Agile improvements toward #FHIR

The healthcare IT exchange for Treatment has been improving from the dark ages to today. This article is where I muse about getting to that beautiful future based on #FHIR.

Break Everything

One possibly that some advocate is turn off what we have today, and everyone and everything switch to using http RESTful FHIR. Even to just leave what we have running, and build new only using http RESTful FHIR, would ignore current successes. There are some things we have learned getting to where we are that are unique to healthcare, for which http REST has not yet needed to solve. This "off/on" solution is not smart, agile, incremental, improvement.

Note I am not saying that using http RESTful FHIR is a bad idea, for green-fields it is a good choice, likely the best choice. Just that nationwide, there are considerations that are beyond http REST concept, that are indeed special in healthcare.

Another  possibly is to just encourage anything and everything, hoping that someone will hit upon a successful solution. This is often referred to "let many flowers bloom", and is the model I hate the most. Yes this is the way evolution in nature works, but evolution in nature doesn't have the brains, lessons-learned, and planning power that humans have. We should not be using "let many flowers bloom" be used, it is not human.

Note, I am not saying that "let many flowers bloom" is always inappropriate. I do think that it is most of the time inappropriate.

Agile improvements

Agile approach builds on working systems, and pivots against non-working solutions. So let me explain an agile path.

We have a very mature and functioning nationwide healthcare exchange. We have two transports that can cross communicate, aka Karen's Cross. This pair of transports now has a third FHIR mode, so Karen's Cross is now three dimensional.

imagine a fancy graphic here that shows three sources each of the types: e-mail, SOAP, and REST talking to three consumers each of the types: e-mail, SOAP, and REST

For a good explanation of these transports, I refer you to the HIE-Whitepaper by IHE.

These transports are content format agnostic, so can carry old content, current content, or future content. Might be PDF, or CCD, or C-CDA, or v2-lab, or DICOM, or Tiff, or text, or comma-separated-values (CSV), or FHIR.

The query / retrieve model enables publishers to offer various formats of the same content.  Meaning the same content could be offered in many formats. This might be published objects, or dynamically generated, or deferred creation entries. Thus a consuming system can select what is best for them. 

Again, I will refer you to the HIE-Whitepaper by IHE.

CDA is here and it works

Much investment has gone into CDA. It has many positive attributes. People know how to make it do things therefore taking on new needs with small changes.  CDA can take on new use-cases just as well as FHIR can. I am not going to try to argue that CDA is just as easy to understand as FHIR, but realistically when the content developers already know CDA, it is easier for them to improve CDA than it is to throw away their knowledge and learn FHIR, simply because there is a perception that FHIR is easier. It is not easier for them.

FHIR is not yet here, but it will be

FHIR is the new hotness, and it will most likely be the future, but it is new and it is still evolving. Likely 5 years yet before it is mature, it is a high-schools graduate able to flip burgers and dig ditches. Powerful and useful, but needing some more maturity. Note it took 5 years to get here, 5 more seems long but it will be here quick. Along the way FHIR will do good things.

First incremental step

So given that I do agree that the future will likely be far more of the FHIR based, I think the best way to get there is to make incremental steps toward that goal. Each step is going to be a bit unsatisfactory, but each step should move us toward that goal. 

The reason incremental will work, is that the current systems already do function. So we are not starting from a broken system, we are starting from a sub-optimal system (some argue it is optimal, but I am willing to allow for saying current system is sub-optimal).

The Document Sharing Exchange allows for new content types to be easily supported. So where we might today be using C-CDA, the next incremental step might be to publish BOTH a C-CDA and a FHIR-Document (IPS). Include an association type linkage between them, so that a consuming system can know that they contain the same information in different formats. In this way a consuming system that has only ever understood C-CDA can pull the content it understands, and a different consuming system that prefers FHIR can pull the IPS content. 

Again, I will point you at the HIE-Whitepaper - section 2.7 Document Relationships where this is discussed.

IHE ITI February 2021

The IHE ITI-Tech committee finished our meeting this week a bit overtime, but very satisfying.

