Wednesday, December 16, 2020

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.


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

Thursday, December 3, 2020

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 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 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 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.

Wednesday, December 2, 2020

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.