Tuesday, January 21, 2020

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





Thursday, January 2, 2020

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


Tuesday, December 3, 2019

Sydney - HL7 FHIR Privacy and Security Tutorial

I will be giving the FHIR Privacy and Security tutorial again at Sydney HL7 meeting on Thursday afternoon (our normal Wednesday afternoon agenda slot). See
https://hl7.sydney/tutorials.php

As always I welcome any suggestions for improving the slides. They can be viewed freely on my blog at : HL7 Tutorial - FHIR Privacy and Security

Given that I have more properly registered my tutorial (rather than filling in at last minute); I will be removing some bulk from Part 1, and making Part 3 more prominent. The removal of bulk in Part 1 will mostly be talking less about it, and leaving it more to the audience to review on their own.

Friday, November 22, 2019

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

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
  • 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 mechanismBPPC in MHDBPPC in FHIR ConsentBPPC in XDS
Resource TypeFHIR DocumentReferenceFHIR ConsentXDS Document Entry
type identifierDocumentReference.code = LOINC “57016-8”Consent.category = LOINC “57016-8”DocumentEntry.typeCode = LOINC “57016-8”
1) Identify who the Patient isDocumentReference.subject = Reference(Patient)Consent.patient = Reference(Patient)DocumentEntry.patientId
2) What organization is bound by this ConsentDocumentReference.author = Reference(Organization)Consent.performer = Reference(Organization)
Consent.organization=Reference(Organization)
Consent.provision[0].actor.reference=Reference(Organization)
DocumentEntry.author
3) Policy being acknowledgedDocumentReference.context.eventConsent.policy.uriDocumentEntry.eventCodeList
4) Time period that the Consent is validDocumentReference.context.periodConsent.provision[0].periodDocumentEntry.serviceStartTime <=>.serviceStopTime
5) When consent happenedDocumentReference.content.attachment.creationConsent.dateTimeDocumentEntry.creationTime
6) What PurposeOfUse this applies toDocumentReference.securityLabelDocumentReference.provision[0].purposeDocumentEntry.confidentialityCode
7) Copy of the signed policyDocumentReference.content.attachment.urlTwo Alternatives
A) Consent.sourceAttachment
B) Consent.sourceReference = Reference(DocumentReference)
DocumentEntry.URI
8) Replacing previous choiceFHIR 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 valuesDocumentReference.content.format=urn:ihe:iti:bppc:2007Consent.status = active
Consent.scope = patient-privacy
Consent.provision[0].type = permit | deny
DocumentEntry.formatCode=urn:ihe:iti:bppc:2007
notesunclear 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.

Tuesday, October 29, 2019

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

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.


Thursday, October 24, 2019

Controlled Exchange Architecture Models for Scale on #FHIR

In the previous article I discuss the various Modes of Patient Centric Exchange models. I cover Mediated Exchange, Directed Exchange, and Negotiated Exchange. These are all good solutions for scaling, but fail when the patient doesn't actively get engaged. When a patient wants to actively get engaged they MUST be given their damn data.

Reminder that I am discussing how to scale Patient Centric Exchanges given the following challenges:
  1. How do I find all the data holders for a given Patient?
  2. How do I prove I am secure and trustworthy?
  3. How do I get data and assure it is authentic?
There are more challenges, but this article is long enough with these big three.

Controlled Exchange --
where the Patient does not get directly involved in the communication, but should be understanding of the communication and possibly have control. over that communication ---- Like using Health Exchange between Provider organizations Controlled Exchange can scale for both those patients that are active participants and for those that simply want the system to work without them doing anything. BUT, Controlled Exchange scaling requires architecture.

The Controlled Exchange is the dominant model preference by Clinicians, Payers, Population Health, and Data Analytics organizations. As it enables access to data without the Patient being an active participant. These exchanges often have regulated exceptions to Patient Control. They tend to be the preference of these organizations with excuses like the need to have full-fidelity of the data to enable patient and clinician safety, to enable access when the patient is not conscious, and to protect the population at large. This model is the only one that 'could' support a "Break-Glass" function. This is often seen as paternalistic, but can also be seen as anti-Privacy.

