Have MHD Clients? What Infrastructure should you deploy>

I am working up a set of decisions around the use of XDS vs XCA vs MHDS. In the past XDS was used when one wanted to create a Document Sharing HIE, and XCA was used to federate XDS Document Sharing HIE and add in EHR based Document publications. Now IHE has the MHDS infrastructure, so the question is likely to come up.

Mostly if you have XDS clients, you need to continue to use XDS or XCA. -- Add MHD as an API to enable MHD clients

If you have no legacy, then it is possible that MHDS is the right platform for you.

There is likely future IHE projects that will federate MHDS, enable connection of MHDS to XCA federations, and add XDS api to MHDS. All of these are unusual configurations, so will need market demand to come to the table to make it clear they are needed, vs simply being academic gaps.

Mobile Health Document Sharing (MHDS) Profile

This profile shows how to build a Document Sharing Exchange using IHE profiled FHIR® standard, rather than the legacy IHE profiles that is dominated by XDS and HL7® v2. This profile will assemble profiles and define a Document Registry.

The MHDS Profile specifies how a collection of IHE profiles can be used by communities for exchanging health information. These IHE profiles include support for patient identification, health document location and retrieval, provider directories, and the protection of privacy and security. MHDS shows how several IHE profiles work together to provide a standards-based, interoperable approach to community health information sharing. The IHE IT Infrastructure Domain has published several resources to support document sharing:

• ITI Technical Framework: Vol. 3 - Section 4.0 Metadata used in Document Sharing
• Health Information Exchange: Enabling Document Sharing Using IHE Profiles
• Document Sharing Metadata Handbook
• Template for XDS Affinity Domain Deployment Planning

Document Sharing on FHIR

This MHDS Profile defines a Document Sharing Exchange that is based around the HL7 FHIR standard, following the principles described in the Health Information Exchange: Enabling Document Sharing Using IHE Profiles whitepaper. This Document Sharing exchange requires the same management of metadata as described in the Document Sharing Metadata Handbook.

more...

IHE Winter 2020

The IHE Winter 2020 face-to-face capped off a 5 week road-trip for me. I am so very glad to be home and able to sleep in my own bed, work at my own desk, surrounded by my kittens and family.

The ITI committee has finalized three work items that will soon be seen open for Public Comment: Public Comment on a whitepaper, and two profiles (Implementation Guides).

SNIF - Survey of Network Interfaces Form 

This is a whitepaper outlining a problem that is faced by many healthcare software or device vendors when they attempt to integrate with a customer environment such as a hospital or clinic. The problem is that there are some critical networking details that are needed to make the connection successful. Things like, what is the IP address of the patient registry.

The whitepaper is attempting to bring together those that manage a network, with those that will eventually need to be integrated into the network. There are a large list of potential ways that this critical information can be managed, but none of them are dominant or comprehensive. By bringing this group together, IHE is attempting to get these stakeholders to work together to a common agreed solution.

One leading proposal is based on our experience running IHE Connectathons, the schema behind Gazelle and how it manages partner testing.

SVCM - Sharing Valuesets Codes and Maps

This profile addresses defining reusable Actors for managing and using terminology using FHIR. There is not much constraints within the IHE profile, but rather setting well defined abstract actors to enable use-case orchestration. There are two actors defined: Terminology Repository and Terminology Consumer. There are seven defined transactions between them. All of the use-cases are focused around use of terminology. There is no intention of supporting the 'management' of terminology, the management is an important functionality of a system declaring the Terminology Repository.

MHDS - Mobile Health Documents Sharing

This profile went through one public comment, so this will be an unusual second public comment. The reason for the second public comment is to assure that we get broad review. The first public comment was on a far less mature text, and was over the Christmas break and January. So we expect that the second public comment can get comment more deep. The biggest improvement is in the diagrams.

MHD defines a full Health Document Sharing infrastructure by assembling many profiles such as the SVCM, mCSD, ATNA, and PMIR. There is one new Actor, the MHDS Document Registry, that takes on the central Document Registry. This Document Registry actor is required to act as a document repository, but this does not force organization sourcing documents from managing their document repository within their organization like is set forth in XDS. The following shows a detailed Actor/Transaction view given two stereotypical clients "System that publishes documents" and "System that consumes documents" pictured in green on the left. The supporting infrastructure is represented in the middle in yellow, this supporting infrastructure is simply the use of these services from the given supporting Profiles.

I will cover more on MHDS in a follow on article.

Mobile Health Document Sharing (MHDS) - First Public Comment

MHDS is published for public comment. This is the first of two Public Comment periods, with the next one this spring. We are doing two public comment phases in order to get broad set of review.