We finished with a toast to Bill Majurski. The ITI committee and the whole Healthcare Information Exchange market has benefited from, The originator of the concept that became XDS.

    https://www.ihe.net/in-memoriam-bill-majurski/

Accomplishments this Quarter:

This week the ITI committee has moved three work items along on their milestones:

IUA - the Internet user authorization profile needed some revisions to update it to the latest standards from OAuth community. Along the way we added clarity and features like introspection.  

HIE-Whitepaper -- the whitepaper needed to be updated to include the FHIR based models that we have published in the MHD family. This was somewhat addressed in the MHDS profile, but the whitepaper addresses the need and all the solutions that IHE has to offer. This also includes the use of QEDm and mXDE to make FHIR Resource level data available from the shared documents, making consumption more easy. This update also links deeply to the newly published html rendering of the ITI Final-Text Technical Framework.

MHD - MHD is our first IHE-Profile to be published using the Implementation Guide publishing platform. This platform, managed as an open-source platform, originally developed by HL7 (Grahame) for FHIR based Implementation Guides. It is widely expanding beyond this scope, and IHE is looking to use it for our publication needs. The Implementation Guide publisher encourages use of conformance resources (e.g. StructureDefinition) and inclusion of examples. Thus a major benefit of this publication means is more accuracy and more specificity. In addition to this, MHD version 4.0 is moving away from using DocumentManifest toward using List FHIR Resource., This to aid with moving toward Normative status.

Each of these works has received conditional approval by the committee, where the condition is to cleanup some minor issues expected to be cleaned up soon. Each of these will get formally published on the new IHE http://profiles.ihe.net web site in html form only. This may take 2-3 weeks to achieve.

Next Quarter: 

Given that we have moved two moderate sized work items off of our plate, we have accepted two new moderate sized work items from our prioritized backlog:

mCSD whitepaper - Since mCSD doesn't require a particular set of FHIR resources to support, there is a need to define various implementations and the additional requirements they would have. For example, a Facility Registry would require supporting mCSD with Location and Organization resources, and a Health Worker Registry / Provider Directory would require Practitioner resources. This whitepaper would describe these various use cases and how mCSD can be utilized to support various implementations. 

MHD to a Federation - The concept of federation is relatively underspecified in FHIR at this time. The notion of "home community" is used by numerous IHE profiles to enable complex, large-scale heterogeneous networks. See [IHE ITI TF-1] E.9 "XCA Integration with XDS and non-XDS communities" for a number of examples of federated deployments enabled by XCA. FHIR does not have an explicit analog for home community. We would like to add this to the IHE FHIR-based profiles. This would support all-FHIR cases requiring federation (for example, crossing security boundaries) as well as bridging FHIR with non-FHIR mechanisms such as XCA. Our initial use cases address mCSD and MHD, but other profiles could be considered, as well as Appendix Z for common capabilities, such as a consistent encoding of HCID as a business identifier.

We will continue to improve the html rendering of the Final Text Technical Framework

We will continue to work on Change Proposals across the portfolio.

Lastly, there has been fantastic input on our PMIR profile that will likely result in some improvements of the profile and possibly some new work items. This is an excellent example of a group trying to develop to our specification and finding difficulty, bringing that difficulty to the committee, and we ALL benefit from clarity that will result.

This was a fantastically successful week. Proof that virtual face-to-face can be successful.

As these get formally published, i will post more articles. The committee drafts will take some care and feeding until they get formally published. A few weeks.

IHE whitepaper on Health Information Exchange models

The Integrating the Healthcare Enterprise (IHE) standards profiling organization has developed a collection of profiles which can be leveraged for use by healthcare communities for the purposes of document sharing. One of the most significant applications of healthcare information technology is the exchange of health information among disparate clinical information systems and otherwise unaffiliated care providers. Across the world, various communities have developed or are developing methods for exchanging health information among healthcare providers, patients, and other authorized parties. The purpose of this white paper is to provide an overview of the collection of IHE profiles which are intended to be used by communities for exchanging health information. The collection of profiles includes support for patient identification, health document location and retrieval, provider directories, and the protection of privacy and security. This white paper will show how various profiles work together to provide a standards based, interoperable approach to community and cross-community health information sharing.