Quality: In the Controlled Exchange there is some governance. This governance might be strong (Central), moderate (Federated) . So there is no guarantee that these are perfect quality.

Authenticity: In the Controlled Exchange there is end-to-end path of the data, so authenticity can be discovered. It is not strong in some cases, but there is a much more distinct action where authenticity is found to be failed. Digital-Signatures might be more likely to succeed in a Controlled Exchange.

Controlled Exchange Architecture Models for Scale

Within Controlled Exchange there are multiple Architectures available. The overall models between XD* and FHIR are the same. There are two basic architectures: Centralized Administration vs Federated Administrative.

  • Centralized Administration - there is a single central authority for a trust domain, organizations, patient identity, and data quality rules. -- Examples: XDS 
  • Federated Administration -  there is a directory of participating organizations and there is management of the trust domain; less control of data quality. -- Examples: XCA
  • Centralized data - there is a single database that everyone uses for all storage and access. I don't see this as legitimate as it would require far too many policy and regulation changes; and it would not really solve enough problems for this overhead.
  • Decentralized - this is actually a Negotiated, or Directed exchange model; as the patient must point at where their data are.

Centralized Administration

In XDS 

This architecture is long standing Document Sharing Health Information Exchange based around PIX and XDS. Participating organizations would provide Patient Identity information to a central Patient Identity Manager, and publish document metadata to a centralized Document Registry.  Thus enabling discovery of cross-referenced patient identity, and discovery of documents related to that patient.
  1. PIX: 
    1. use of patient identity feed of demographics and identifiers on all patient registration events to a central authority who correlates patients into a cross-reference and assigns a centrally managed patient ID (Affinity Domain ID)
      1. minimally: their local patient identifier, and national identifier
      2. optionally: patient demographics (quality criteria)
    2. query given local patient identity to get central authority identifier (Affinity Domain ID)
    3. optionally a query on demographics (PDQ)
  2. ATNA + XUA: 
    1. Certificate Authority (CA) manages certificate trusts: TLS and SAML
    2. point-to-point mutually-authenticated and encrypted connections (one or more certificate authorities)
    3. audit log is managed for all transactions and other security/privacy relevant events  
    4. transactions carry assertion of requesting organization, user, and purposeOfUse
    5. assertions signed by a federation of assertion providers (one or more authorities)
  3. XDS: 
    1. One central Registry 
    2. query given the central authority patient identifier (Affinity Domain ID)
      1. results indicate data holding organization and location of the data (repository)
    3. on publication of new data, Registry enforces a set metadata and document formats: 
      1. Metadata Handbook and selection of CDA or FHIR document profiles
    4. metadata is all that can be queried upon, and is all that is centralized
    5. Repository holds the documents. May be one central Repository, or many distributed at the data source organizations
    6. CDA or FHIR documents (see mXDE)
Note: participants are usually manually configured into PIX and XDS Registry authority, This is usually done as the quality of the edge systems usually need to be strongly confirmed. Usually less than 100 endpoints to manage per Affinity Domain. A directory could be used like HPD or CSD.

detailed webSequence Diagram available

In FHIR