The Mobile Health Document Sharing (MHDS) Profile is a 100% FHIR Document Sharing infrastructure leveraging many IHE FHIR profiles including MHD. Where MHD has historically been an API to an XDS or XCA environment; MHDS introduces a new Central Registry actor and discusses how to build a complete Document Sharing infrastructure using other IHE Profiles.

This Document Sharing includes support for sharing FHIR-Documents, but is content format agnostic, thus equally capable of sharing CDA documents, PDF documents, or imaging. The big difference with MHDS is that one does not need to have an XDS or XCA backbone, as the backbone of MHD is purely a FHIR server.

Please review and comment. Good and bad. We need to reach a new #FHIR audience, new markets, new solutions. Here is the announcement and details on how to review and comment https://mailchi.mp/ihe/ihe-iti-tf-supplement-published-for-pc-2020-01-21 Note that the deadline for comments is February 14th, a bit shorter than normal, but we need to get comments in by the next IHE face-to-face meeting scheduled for the following week.

Here is the public comment forum and link to the MHD supplement

Included is support for

a system that is publishing documents

a system that is consuming documents

a relationship to mXDE enabled consumption of FHIR resources

2019 wrap

I am not impressed by 2019. Not personally, not for the healthcare industry, not for my country, and not for our world. This is depressing, but also gives me many things to work on. It is working on fixing problems that gives a Systems Designer something to look forward to in the morning.

Blog

On my blog, I only posted 28 articles, which is average more than two a month. But realistically I had a few months where nothing was posted, and other months where a set of four posts happened.

• Segmentation and Security Labeling: 1, 2, 3, and 4
• Blockchain: 1
• Provenance: 1, 2, and 3
• HIE on FHIR: 1, 2, 3, 4, 5, 6, 7, and 8
• IHE: 1, 2, 3, 4, and 5
• Patient Empowerment: 1, 2, and 3
• Speaking Engagements: 1, and 2

IHE and FHIR

My engagements with standards have been the most productive part of my work life. It is hard to come up with describable milestones, but I know that I have succeeded at many milestones.

• The IHE profiles from ITI are all now aligned on FHIR R4, and all have FHIR conformance resources published. This is not all me, in many cases I was just the one pushing the authors 
• I am now part of a team funded by the cooperative agreement between ONC and IHE-USA to position IHE as a major organization for standardization of FHIR based Profiles (aka Implementation Guides)
• Catalog IHE Profiles that utilize the FHIR standard to enable cross community health information exchange
• Identify and prioritize new profiling opportunities to leverage the FHIR standard.
• Accelerate the development of robust, real world testing processes and adoption of the updated FHIR-focused IHE profile and HL7 implementation guides 
• Actively engage with HL7 and IHE International on lessons learned through profiling improvements and real-world testing
• IHE use of the HL7 Implementation Guide publication system is coming along. It is taking longer than anyone wants, but we keep coming up with instances where the tooling is (a) hard to use, (b) unstable, and (c) missing important features. In all cases we are working with HL7 leadership together to make this tooling better for everyone.  

Personal

The big win for the year was a 60 pound weight loss (4.25 stone) on a Keto diet. The bad news is the last three months have been flat. I wish that was my plan, but I really want to loose another 50-60 pounds. Injury to legs and feet have kept me from exercising.  I feel a bit better, and do enjoy doing things that last year would have exhausted me. But not good enough, yet...

FHIR Consent mapped with BPPC

Today on the FHIR Consent call we had a very useful discussion of how one would use FHIR Consent to do the same thing that BPPC does in XDS. Said another way, what is the degenerate form of FHIR Consent that is equal-to the functionality of BPPC, and what is the degenerate form of FHIR Consent that is compatible with BPPC. We did have a slight side discussion about APPC, but lets start simple.

BPPC -- Basic Patient Privacy Consent

An IHE profile for use in an XDS/XCA environment to convey the Privacy Policy Consent status given some basic function. This profile was intentionally called "Basic" with the expectation that something more expressive would eventually come along, but at the time we needed a solution for simple use-cases. Something did come along that is more expressive, called Advanced Patient Privacy Consent (APPC).  BPPC is still the dominant solution as it fits the realistic set of use-cases that are most used. APPC leverages BPPC for context setting and documentation, but adds more flexible rules. Where BPPC supports a binary (true/false), and APPC enables all flavors of grey.

See past articles for more

• Basic Consent - a necessary first step
• BPPC is not just for XDS/XCA
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
• Texas HIE Consent Management System Design
• Beyond Basic Privacy – The IHE APPC Profile

BPPC supports:

