Set of documents that are very focused #FHIR

 I outline in the last article that a Document Sharing "document" does not need to be a "Document". I propose that there might be a set of documents that are very focused on specific concepts, or Document sections. I think we have a ready structure for this in the current International Patient Summary (IPS). This is a real Document, but it is made up of sections that are interesting on their own. So, I suggest that we take the sections of the IPS and declare a way for that section to be made available as a  "document" in Document Sharing.

Here is the diagram from IPS,  the BLUE (header) stuff is already handled by the DocumentReference (XDS DocumentEntry)., so each of the Red, Orange, and Green blocks could be a standalone "document".

 Which is simply a Bundle of type searchSet holding the information profiled for that section.

And those sections are already defined. This is an excerpt from section 5.3

Following are the profiles that have been defined for each section. (R) denotes a required section (i.e. must be present in an IPS), (S) denotes a recommended section, the others are optional:

• Medication Summary (R) [ Medication Statement (IPS) | Medication (IPS) ]
• Allergies and Intolerances (R) [ Allergy Intolerance (IPS) ]
• Problem List (R) [ Condition (IPS) ]
• Immunizations (S) [ Immunization (IPS) ]
• History of Procedures (S) [ Procedure (IPS) | Organization (IPS) | Device (performer, observer) ]
• Medical Devices (S) [ Device Use Statement (IPS) | Device (IPS) ]
• Diagnostic Results (S) [ Observation (Results) | DiagnosticReport (IPS) | Organization (IPS) ]Laboratory results [ Observation (Results: laboratory) | Specimen (IPS) | Media observation (Results: laboratory, media) ]
• Radiology results [ Observation (Results: radiology) | Device (performer, observer) | Imaging Study (IPS) | Practitioner (IPS) ]
• Pathology results [ Observation (Results: pathology) | Specimen (IPS) | Media observation (Results: laboratory, media) ]
• Vital Signs [ Vital Signs ]
• Past history of illnesses [ Condition (IPS) ]
• Pregnancy (status and history summary) [ Observation (Pregnancy: EDD) | Observation (Pregnancy: outcome) | Observation (Pregnancy: status) ]
• Social History [ Observation (SH: alcohol use) | Observation (SH: tobacco use) ]
• Functional Status (Autonomy / Invalidity) [ Condition (IPS) | Clinical Impression ]
• Plan of care [ Care Plan ]
• Advance Directives [ Consent ]

So we just need (a small Implementation Guide written)

1. A formatCode defined for each of the above. 
2. A constrained DocumentReference to make sure that it is covering all that is in the  Blue section of the IPS. Mostly this is just a use of the IPS Composition profile applied to the DocumentReference (see FHIR core mapping between Composition and DocumentReference).
3. Additional requirements on DocumentReference based on the Composition.section details for that type of content.  This likely sets the typeCode, classCode, etc.
4. The Bundle profiled. I propose a search set Bundle, but am not sure that is the right Bundle type. I prefer it as that type of a bundle is well supported today, and realistically this whole concept could be seen as a search result.
5. Define if this is only available as a On-Demand? Should this allow snapshot, or forbid? Is there a Transforms relationship to the full IPS, or is that through referenceIdList?

The result is about 15 new document types. Thus if one only wants to get the immunizations, they only need to pull the immunizations. The IPS is there if you want it, this is not an attempt to degrade the need or concept of a Document. This is simply to recognize that sometimes (most?) there is just a need for a section, not the whole summary.

Who is with me?

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.

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