Following the architecture similar to XDS, one would have a central Patient Identity management function represented by the PRIM profile, and a centralized Document Metadata Registry. There is a project underway in IHE to develop a centralized Document Metadata Registry. Same diagram would work.

  1. PRIM + mCSD
    1. See this article on Patient Identity Management using FHIR
    2. all organizations feed Patient updates upon registration to a central authority. 
      1. minimally their patient identifier, national identifier, and managing organization
      2. usually also includes some set of demographics (quality criteria)
    3. central authority manages a master patient identity (like Affinity Domain ID)
    4. query given local patient id to get master patient identity (PIXm) 
    5. optionally a query on demographics (PDQm)
    6. master patient identity includes managing organization
  2. ATNA + IUA
    1. With REST the TLS tends to be just server side, but does still cover authenticity of the server to assure one is going to the destination they wanted to go to, encryption of all traffic, and integrity validation of that traffic.
    2. Audit Logging can be done using the ATNA method now supported with FHIR AuditEvent
      1. alternative is logs are kept locally and one can as needed uset the ATNA method now supported to do queries against FHIR AuditEvent
    3. Client authenticity is the struggle
      1. If we assume that for every organization within the domain, that they have a client_id and thus client_secret for all outbound requests
    4. User at a Client is even harder
      1. cascading of OAuth would be very combersome
    5. When Source or Recipient is communicating to Registry
      1. IUA model (unlike SMART) presumes that the requesting actor knows to preemptively get a token from the authority recognized by the Registry. This is similar model to XUA. Thus the requesting actor would take the local knowledge of the user and organization, and send that to the OAuth authority
        1. One model has this initiated by way of a SAML token
      2. get OAuth (IUA) token from Registry defined OAuth authority
      3. that OAuth authority reflects OpenID-Connect back to requesting organization
      4. not clear how trust is built between all these
    6. When Recipient is communicating to Source
      1. get OAuth (IUA) token from Source defined OAuth authority
      2. not clear how the source cascades to somewhere trustworhy. This is likely some centrally managed OAuth authority that cascades to 

  3. MHD or QEDm (or mXDE)
    1. for each FHIR endpoint with MHD support or QEDm support
I tried to figure out how the SMART model would work, and fail as it seems to require a known identity at each endpoint. This identity might just be an account associated with an identity, but there seems to need to be an identity established. I am not sure how that scales. The OpenID-Connect mechanism leads us to the ability for it to scale, but seems to create a local account for every new identity. This certainly could be done, but is it really needed given that the request is coming from a remotely approved identity that may never re-connect. Might the client identity be only organizations, and no users?

detailed webSequence Diagram available

CommonWell variant for multiple Communities

I'm including this as I know of this architecture, but I am not an expert.

CommonWell has centralized administration, they support this for a set of XCA communities. XCA protocol is designed to be a federation protocol, but CommonWell has implemented central administrative services. This is my understanding of the CommonWell RLS, which I understand acts like a PIX manager for many communities, and where XCA queries are initiated as if one is looking for their own patient Identity and the infrastructure uses the RLS to fan-out the queries to everyone they know about. Please correct me if I am wrong.
  1. PIX 
    1. feed to create cross-reference. (yes, HL7 v2 ADT feed, which has the advantage of informing them of activity at a organization/community even if no data are created)
    2. recipients don't need to lookup patient identity, they will just use the one they know
  2. ATNA + XUA
    1. i don't think they support audit log repository
  3. XCA
    1. XCA query is done given the local patient identity
    2. infrastructure uses the RLS to fan-out queries to all communities/organizations they know
    3. results are returned
Might there be a similar model for FHIR? The difference from above is that the query for data would go to one intermediary that would fan-out the query to many source services and combine the results. 

Federation

In XCA -- 

  1. CSD + XCPD: directory of participating organizations in the federation and their endpoints
  2. ATNA + XUA (alternative end-to-end web-services security and AS4)
  3. XCA
These get progressively more difficult to diagram without oversimplification

In FHIR - Federated

  1. mCSD + (PIXm | PDQm)
    1. master directory of all possible endpoints where data might exist
    2. query each endpoint for patient records
      1. hopefully there is a national patient ID to give deterministic positive results with very low false-positive and very low false-negative
    3. for each Patient returned
      1. given the Patient.managingOrganization lookup
    1. PRIM + mCSD
      1. See this article on Patient Identity Management using FHIR
      2. all organizations feed Patient updates upon registration to a central authority. 
        1. minimally their patient identifier, national identifier, and managing organization
        2. usually also includes some set of demographics (quality criteria)
      3. central authority manages a master patient identity (like Affinity Domain ID)
      4. query given local patient id to get master patient identity (PIXm) 
      5. optionally a query on demographics (PDQm)
      6. master patient identity includes managing organization
    2. ATNA + IUA (or SMART)
      1. at each Patient found
        1. Patient.managingOrganization points at an Organization
        2. Organization.endpoint will point at a set of endpoints
        3. for Endpoint.status == active
          1. Endpoint.connectionType == hl7-fhir-rest 
            1. get endpont's CapabilityStatement 
              1. and confirm support for (3) queries desired
              2. and confirm support for security model desired
            2. look at this endpoint for OAuth authority
              1. use OAuth to get authorization token
                1. likely cascaded to your organization
    3. MHD or QEDm (or mXDE)
      1. for each FHIR endpoint with MHD support or QEDm support