The BPPC profile supports a few vectors. It might be Basic, but it is really quite useful:

1. Identify who the Patient is -- in BPPC the patient is all that is recorded in coded form. The act might have been signed by a guardian or parent; but that would be only noted in the attachment. It was not seen as critical to automatic processing
2. Identify what organization is being bound by this Consent -- in BPPC there was not a need to differentiate between what organization is bound, vs what organization signed, vs what organization is allowed to use this consent.
3. Policy being acknowledged -- this enables the community to define a set of policies that are offered, and the one picked and agreed to by the patient is referenced. That policy might be the "OPT-OUT" policy, thus their selection is to not allow sharing of data. -- ITI TF3:5.1.2.1.1.2 
4. Time period that the Consent is valid -- supports a consent that starts in the future, and a consent that has an expiration -- ITI TF3:5.1.2.2.1
5. When the Consent happened - BPPC doesn't address when the consent was indexed as that is not important to automatic processing
6. What PurposeOfUse this applies to -- what activities identified by PurposeOfUse vocabulary. When the consent is an OPT-OUT, this means this PurposeOfUse is forbidden. The PurposeOfUse enables research project-by-project identification each as a coded value.
7. Copy of the signed policy, which may be scanned ink-on-paper or other representation
8. Replacing previous choice -- enabling patient to change their mind as many times as they want

Here is a table showing the mapping between these fundamentals:

• Column A -- short identification of the above fundamental
• Column B -- BPPC as it would look in MHD (FHIR DocumentReference) with no adjustments
• Column C -- BPPC as it would look published in FHIR Consent with no adjustments or improvements -- plenty more can be don in FHIR Consent
• Column D -- BPPC as it is today in XDS/XCA

Basic Patient Privacy mechanism	BPPC in MHD	BPPC in FHIR Consent	BPPC in XDS
Resource Type	FHIR DocumentReference	FHIR Consent	XDS Document Entry
type identifier	DocumentReference.code = LOINC “57016-8”	Consent.category = LOINC “57016-8”	DocumentEntry.typeCode = LOINC “57016-8”
1) Identify who the Patient is	DocumentReference.subject = Reference(Patient)	Consent.patient = Reference(Patient)	DocumentEntry.patientId
2) What organization is bound by this Consent	DocumentReference.author = Reference(Organization)	Consent.performer = Reference(Organization) Consent.organization=Reference(Organization) Consent.provision[0].actor.reference=Reference(Organization)	DocumentEntry.author
3) Policy being acknowledged	DocumentReference.context.event	Consent.policy.uri	DocumentEntry.eventCodeList
4) Time period that the Consent is valid	DocumentReference.context.period	Consent.provision[0].period	DocumentEntry.serviceStartTime <=>.serviceStopTime
5) When consent happened	DocumentReference.content.attachment.creation	Consent.dateTime	DocumentEntry.creationTime
6) What PurposeOfUse this applies to	DocumentReference.securityLabel	DocumentReference.provision[0].purpose	DocumentEntry.confidentialityCode
7) Copy of the signed policy	DocumentReference.content.attachment.url	Two Alternatives A) Consent.sourceAttachment B) Consent.sourceReference = Reference(DocumentReference)	DocumentEntry.URI
8) Replacing previous choice	FHIR Create (New)DocumentReferencewith details & Set previous DocumentReference.status = superseded with DocumentReference.relatesTo.target = (New)DocumentReference	Two Alternatives A) (New)Consent with details & Set previous Consent.status=inactive B) Update Consent with details using a Version tracking Server	XDS Replace operation
fixed values	DocumentReference.content.format=urn:ihe:iti:bppc:2007	Consent.status = active Consent.scope = patient-privacy Consent.provision[0].type = permit | deny	DocumentEntry.formatCode=urn:ihe:iti:bppc:2007
notes		unclear how negative consents are really supported. If one points at a "OPT-OUT" policy, what goes into the Consent.provision[0].type? A "permit" seems wrong as you are not permitting "OPT-OUT". Yet a "deny" also seems wrong as you are not applying a double-negative --> NOT "OPT-OUT"

APPC - Advanced Patient Privacy Consents Profile

APPC could also be mapped similar in two additional variations. These variations leverage the fact that APPC is a profile of the XACML language, and thus is a rich language for encoding policy rules. Thus where Consent has a complex set of .provision.provision nesting, this would not be used. Rather the XACML encoding would be used. In this case the Consent is mostly a method for managing the consents and not for encoding the rules; that is that the rules would be encoded in XACML and managed as XACML encoding. Likely encoding that are pushed into the XACML engine and thus only externally referenced by each policy set unique identifier.

