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.

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.

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

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?

• IHE International YouTube channel - https://www.youtube.com/user/IHEIntl
• IHE-USA intro - YouTube - https://www.youtube.com/watch?v=BaN1DuVY3go
• General overview - YouTube - https://www.youtube.com/watch?v=hAgjlMmiaLY
• General Introduction to IHE - https://www.ihe.net/resources/technical_frameworks/#GenIntro
• Actors, Transactions, Namespaces, Glossary, Profiling, and Integration Statements
• Connectathon - YouTube - https://www.youtube.com/watch?v=ozHb9gm1nws
• Governance Process - https://wiki.ihe.net/index.php/Process
• Continuous Development Process - https://wiki.ihe.net/index.php/ITI_Continuous_Development 
• Committees - https://wiki.ihe.net/index.php/Committees
• Profiles - https://wiki.ihe.net/index.php/Profiles

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

• Document Sharing - YouTube -- https://www.youtube.com/watch?v=VG1oF5FEijY
• Metadata handbook - https://wiki.ihe.net/index.php/Metadata_Handbook
• All the Document Sharing profiles https://wiki.ihe.net/index.php/Category:DocShare
• White-Paper Enabling doc sharing through IHE Profiles
• White-Paper XDS Affinity Domain Template
• White-Paper HIT Standards for HIM Practices
• White-Paper Access Control
• My Blog topic on Document Sharing 

Is it IHE work on FHIR?

• FHIR Profiles https://wiki.ihe.net/index.php/Category:FHIR
• MHD - YouTube - https://www.youtube.com/watch?v=ZpQrHI3VVxY
• mXDE - YouTube - https://www.youtube.com/watch?v=o24WQgxiYVI
• Guidance to IHE profile authors when profiling FHIR  https://wiki.ihe.net/index.php/Guidance_on_writing_Profiles_of_FHIR
• My Blog topic on FHIR

Advanced work by ITI

• IHE GitHub - https://github.com/IHE
• IHE FHIR conformance resources - https://github.com/IHE/fhir

All of my blog topics

HL7 Tutorial - FHIR Privacy and Security

Updated: I  gave a tutorial at the HL7 workgroup meeting in Atlanta. My scheduled tutorial covered two quarters, about 3 hours.

My slides can be found at http://bit.ly/FHIR-SecPriv .Published slides as open under Creative Commons Attribution - NonCommercial-ShareAlike 3.0 Unported License.

Please feel free to ask questions about these topics, that might inspire me to blog on that question. I am not sure I will be creating a "bloginar" of these slides, but it seems right.

Not Hacking

Unfortunately I did not provide a description for my tutorial, so what is published in the HL7 tutorial guide is based on a previous tutorial. This is totally my mistake, please don't blame HL7. That tutorial was more focused on hacking a FHIR Server. I hope that people that signed up for my tutorial are not expecting this described detail. I recommend many general IT resources for how to hack a http service:

• Coursera has a set of courses on "Ethical Hacking"
• Linked In Learning also has Ethical Hacker 
• SANS has Network Penetration Testing and Ethical Hacking
• CompTIA
• etc...

So, if that is what you want... sorry... but if that is what you want, then there are much more excellent resources than HL7 would ever be able to provide.

SMART-on-FHIR

During the HL7 Workgroup meeting there will be a good tutorials on how to use SMART-on-FHIR specifically. This tutorial will be given Monday afternoon titled "HL7 FHIR Using SMART & CDS Hooks (M1)". 

My FHIR Security and Privacy (TH15) tutorial

Background on Privacy and Security as it relates to the technology stack that FHIR is based on, specific Security and Privacy capabilities built into FHIR, and practical implementations of these capabilities on a set of use-cases. 

Here is my agenda made up of three parts. This is far more than can be accomplished, so I will adjust what I spend most time on based on the interest and competency of those in the tutorial

Part 1 - Basics