Here is the HIE-Whitepaper

Those looking to deploy a Health Information Exchange will find guidance on recognized principles and mechanisms. There are solutions that are intended to support small, medium, large, and federations of communities. Where an exchange is based on legacy IHE profiles of XDS or XCA, there is guidance on how to enable a more easy on-ramp and off-ramp in the MHD profile that uses FHIR for the API. There is important considerations on how to evolve from a working legacy exchange to an exchange that enables modern technology. There is also a model in MHDS for those that have no legacy environment that builds the full infrastructure using FHIR services.

There is guidance on how to enable more fine grain access to the data already available in your network through the use of mXDE and QEDm. This model enables FHIR clients to access Observations, Allergies, Medications, etc; as if they were published as FHIR resources, while preserving Provenance back to the Documents and Organizations that published the data. Giving credit where it is needed, and providing critical context for the fine grain data.

The clinicians will find that this paper recognizes their interests in being properly recognized as authors of documentation. Some clinicians are comforted with the document concept, some clinicians are more comfortable with the fine grain access that FHIR brings. Both models are described as integrated.

The Health Information Exchange model presented is an Infrastructure, it is not constraining the content. Today it is common to communicate CDA documents, but the future may switch over to FHIR Documents. Along the way there may be fragments of FHIR bundles dedicated to a specific need, such as the patients current allergies, or the patients current medications. These may not be seen as a fully qualifying document in the eyes of CDA, but they are perfectly legitimate in the Document Sharing infrastructure.  

The patient is not to be left out of the discussion. Like the clinician the patient is a recognized potential participant in these Health Information Exchanges. The patient based application is more likely one that will need and want a FHIR based interaction, so the MHD based on-ramp and off-ramp are very important to the Patient access. The Patient would also be a participant in setting rules of access in their Consent. This paper discusses three different Consent mechanisms that IHE offers to enable this. The actual accessibility and control is driven more by policy.

The population health communities can also be a participant on the Health Information Exchange. They typically would not be publishing documents, but would be consuming documents published, receiving content that is pushed to them, and analyzing the data for population trends and reporting.

All of these communities would need to be carefully managed, carefully authenticated, authorized, and monitored. The paper goes into the interoperability solutions in Privacy and Security that are foundational to local policies to be enforced. There is some additional papers that discuss some of these policy considerations, and how the policy interacts with the infrastructure.

Lastly the whitepaper is stressing the use of FHIR available today, while showing that there is a much bigger and better future that gets built upon the legacy and FHIR tooling. 

Find the whitepaper here

From Implementation-Guide to IHE-Connectathon

So you have an Implementation Guide (aka IHE-Profile), and want to test at IHE-Connectathon....

The following is mostly based on what happens when an IHE Profile (aka Implementation Guide) is written. Much of what I outline is not as visible as it should be. Often these tasks are done by the IHE Connectathon staff, with a bit of help and oversight by the Profile writers and co-chairs. I am working to move some of this more visible, and sooner in the process.

I am not yet convinced that IHE is ready to take on the task of testing a specification not written by IHE. This is talked about a lot, but not much resources have been put toward it. First up was SANER, but it is a bit stalled. I started a TestPlan in the SANER implementation guide, and Keith has improved it. I am just not sure how comprehensive the SANER test plan is. 

I am a fan of using IHE-Connectathon for more comprehensive and formal testing, vs using the FHIR-Connectathon more for specification validation and experimentation. See my past articles on "What is a Connectathon", "Maturing FHIR Connectathon without confusing the marketplace". and "Introduction to IHE Connectathon and Projectathon".

So the idea of IHE-Connectathon testing of a developed IG goes something like this.