The two variations are:

• Where the FHIR Consent is similar to above, where Consent.policy.uri points at a base policy, but the deviations from that policy would be encoded in APPC (XACML) and that is pointed  by Consent.source[x]
• This model optimizes on maintenance at the expense of much less optimal run-time decision making
• Where the FHIR Consent is very sparsly populated with Consent.policy.uri pointing at a patient specific instance of APPC (XACML). Meaning where above this uri value is from a small pre-published policies that are chosen from, in this case each Consent instance has a unique uri as each one has encoded policy using XACML language. The drawback is that one must look inside to see all the context, which is not a problem when one is relying on XACML enforcement engines which would need this in XACML anyway. 
• This model optimizes on run-time decision use of XACML, and is harder to do the maintenance (new consent, replacement consent, expiration, etc)

Performance

ALL of these and other solutions need careful design considerations to make access control decisions accurate and fast. This often means that these run time decisions are not processing the FHIR or XDS data, but rather each time a policy is changed, that change is pushed to the access control decision engine for ingestion into that engine's system.

Scaling #FHIR authorization in a multiple organization HIE

In my last article on  Controlled Exchange Architecture Models for Scale on #FHIR. One issue I ran into is the question of how OAuth at healthcare scale works when an HIE is made up of multiple organizations in a federation. 

In XDS environment we describe that the SAML assertion in the transaction is authenticating the Organization requesting the information, it includes PurposeOfUse, and it includes user identity that triggered the request. We are careful to distinguish that this is an organizational assertion vs a user assertion. This is important as in an HIE the data returned is not exclusive to that user, but will be used by the whole organization.

Further in an XDS environment, this is a community of organizations. The trust framework (Affinity Domain) is based on organizational participation. These organizations, as part of that trust-domain, agree to rules of user authentication and user authorization. They agree that they will not issue a cross-enterprise transaction unless they have appropriately authenticated the user, and that they have proven that user has authorization to initialize the transaction. They also agree that any data returned will not be used for any other PurposeOfUse beyond that asserted in the XUA.

This is an important part of how HIE scale. 

• First because requests from organizations are often the whole organization, not limited to the user who triggered the request
• Second because to use user level assertions would require that all services (Registry, Repository, etc) would need to keep a user database that is inclusive of all possible past/current users.

The drawback is that consents within an HIE are limited to blinding of external organizations (they can still have user level blinding within their organization). This seems like a big issue, but it is often impossible for one organization to know the identity of a user at another organization with sufficient accuracy. There are alternatives, just not realistic in a reasonable deployment.

This was originally said in the appendix as part of XDS, but was further elaborated on in the HIE white paper (see section 6).

https://www.ihe.net/Technical_Framework/upload/IHE_ITI_White-Paper_Enabling-doc-sharing-through-IHE-Profiles_Rev1-0_2012-01-24.pdf  

It is not to say that SAML can't be a user assertion, but rather that there is a well understood model of XUA for use in an HIE.  We don't address how an HIE might switch to user level., mostly because no one has asked.  There are some that 'think' they are using user level assertions, and they continue to think that the results returned would only be used by that user. There might be some cases where this is true, and it would be good to express these as different. One usually needs to know something about the organization requesting to understand if the requests are restricted to the user or not.   There are mechanisms where transactions can carry multiple assertions. There are mechanisms where results can carry restrictions (obligations). These are all theoretical solutions, not practical in reality. These are all much more advance than we should try to support at this time.

OAuth tends to be described as authorization statement about the client application and/or user using that application. The typical deployment of OAuth, like shown in SMART-on-FHIR, is to deploy an OAuth authority next-to the resource server to make authorization decisions. That authorization decision is often cascaded to OpenID-Connect to get the user identity, and the expectation is that a decision will be made wrapped in the OAuth token with scopes. These discussions are very user focused. 

However sometimes OAuth is intended to be used between organizations, such as in bulk-data transfer. Or my use-case of an HIE. In these cases the token is not representing a user, but rather an organizational service.

SO to support an HIE that scales to many organizational partners in the community. We need an OAuth token (IUA profile) that is architecturally similar. My original vision of IUA was this, but I am not sure this came through in the text. This is why we did not include where the OAuth authority existed. This is why we focused on JWT, and made it a set of attributes. This is why we left unsaid the authority model that a recipient would use to confirm that the token was legitimate.

Do we need a distinction between a single domain use of IUA where the assertions are authorizing the user and client ONLY; and another which is a cross-enterprise where the assertions are authorizing an organization (client) and including user identity only as the triggering agent?

Or am I missing a solution due to my ignorance? If so, please comment.