detailed webSequence Diagram available

In FHIR - Decentralized Federation -- BlockChain Negotiation

Imagine a decentralized model such as would be used for the Negotiated Exchange. Where the Patient gets the choice of which service to put their data. The Patient thus manages who has access to their data. 

The difference from purely Negotiated Exchange is that the patient publishes the location(s) of their data into a decentralized service. Such as a blockchain ledger.  The Patient relationship with a data source or recipient (Clinician, Payer, or Researcher) is bounded by assertions on the blockchain. Thus the Patient is not discoverable unless the Patient chooses to be found, and then a blockchain contract with terms of the relationship can bind a source/recipient access to the data.

I thus don't see this one as really a Federation, but put it here for completeness sake.

Conclusion

The one thing that gets in the way of scale, is client side user identity. I think there would need to be a trust domain, so as to enable this trust without replication of user accounts that have no added value.

Nationwide Health Information Exchange on #FHIR

Most use of FHIR today is as an API to an organizations health information (EHR). This solution is maturing nicely, although it has issues that are being worked on. However what is being asked latey is how does one scale FHIR to a nation. I spoke of this scale problem in past articles. It is very different than the scale success that REST is often sited as solving, which is one server to millions of clients. In healthcare we have 100s thousands of servers to millions of clients; and likely 10s thousands of intermediaries.

I have plenty of articles on how a Nationwide Health Information Exchange (HIE) could be built with the IHE XD* family of profiles. What is missing is a similar architecture for HL7 FHIR family of technology. I will show a few alternatives, none of them have been tried, as far as I know. The alternatives are inspired by what is working well in the IHE XD* family, but using FHIR. So I do expect new alternatives to come up, I just have not seen any evidence of fundamental new alternatives.

There are various challenges at the scale of a nationwide health information exchange:
  1. How do I find all the data holders for a given Patient?
  2. How do I prove I am secure and trustworthy?
  3. How do I get data and assure it is authentic?
There are more challenges, but this article is long enough with these big three.

Patient Centric

When it comes to Patient Data exchange, I want us to be inclusive of "Mediated" exchange, "Directed" exchange, "Controlled" exchange, and "Negotiated" exchange. I have not seen these formally defined elsewhere, I first defined them here


Note the diagrams below are "one" rendering, there could be variations not shown. The diagrams are abstract, thus not representing exactly network transactions. The text in courier font are the essential source for WebSequence Diagram rendering.

Mediated Exchange -- 

where the Patient themselves is an active part of the communication pathway. Such as carrying the data within their possession, using a personal device and application, --- Such as using a phone resident App using FHIR to download their data, then upload that data to some recipient. Mediated might also be by way of a Cloud service that is completely controlled by the Patient (PHR model)

loop get data
Patient->+Source: Request for data
Source->-Patient: data
end

loop gives data 
Patient->+Recipient: Give data
Recipient->-Patient: Thanks for data 
end

Directed Exchange -- 

where the Patient actively requests that the information flow to a selected destination. --- Such as a patient using Direct Secure Messaging, or where a patient requests that the data be pushed.

loop send data
Patient->+Source: Request for data to be sent

Source->+Recipient: Give data
Recipient->-Source: Thanks for data 

Source->-Patient: data has been sent
end

Negotiated Exchange --

where the Patient themselves connects two parties and authorizes the flow between those two parties. --- This might use the HEART standard for authorization, and FHIR apps.

Patient->Recipient: I have data at Source

loop for all the data
Recipient->+Source: Ask for data 
Source->+Patient: is this Recipient authorized for this data?
Patient->-Source: yes
Source->-Recipient: Here are data
end

Controlled Exchange --

where the Patient does not get directly involved in the communication, but should be understanding of the communication and possibly have control. over that communication. The discovery of the data locations is architecture specific. --- Like using Health Exchange between Provider organizations

