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

(See the previous article for Mediated, Directed, and Negotiated)

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