1. IHE develops a test plan -- this is the overall plan for how the actors would be tested independently, and how scenarios would test a set of products.
2. IHE develops test procedures for everything in the plan
3. IHE develops or selects test tools to simulate peer actors for actor testing
4. IHE enters the IG, actors, and any optional pathways into Gazelle
5. Products sign up for testing
6. some IHE-Connectathon happens (virtual or physical or adhoc)
7. Products test using the actor test test procedure and tools
8. Products submit their results to proctors
9. Proctor checks the results with the expected results and passes them or sends them back to try again
10. Product is paired up with peers for cross-product testing
11. proof of cross-testing is submitted to proctor
12. After final review products are given a gold-star

Generally today this starts with #4, and only after 3 or more products sign up for connectathon are steps #1-3 done. We could do this with HL7 Implementation Guides, but I would think we should look for interest before we enter them into Gazelle. Although the theory is that with IG publication and the CapabilityStatements in these IGs, this Gazelle registration could be automated.   

Generally today 1-3 is done by two IHE experts. These steps are often done in isolation, and in the first year done very quickly. As the signal that an Implementation Guide needs these written is very close to the time at which the IHE-Connecathon happens. This is why I want step 1 to be done as part of the specification writing. Doing step 1 as part of the specification writing will also assure that the goal of the Implementation Guide is clear.

Step 1 is where I and a few others are thinking Gherkin comes in. Step 1 is a critical step to have cooperation between the specification writers, product implementers, and test writers. Theory is that if we had a mature Gherkin infrastructure and writing, then many of the other steps could be less hard, and the testing could potentially be automated. The use of Gherkin fits nicely because it is very Behavior based, and is considered a critical tool in Behavior Driven Development (BDD). Gherkin promises to provide a well pattered sentence structure (Given, When, Then) so that the sentence structure can be parsed by regular-expressions and glue-code. These regular-expressions and glue-code are the magics, and are special to every project. Theory is that IHE might find some of these reusable.

Here is an example of a test-plan as part of my MHD IG that I am developing, this test plan only covers 25%. It is not using Gherkin (yet), but rather is just a minimally expressed set of test scenarios that are envisioned would be necessary to test comprehensively:

    http://build.fhir.org/ig/IHE/ITI.MHD/branches/master/testplan.html

Here is SANER. I started this page, but it has taken on a life beyond my efforts. So I am not exactly sure if it is a good example. But it is again high-level set of scenarios

    http://build.fhir.org/ig/HL7/fhir-saner/test_plan.html

Similar setup can be done with a "Projectathon", which starts with the above already done, and focuses on project specific further refinement. Where projects tend to be regions, countries, or other community. Possibly I will write about this in a future blog article.

The above has not been outlined as well as I just did... so this is just my first try at expressing this.  Each step is likely 20-60 hours of work to do it right. Thus to get to step 6, means at least 100 hours expended. I will see if others agree.

Actual Consent is more important than more standards for Consent

I interact with many Patient Advocates, Privacy Advocates, and individual Patients that are frustrated at the state of Privacy Consent today. I am too, but potentially in a different way.  

Interoperable Consent Standards

My main focus is on enabling Health Information to flow given proper Security and Privacy. Thus one of my focuses is on the interop standards that enable Privacy Consent to function properly. Enabling data to flow when it should, and blocking data from flowing when it should not. This involves simple consents like Allow or Deny. This involves a patient not yet having made a choice (default rules). This involves a patient changing their mind. This involves a patient explicitly authorizing a given kind of access by a given kind of user... etc

These Consent needs are very itemizable. I have been involved (sometimes lead) the efforts to define an Interoperable Standard for these use-cases in IHE for Document Sharing Exchanges (BPPC, APPC, XUA), and in CDA (CDA Consent), and in FHIR (FHIR Consent). The application of security vocabulary as request context (purposeOfUse), response obligations (do not re-disclose), and data tags (confidential and sensitive). The creation of a Consent Service using User Managed Access functionality of OAuth (HEART).

I have been engaged by some of the nationwide exchanges to customize these for their needs, which turn out to look much like the IHE solutions. They mostly look for a reasonable subset of full capability of these standards that minimally meet their needs. This minimal view is important as building a trust domain requires that you get everyone within that domain to all equally implement the same thing. Thus a minimal subset that hits the realistic need (not theory) is more likely to get implemented fully.