Recipient-->Source: Discover data

loop for all the dataRecipient->+Source: Ask for data Source->+Patient: is this Recipient authorized for this data?Patient->-Source: yesSource->-Recipient: Here are dataend

All data movement only by authorization by the Patient

In all of these models there is NO movement of the data except through authorization by the Patient. This is the fundamental of "Patient Centric". They each 'should' offer the same level of Patient control, right down to the ability to permit or deny access to any specific data. They each 'could' provide the recipient proof of integrity, authenticity, and provenance. They each can do this, but they each can also fail to do this. They differ in technical mechanics, and thus they differ in how well supported these factors are.

Mediated, Direct, and Negotiated Exchange Models

Mediated, Directed, and Negotiated scale only when the population of patients chooses to take an active role. Some patients are very active, most are not. Those that are active should be given their damn data.

So for our three factors:
  1. The patient themselves through direct action makes the connection. The patient must have a direct relationship with both parties. (yeah, I know someone is going to say the patient will hide data they don't want shared. yes, they will. I assert they can do this in ALL correctly patient centric models)
  2. The patient themselves decides who to share their data with. (yeah, I know someone is going to say that the patient is ignorant and can't be trusted. This is a tired, and paternalistic, position that is getting in the way of progress while not having any proof. I assert that if a patient has taken action, it should be done. )
  3. The patient themselves directs the exchange of data.
Quality: In these models there is no overall governance that could assure quality of the data. So a recipient is stuck with the format and quality of the data they are given. 

Authenticity: In these models, the biggest technical problem is "Trust of the data received". The place where this breaks down is when the direct relationship is with the destination, and that destination needs to understand the trustworthiness of the source data. The Direct Exchange and Negotiated Exchange have mechanisms under which the destination understands the source identity and can thus build "Trust" on that.  The backup solution is that the recipient organization uses some out-of-band mechanism to confirm the data prior to accepting it. This might be a conversation between the clinician and the patient; conversation between the clinician and the source organization.

Digital-Signature: There are digital-signature technologies that could be used, but they require that there is a trust-domain of all possible signatories and their legitimate role in signing legitimate content in a given context. Provided there is a trust-domain for signatures, then digitally signing all content will work regardless of how the data are transported. I am a fan of digital-signatures, but they often fail for policy, procedure, and human reasons.

Funding: I am not sure how any of these models are economical. That is, who pays for the mechanics of scale. The mechanics are small, but they are not zero; and we have seen many PHR products fail due to no ability to have a legitimate funding model.  The hidden costs is that the health data keep growing larger and larger, while engagement by the patient falls off.

  • Mediated -- the storage is either on an app held by the patient, or in the cloud. On app storage is limited by the storage of the device, but this likely scales reasonably. On cloud storage has a very low cost of bytes, but does need to deal with eventual purge of the data when the patient expires.
  • Directed -- this is currently funded by Provider-to-Provider use-cases, which is getting in the way of being offered to the Patient. So we already see how the funding model of Directed is a problem.
  • Negotiated -- the funding problem here is on how to fund the negotiation infrastructure. This is a problem that the HEART community is having today.  

Conclusion on Mediated, Directed, and Negotiated 

These only scale to the extent that the population of patients engages. I think that if the full population engaged, these solutions would technically scale. However I think that there are too few patients that want to be this engaged.

The issues around Quality and Funding are major problems.

Controlled Exchange Architecture Models

Controlled Exchange can scale for both those patients that are active participants and for those that simply want the system to work without them doing anything. BUT, Controlled Exchange scaling requires architecture.

The Controlled Exchange is the dominant model preference by Clinicians, Payers, Population Health, and Data Analytics organizations. As it enables access to data without the Patient being an active participant. These exchanges often have regulated exceptions to Patient Control. They tend to be the preference of these organizations with excuses like the need to have full-fidelity of the data to enable patient and clinician safety, to enable access when the patient is not conscious, and to protect the population at large. This model is the only one that 'could' support a "Break-Glass" function. This is often seen as paternalistic, but can also be seen as anti-Privacy.

 -- Part 2: Controlled Exchange Architecture Models for Scale