• Security Principles
• Privacy Principles
• Basic Security and Privacy Considerations in FHIR
• Anonymous Read
• Business Sensitive
• Individual Sensitive
• Patient Sensitive
• Not Classified
• Secure Communication of FHIR -- HTTP[S] - TLS
• Authentication & Authorization
• SMART on FHIR
• IUA
• Mutual-Authenticated TLS
• Access Denied Responses

Part 2 - FHIR capability

• Provenance
• Basic
• Digital Signature
• Audit Logging
• Audit Reporting
• Audit Purging
• Consent - for Privacy
• HEART
• Attribute Based Access Control
• Security Tags
• Compartments / Clearance
• Obligations
• Break-Glass
• De-Identification

Part 3 - Practical application

• Provider Directory
• Guide Management
• Extra-Sensitive Treatment
• De-Identified Research

The Patient Innovator Track at DevDays - Privacy

I assume anyone reading my blog has already seen this announcement on FireLy, Grahame, HL7, Hay on FHIR, etc. Go read those for the specific details, no good reason for me to duplicate them.

What I will do is focus on the opportunity for Patient to drive for Innovations in Privacy. Most of the other blogs are focusing on the Patient being the Innovator at "using" their data. This is the most powerful thing that Patient access using FHIR enables, by giving high quality and fully coded data into the hands of the Patient... so that the Patient can call upon a vast future set of applications that can enhance their Patient health (and safety).

Patient Privacy enhancements can also happen. When I reference Patient Privacy I am not just speaking of "Confidentiality" or "Consent". I am speaking to all of the Privacy Principles.  Here is the list summarized:

The OECD Privacy Principles are as good as any to review

1. Collection Limitation Principle -- There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.
2. Data Quality Principle -- Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.
3. Purpose Specification Principle -- The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.
4. Use Limitation Principle -- Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except: a) with the consent of the data subject; or b) by the authority of law.
5. Security Safeguards Principle -- Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.
6. Openness Principle -- There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.
7. Individual Participation Principle -- An individual should have the right:a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him; b) to have communicated to him, data relating to him within a reasonable time; at a charge, if any, that is not excessive; in a reasonable manner; and in a form that is readily intelligible to him; c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to challenge such denial; and d) to challenge data relating to him and, if the challenge is successful to have the data erased, rectified, completed or amended.
8. Accountability Principle -- A data controller should be accountable for complying with measures which give effect to the principles stated above.

It isn't even as simple as these 8 Privacy Principles. There are regional nuances, personal decisions, concerns for safety/health, etc. Often times there is complaints that these Privacy Principles get in the way of Medical Ethics the actual cases of conflict are few and usually well understood by those affected.

I included all the Privacy Principles, although most will think that they-as-a-patient have very little control over these. This might be true, but "Innovation" comes from creative thinking. So I challenge the Patient Innovators with the full set of Privacy Principles. 

One that I am working on, with the help from my fresh college graduate son (please hire him), is an app that helps keep the Patient informed of how, and when their data are used. 

Finding Gaps in the specification and implementations:

As with all of the innovations in FHIR, the road is not always smooth. We are uncovering issues in the FHIR specification, issues in common implementations of FHIR Servers, and misunderstandings all around. These gaps are the important thing to uncover at this point in the FHIR Maturity. So please speak up when you uncover a gap. Now is not the time to be held back by a gap, or to 'hack' around the gap. Hit the gap head-on.

Tipping point in Health Interoperability Maturity

In the past two weeks I have been in large audience discussions where there is a very different kind of topic being discussed around Health Information Technology. The topic is about a vision of how things could/should be at the point of care because of successful interoperability. It is not explicitly said that way. These discussions are around better safety, better treatment, better efficiency, better outcomes, etc.

Historically discussions in Health IT have been around very basic interoperability fundamentals. Things like basic security, basic medical data (Allergies, Problems, Medications, etc), basic medical summary, basic episode/discharge summary. These things have been the focus of the past 10 years. These things have been greatly supported by current Health Information Exchange (IHE Document Sharing using XDS/XCPD/XCA). These things are accelerated by FHIR and US-Core.