Reality is that Consent is Local

Most of these situations, the consent is a local thing. That is to say that a custodial organization obtains consent, manages consent, and enforces consent with no visibility to the exchange beyond the enforcement of releasing documents or not. Thus the majority of situations have no need for an “Interoperable” consent, as they need only achieve it functionally. Thus most trust-frameworks make it clear that data released is released for the given context (purposeOfUse) and then falls under the custodial rules of the recipient.

The dominant Consent failure is also Local

This is where the biggest failures around Privacy Consent happen. They are NOT offered, or too few choices are offered, or too many exceptions to the Patient desire are embedded. Thus the patient data flows in cases that the Patient does not want it to flow. The patient data does NOT flow when the patient does want it to flow. And the Patient often has no visibility into when it did flow, or when it was denied to flow (traceability). These failures are local functionality (policy). Fixing these failures will not be aided by more Interop standards on the topic. Fixing these failures is only driven by Patient demand, Government backing of that demand, and Businesses having an interest in satisfying the patient, and/or their government. In the absence of this interest, Businesses will do what optimizes the Business bottom line... which is data-blocking to keep Patients from leaving, data-analytics on the data for benefit of the Business, etc. 

But Interoperable Consents are needed

I am not happy with this state of Consent fact. I am comfortable with it, but I see so much more that could be done beyond what is happening today.   The vast majority of use-cases today are “Treatment” purpose of use… a very narrow and well defined domain with simple trust framework needs.

A demonstration of this Consent for Treatment has been done at HIMSS multiple times, and reality is… no one cared to watch it. I say no one, but we all realize that is just a statement of percentage of people that care vs total HIMSS population. Likely hundreds of people care, and 20% of them showed up. The audience is just so small that it is not worth the energy needed to setup the presentation. This is why I blog, and also why my blog gets so few visitors. The math is just not very big.

Non-heterogeneous PurposeOfUse networks

There is an emerging force in HealthIT approaching, the Payer community that also want and need access to the data. The very data that we have enabled in the exchanges so far. This would be a "Payment" purpose of use.  But this does not really stress the minimal implementation much at all, as the PurposeOfUse mechanism is something that was kept in the minimal set. And consent is still local when it comes to billing requests. Most healthcare, especially in the USA, get a consent that is effectively on Treatment, Payment, and normal hospital operations (maintenance).

There are some Government use-cases for population health that have used the exchanges. These are beyond Treatment, Payment, and Normal hospital operations. But are also a specific defined purpose of use. 

The more important force is that the Patient wants to interact with these nationwide exchanges. This means a PurposeOfUse of "Patient. The Patient might choose to request their data move in ways not yet defined.

If we had a more comprehensive consent system, might that enable data to flow more freely and more broadly than today? Yes, but... Most of these consent rules could still be local. What is important for non-heterogeneous networks is a method of identifying the purpose(s) for which the data are requested, and for which the data are released. This is baked into the standards, but everyone must use these consistently and accurately.

Just in time Consent

The most interesting Interoperable Consent that I have come across is the Just-in-time Consent, other wise known as "Point of Care Consent". This is a setting where the patient has not pre-arranged a Consent, thus initial requests for data are denied. But one where the two (requesting and responding) have a trust-framework such that the responding organization trusts the requesting organization to get a Consent from the Patient, provide proof of that consent, and then the responding organization will release the data for the consented purpose. This Consent is mostly for Treatment, I have not seen it for other. This Consent tends to be a blanket PERMIT, no quilting of exceptions or stipulations. Thus this consent tends to be a simple binary "Interoperability" need. But it could be more complex. It could include the same features as any Consent. And THAT is when the Consent needs to be more than a binary, when it needs to have these conditions, clauses, expiration, etc all in a structured and coded form. 

