When is a document not a Document but still a document?

Documents have a bad perception, they are big, unfocused, and hard to process or view. I'm going to propose something that is counter to the perception, driven by current healthcare use of CDA documents and the HL7 Principles of a Document. Something supported by IHE Document Sharing (XDS/XDR/XDM/XCA/MHD), something enabled and using #FHIR.

When is a Document a Document?

Some background that is important can be found in the IHE HIE-Witepaper in the section on "Principles of IHE for Health Document Sharing". The the most important part is the HL7 defined Principles for a Document. Found in "2.3 Distinction between Documents and Messages"

The HL7 standard for Structured Documents Section describes the document vs. message distinction as follows “A document is designed to be persistent for long periods of time, whereas messages are more often expected to be transient. There is a place for both of these constructs in healthcare.” HL7 characterizes a document by the following properties:

• Persistence – Documents are persistent over time. The content of the document does not change from one moment to another. A document represents information stored at a single instance in time.
• Wholeness - A document is a whole unit of information. Parts of the document may be created or edited separately, or may also be authenticated or legally authenticated, but the entire document is still to be treated as a whole unit.
• Stewardship - A document is maintained over its lifetime by a custodian, either an organization or a person entrusted with its care.
• Context - A clinical document establishes the default context for its contents
• Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.

I am not going to say that these principles are not good Principles. I really believe they are critical principles. But sometimes they become a burden when one wants a "document" and not a "Document". What I am describing is something that is short of these Document Principles, but still meets the need.

What is a document vs a Document?

The Document Sharing system from IHE is focused on "document", not "Document". I don't think that IHE always makes that distinction, but I will make it here for the purposes of this article. I use  "Document", with an upper-case "D", when the object meets (or is intended to meet) the principles listed above. These are the best kind of Documents, I am not arguing that these principles are not the best.

I use "document", with a lower-case "d", when I am referring to an object that meets the Internet's definition of a document. As in the "http" transport is defined to move documents. All that the Internet cares about a document is that it is a set of bytes that have a mime-type and possibly other metadata. These mime-types and other metadata in the case of http are carried in the http header. But they are simply metadata, that is to say they are data that describes the document. the mime-type is the most visible, and the mandatory one.

The IHE Document Sharing infrastructure has almost this same requirement. A document in XDS need only have a mime-type and a Patient identity. The additional requirement of a Patient identity is because of our Healthcare need.

FHIR-Document is a Document

In FHIR there is a formal definition of a FHIR Document, that is intended to be able to meet the above HL7 defined Principles of a Document. Most of the Principles are carried in the FHIR Composition Resource that must exist in a FHIR-Document Bundle. Everything else in the Bundle is just FHIR Resources. The problem with a FHIR-Document is that there is not as much experience with it, vs experience with http RESTful FHIR. So, although I could propose that FHIR-Document concept be used, I am going to deviate back to "document"

What is this document?

Given that there is much experience and interest in using http RESTful FHIR, and given that there is a nationwide exchange for Document Sharing. How can we use this exchange to get at RESTful FHIR results? So what I propose is that there is a well established set of typical queries used in the RESTful space. It is not as big as one might imagine. I am not saying that the full spectrum of FHIR queries are not needed or used, just that the vast majority fall into a few typical needs. This is especially true in Treatment usecases in cross-organizational need.

I propose that we define a set of canned Queries that are needed often. Each of these would be defined as a FormatCode with a set of metadata appropriate to the need. The document in this case is then the FHIR search set Bundle that would result from a http RESTful query. In this way the document is not fully a Document, but it is a Bundle that is more commonly consumed by clients today.

A system supporting these FormatCodes would publish a "On-Demand" entry advertizing each of these that they are willing to produce. A consuming application can discover these "On-Demand" entries, and retrieve the "document". That "document" is a SearchSet Bundle holding the query results. Likely the use of Snapshots to preserve each response would not be needed.

Some suggestions would need to be discussed. I suspect the following are a good start:

• Current Medications
• Current Allergies
• Current Problems
• Current Immunizations
• etc...

Some design needs to be done, The list is likely not more than 10 or 20. There might need to be consideration of huge results, that might be addressed through better query specifications, or might have some other solution.

Consuming FHIR

This solution gives a similar result to the one described in "Consuming data as FHIR Resources" in the HIE Whitepaper. But does not require a "decomposition" step as the original source is producing the FHIR SearchSet Bundle.

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.