These existing Health IT Interoperability are supported by basic security and privacy models. Things like IHE ATNA, XUA, BPPC; as well as the FHIR solutions of SMART-on-FHIR. Everyone is so very comfortable with using Mutually-Authenticated-TLS, and Digital Certificates. There is an understanding of how to handle patient consent in the context of Treatment workflows (mostly a custodian side problem that is handled in-house of that custodian).

Maturity

These basic interop solutions are not without issues, but they are mature enough that there is a totally new discussion that is starting with "So, now that we have basic interop, what more can be done?"

These more discussions are happening around new PurposeOfUse beyond just Treatment. There are discussions around Payment centered Interop. There are discussions around Clinical Trials and Clinical Research (something that was done in the past but very expensively and very privately). There are discussions around the PATIENT themselves getting engaged through applications and services.

There are other domains outside core treatment that are getting engaged. Some of them are envisioning being actively engaged in the Health IT, like through a Care Plan. Some of them are looking to get away from purely paper, like EMS and Transport.

There is interest in extending Health IT out to various Directories for discovering specialty treatment organizations, focused practitioners, clinics with specific equipment, etc.

There is also an interest in a large number of measurement devices to contribute to information about the patient. These might be weight scales, pedometers, heart-rate, SPO2, blood-sugar, sleep-tracking, blood-pressure, etc. (This group is scaring many as it has the capacity to overwhelm the Clinician very quickly. I assert this is more of an opportunity than a threat).

There is now discussions around Patient Consent and Authorization for various uses beyond Treatment, or even to more privacy realistic rules within Treatment use-case. There are discussions around patient delegations. There are discussion around patient using portals and applications. There are discussions around making it possible for a patient to REMOVE authorization when they want. There is discussions around empowering the patient to know how their data is being used, so that they can alert authorities when it is being used inappropriately and against their wishes.

Core Interop

Core interop is NOT done. There are plenty of further enhancements.... My blog will always be focused down at the core, and I see no end in sight. But I do see great things that the core Interop have enabled, and that excites me.

Definition

The definition of Interoperability includes this tipping point. The definitions of Interoperability do not stop at getting bits communicated, they are all very careful that the definition of Interoperability always includes that the recipient use the data to improve outcomes.

Here is a HIMSS published definition

Interoperability is the ability of different information systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders, with the goal of optimizing the health of individuals and populations.

It has never been acceptable to just communicate bits. The whole purpose of Interoperability MUST be for some end goal. Interoperability is not the goal, it is a tool to get to various goals. 

Note that previous definitions of Interoperability from HIMSS were even more focused on achieving outcomes and improving patient health and safety. 

It is very disappointing that ONC has a much more limited view on what Interoperability is. To them it is just getting bits to flow. This view is constrained by regulation text from 21st Century Cures Act. 

Here is ONC definition

According to section 4003 of the 21st Century Cures Act, the term 'interoperability,' with respect to health information technology, means such health information technology that— "(A) enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user; "(B) allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law; and "(C) does not constitute information blocking as defined in section 3022(a)."

I certainly hope that ONC updates their expectations. I think they have given the agenda at the ONC 3rd Interoperability Forum was very focused on thee higher level outcomes vs the low level means of Interoperability

Success

Success at building "core" Interoperability means that people can now dream about this second part of the definition of Interoperability, that is they can dream of "... optimizing health of individuals and populations".

FHIR Scaling to a Nation

Most discussions about FHIR are simple interaction diagrams like this:

Many Sources (n != 1)

The Real story needs to consider that the "Source" above is a single box representing 10,000 potential source systems that hold data about the patient: (map is a static view of CareQuality network)

More important is that the above map only represents Clinical sources. There are also Payer sources, and many more...

So there is a real scale problem with the above.

