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.


No comments:

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.

No comments:

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



No comments:

Wednesday, October 9, 2019

Introduction to IHE

I was asked for recommendation for a set of resources that would give a good introduction to IHE:

One always wishes they could create new material, but realistically there exists plenty of resources already published that can be leveraged:

Is it general intro to what is IHE?

Is it specific to Document Sharing (aka XDS, XCA, XDR, XDM, etc)?

Is it IHE work on FHIR?

Advanced work by ITI


All of my blog topics
No comments:
Subscribe to: Posts (Atom)