This is baked into the IHE-XUA (SAML), and IHE-IUA (OAuth) profiles. What is needed is a policy based trust-framework, a policy based vocabulary. and traceability for the evidence and terms of the consent. Care Quality has set these up. The vocabulary and evidence could use simple (BPPC), or comprehensive (APPC), or FHIR Consents. 

And Interoperable Consents will happen

The standards organizations (IHE, HL7, ISO, etc) have done as much as they can at this point. They are not done, but the next steps for these standards organizations is not in the core standards space. The problem is in implementation guides and market demand.

Here is my best-case plan… I want to see the SAMHSA defined  "Consent to Share" Implementation Guide, come back to HL7 to be balloted, published, and maintained. I see this happening next year. I do NOT see this being driven by security workgroup or CBCP. I see this being driven by Patient Empowerment workgroup with security and CBCP as interested parties (not co-sponsors). I think this has the best chance to succeed. 

Do I think that security couldn’t make it happen? No. But if security (or CBCP) did the project, no one outside of our workgroups would care. A specification that is ignored is not useful.

Why next year, and not now? Because Patient Empowerment workgroup is deep in two other projects at this time. Both of which have a high interest and strong engagement. PLUS these have gotten the attention of Argonaut, and thus the EHR vendors.  I want to see these succeed (so don’t overload them with yet another project). And once they succeed, consent will take off with the momentum.

Conclusion

The most important point is that consent is mostly a local thing, that results in data being withheld to an external request or allowed. There are very few use-cases where a consent must be anything more than that. Fewer than that where that consent must be in an interoperable format. And fewer than that where there is a trust-framework to make an interoperable consent work. And fewer where the recipient has different custodial rules than the original custodian.  Yes we design things like Consent Resource and Consent Service to these needs. But we must recognize that they are not actually compelling.

See my other articles on Consent

IHE releases IUA, HIE-Whitepaper, and html published Technical Framework

Big day for me, and the IHE team. I am so pleased at the way the IHE ITI workgroup membership, and IHE support personal, worked on all of this. I would say this is the biggest impacting release that IHE has done since XDS. This is bittersweet as we recently lost the father of XDS, Bill 

Today IHE releases three very important products:

1. An update of IUA, the profile of OAuth that IHE has defined. This is an alternative to SMART-on-FHIR, and not intended to be conflicting. Each cover unique spaces with some overlap.
   
   
2. An update to the HIE-Whitepaper, bringing in the newly build FHIR based profiles. Profiles like MHD, MHDS, mXDE, QEDm, PMIR, SVCM, mCSD, ATNA, and IUA.
   
   
3. Brand new publication method for the ITI Technical Framework using html. This is just the final-text, does not include trial-implementation supplements, although they are included in the publication framework.

These three publications are all using the html publication framework, and they cross-link into the technical framework. see https://profiles.ihe.net/. This is the new home for html published works from IHE.

I will be writing more articles pointing out specific things of each of these publications. coming soon, right here, and possibly elsewhere...