If we look at the use-case of Treatment needing to get a current view of data. We could imagine that EACH of these Sources will publish a FHIR endpoint and publish US-Core based Common Clinical Data Set (CCDS). Thus your Source system will need to query them all.

The diagram is not all that more complex as in a sequence diagram we just add a loop. But we all need to understand that loop is multiplied by all sites that indicate the patent has data

Combining Many Sources

You will note that EACH Consumer system needs to do some detailed combination of the results.

1.  Hope all provide well constrained (e.g. US-Core)
• need to be robust to variations
2.  Combine current data from many sources, 
• leverage any List indicating reconciled at that site
• hope republished data preserved original id
• resolving duplicates 
• leverage any Provenance indicating duplicate resolution
3.  resolving invalidated deactivate
•  watching age and Provenance
4.  harmonize vocabulary differences
5.  Provide Provenance back to source REST resources

Not everyone will publish US-Core level resources

Reality is that many of the sites won't provide US-Core level access, but will only provide Documents. Best-case is that it is a On-Demand Medical Summary, which does cover the same data and does provide only current data. But may be a set of discharge summary, or episode documents.

So one might need to combine REST access with Document content.  One could optimize to NOT pull documents from sites that provided REST access to current data.

I show this being implemented by an Intermediary. I am not proposing a common Intermediary, although that is possible. I suspect that these Intermediary will have organizational customization. That is that the Consumer organization will want to control the algorithm and output. Thus the Intermediary is likely as many as there are Consuming organizations. This might be able to be generalized for a region. But the more one moves it to a central position, the more one creates potential Privacy concerns.

NOT fully discussed here 

I did not address how the sub-set of sites that have data on this patient are discoverd. There likely needs to be some level of Federated search, or centralized Record Locator, or a combination of both.

I did not address how security is addressed. There could be a national managed security infrastructure, but that is another kind of scale problem. It is possible, but not addressed in this article.

I did not address how Privacy is addressed. I expect that this will continue to be a Source side management. That is that each Source manages their responsibility to protect the data and to release it as appropriate according to the Consent they have on file. There likely is a need for "Point-of-Care Consent".

Likely many more too

----------------------------------- websequence diagram source ---------------------------

title Interop tendency

participant Source
participant Intermediary
participant Consumer

note left of Source: Broad tendency

loop Current Details
note right of Source: Many sources for each site patient Visited
Source->Consumer: FHIR REST
note right of Source
 Note that results can include 
 DocumentReference to documents flow
end note
end

loop Discharge or Episode or Problem or CarePlan or Notes
note right of Source
 Targeted to one document sources or all
 Clinical Documents cover 5 Principles 
 * Persistence
 * Wholeness 
 * Stewardship  
 * Context 
 * Potential for authentication
 Documents could be CDA or FHIR documents
 Not optimial but may be TEXT or PDF 
 Transport can be XD* or MHD (FHIR DocumentReference)
end note
Source->Consumer: FHIR/CDA Document

end


loop Population on a cohort
note right of Source: Many sources

Source->Consumer: FHIR Bulk access
end

note left of Source
 Comprehensive view 
 using Intermediary
end note
opt Reconcilled
Consumer->+Intermediary: Request for data
loop over all sites with current
Source->Intermediary: REST
note left of Intermediary
 Hope all provide well constrained (e.g. US-Core)
 Combine current from many sources, 
 * leverage any List indicating harmonized
 * resolving duplicates, 
 ** leverage any Provenance indicating duplicate resolution
 * resolving invalidated deactivate
 ** watching age and Provenance
 * harmonize vocabulary differences
 Provide Provenance back to source REST resources
end note
end
loop over all sites with Documents 
note left of Intermediary: e.g. IHE mXDE Profile
Source->Intermediary: Document
note left of Intermediary
 Decompose Documents
 Combine document data with current
 Provide Provenance back to source Document
end note 
end
Intermediary->-Consumer: FHIR REST
end