IHE IT Infrastructure Technical Framework Documents Published. Is this email not displaying correctly? View it in your browser. Important IHE IT Infrastructure Technical Publication News: The IHE IT Infrastructure (ITI) Domain has been working towards the goal of publishing some ITI documents in HTML versus the current PDF format. Their efforts have produced the following: An updated public comment version of the Internet User Authorization (IUA) supplement  An updated public comment version of the Enabling Document Sharing Health Information Exchange Using IHE Profiles white paper An HTML version of the complete IHE IT Infrastructure Technical Framework Please see below for further details about these publications.   IHE IT Infrastructure Technical Framework Supplement Published for Public Comment The ITI Technical Committee has published the following updated supplement for public comment from December 2, 2020 through January 15, 2021: Internet User Authorization (IUA) - Rev. 2.0 Note: This revision of the IUA supplement, published as HTML, updates the IUA profile originally authored in 2013. This new version aligns IUA with the latest OAuth specifications and adds some new deployment options. A summary of changes is noted in the README on the GitHb repository. This document is available at http://profiles.ihe.net/ITI/. Comments submitted by January 15, 2021 will be considered by the ITI Technical Committee in developing the Trial Implementation version of the supplement. Comments can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.   IHE IT Infrastructure White Paper Published for Public Comment The ITI Technical Committee has published the following updated white paper for public comment from December 2, 2020 through January 15, 2021: Enabling Document Sharing Health Information Exchange Using IHE Profiles - Rev. 2.0 Note: This revision of the HIE white paper, published as HTML, has been updated to include advancements in Document Sharing Health Information Exchange support, including the use of FHIR® infrastructure, and support for consuming FHIR® Resources. This document is available at http://profiles.ihe.net/ITI/. Comments submitted by January 15, 2021 will be considered by the ITI Technical Committee in developing the subsequent version of the white paper. Comments can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.   IHE IT Infrastructure Technical Framework Published as an HTML document The ITI Technical Committee has converted the complete ITI Technical Framework to HTML. It is available here. Important Note: This HTML version of the IT Infrastructure Technical Framework is published in parallel with the current ITI Technical Framework (Revision 17.0) published in PDF format. Any discrepancies between the HTML and the PDF are unintended and the PDF shall take precedence.  The ITI Domain expects that the next revision of the ITI Technical Framework will only be published in HTML form and the domain will stop producing PDF Technical Framework Volumes. A reader can use a browser to produce PDF extracts and IHE plans to provide more comprehensive functionality to extract PDF next year. Comments on the HTML version of the IT Infrastructure Technical Framework are welcome at any time and can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.

XDS/MHD Community input needed - MHD move away from DocumentManifest

I have asked this on the various discussion lists for XDS and MHD. I have gotten positive response. I am very interested in concerns, and help.  I have started this work, IHE MHD Github Repo. 

Hi MHD implementer community 

As many of you know, I am the author of MHD and also part of the HL7 FHIR core team. 

ASK: Please consider this message and provide feedback. I want to represent the interests of the MHD community, but also need that community to be active in HL7 and IHE. I am especially interested in concerns with the approach described below. I am also eager to get engagement in the ITI-Tech work we are starting on MHD (see below).

I have been thinking about a maturity problem that is coming up in FHIR R5 related to the FHIR Resources used by MHD. 

Patient is already normative.

DocumentReference is likely to be pushed to be normative in FHIR R5. It is part of US-Core so has a group of people beyond MHD working on it.

List (MHD uses for Folder) is used by a couple of use-cases outside of MHD. So there is multiple groups working on it.

but DocumentManifest is not getting the proper attention to help move it to normative state. If that does not happen, then MHD will stay as Trial Implementation when it should be a consideration for Final Text.

Many of the MHD use-cases are recognized in US-Core, but they use only DocumentReference and don't have use-cases for DocumentManifest or List (Folder). I bring in US-Core only to express where the motivation is to push DocumentReference to normative. IHE is of course Internationally focused.

The only use of DocumentManifest is in MHD...

1. We (IHE) can do what is necessary to make this normative. I will still need the IHE community to step forward within the HL7 community to push the workgroup owning DocumentManifest to do HL7 governance. Note that this is a big problem as well since DocumentManifest is still owned by Struct Doc WG; where DocumentReference has moved over to OO. Thus this pathway has many organizational challenges.
2. We (IHE) can switch MHD away from DocumentManifest, using List. There would then be two kinds of list in MHD, one as the SubmisstionSet, the other as a Folder.
3. We (IHE) can switch MHD away from DocumentManifest toward some other resource. 

ITI-Tech has agreed to #2. That is to stop using DocumentManifest for SubmissionSet, and profile a use of List for SubmissionSet functionality. This might produce some update requests to List to add elements necessary for that use-case. Adding elements to List should not be seen as a problem. List maturity would be needed by MHD for Folder anyway, so putting our efforts toward the same resource would be helpful.

Yes there are functionality differences between a SubmissionSet and a Folder. These differences can easily be profiled into the same List resource.

Note that ITI-Tech is also going to formally move MHD out of supplement form, and into the IG Authoring form. Thus we would benefit from community engagement, such as providing examples and review.