FHIR Security & Privacy activities

This is an update of what is going on in Security and Privacy in, and around, the FHIR specification. 

---------------tl;dr-----------------------

• FHIR R4 includes Security Considerations classification

• SMART-on-FHIR first flavor is Normative

• Addition of X-Provenance and X-Consent http headers

• GDPR assessment against FHIR indicates good coverage of needs in FHIR already

• Maturing AuditEvent and Provenance to Normative by FHIR R5

• HL7 Implementation Guide on Basic Provenance (CDA and FHIR)

• IHE updated ATNA to include FHIR AuditEvent feed and query

• Signature datatype not likely to be R5 normative candidate

-----------------Details -----------------------

Overall Security Considerations:

The FHIR R4 specification now has an overall Security Consideration Classification. This spans the whole of the FHIR specification such that each Resource is assessed into one of four buckets of Security Considerations: Patient specific, Other Identified Individual specific, Business sensitive, and Anonymous Readable. These are not mutually exclusive classifications, but rather a "tendency". That is to say that each resource could cover many of these classifications, but tends to fall into the specified classification. The main goal of the classification is to raise awareness that the FHIR specification covers use-cases other than just sensitive patient data. The Security WG set the initial assessment, but the owner of the Resource can re-classify.  Also, actual use will be context specific. There is nothing wrong with using the 'Patient" classified resources in a way that is fully anonymous because they are holding synthetic data.

GDPR driven activities:

The Security WG has done an assessment of FHIR in the context of GDPR. This has produced a white paper that is available informally today. The GDPR assessment has driven some of changes that are already in the specification, and is also driving some future changes or implementation guides. These things have not really started formally yet, but include :

• consent decision service -- to enable a FHIR Server to ask a service for Permit/Deny on an otherwise authorized request
• basic Privacy Authorization Consent IG to support freely given and informed privacy authorizing consent
• erasure operation to support GDPR and Right-to-Forget

SMART-on-FHIR:

The SMART-on-FHIR specification is now published in the basic form that is compatible with the original Argonaut version. This base-lines the standard at this starting point. There is interest in opening up for the next more advanced form of OAuth token support. One method uses a JSON Scope encoding, thus enabling far more comprehensive and complex scopes.

Maturity toward FHIR Release 5:

The Security Workgroup is going to work toward getting Provenance and AuditEvent to Normative by Release 5 (R5) of FHIR (Approximately end of 2020). This will be enabled by two different projects.  The HL7 Basic Provenance Implementation Guide, and IHE Audit Trail and Node Authentication updates to support FHIR. Signature datatype is not likely to go Normative in R5, but likely will have some advancements.

Plan to Mature Provenance:

The HL7 Basic Provenance Implementation Guide is getting started, so there is no specific conclusions yet. That said, the goal of this project is to define realistic and effective guidance on implementation of Provenance in a cross-organizational health information exchange (HIE) for the purpose of Treatment (may be Payment). This project is not addressing the Provenance requirements for within an organization. This project is not addressing ALL possible use-cases for Provenance, such as supporting Clinical Research. The most important part of the scope of this project is to set requirements that are as minimal as possible, yet effective for supporting Treatment. Counter this against a comprehensive Provenance implementation that would likely have well over a dozen Provenance records for any one clinical object record. Meaning that in a fully advanced Provenance it is very likely that Provenance is 10x the clinical data.  This Implementation Guide will drive public comment ballot, comment resolution, improvement of the core Provenance resource, and testing at Connectathon.  This is the maturity steps that the core Provenance resource needs to approach Normative in R5.

Note there are some Implementation Guides that have included Provenance guidance and constraints.

Plan to Mature AuditEvent

The IHE Audit Trail and Node Authentication (ATNA) project will help mature the core AuditEvent resource in support of Normative in R5. The ATNA profile is one of the oldest profiles in IHE, but has seen a major change to add FHIR based interactions. Last year there was an update of ATNA to add a query one could make of an Audit Repository to support reporting and alerting such as a report for Accounting of Disclosures, Access Log, and to support investigation of security and privacy incidents. This year IHE has added a AuditEvent feed support to support FHIR based applications recording AuditEvents using http RESTful FHIR create. Thus now the ATNA profile has support for recording an AuditLog, and queries.  This is going through a Public Comment ballot in the coming months, and will be setup for testing at IHE Connectathon in the future.

Advancements since R4

Provenance has not changed much yet, although there is a related abstract Provenance service ballot going through the HL7 ballot process. This abstract Provenance service work may impact the FHIR Provenance resource, but no changes have yet been proposed.

Provenance X-Header:

In FHIR R4 there is a new capability that may not be as well known. When an app is creating a FHIR Resource (for example an Observation), that application likely has a very rich understanding of the context of the creation event, so could provide a Provenance. The historic way it could do this was to either create the Observation, then create the Provenance; or it could use a Transaction to send a Bundle with both the Observation and Provenance. These do work, but there is a question of making this more easy. So there is now a http "X" header that one can use in a simple RESTful create/update to also carry the Provenance. Thus a normal http RESTful create of a new Observation can carry the app's definition of the Provenance in the http header, while the Observation is in the body. 

Consent X-Header:

A joint effort with CBCP has moved to add an X-Header to support an app asserting that a FHIR Consent authorizes the request being made. This is a http "X" header that holds the URL to the FHIR Consent. The Server is not obliged to consider the Consent, but it may consider it. That is to say that the use of this "X" header will only enable actions that the access control protecting the data also agrees with. The prime use-case for this feature is to enable a real-time point-of-care capturing of a Consent from the patient that authorizes the interaction. Where prior to having this Consent, the request would be rejected, but with appropriate proof that an informed and freely given Consent would now enable access. A similar "point of care consent" interaction is supported in some Nationwide Health Exchanges such as CareQuality.

Signature:

The Signature datatype is receiving some interest. Given that the primary function of a digital signature leverages external Digital-Signature standards such as XML-Signature and JSON Signature. Thus we are not developing the technology of Digital-Signature. In the FHIR Signature Datatype, we are just exposing in a more friendly FHIR way some of the useful attributes about the signature. The Digital-Signature validation is done using the Digital-Signature standard. A new use-case that is driving some interesting new views is one that has a context of a Provenance "Service" that is managed independently from the Clinical repository. In this case a end-user may be using a clinical Resource and use a Provenance Service to discover the Provenance of that clinical Resource. In that case the Provenance is being managed independently from the clinical Resource and the pathway the clinical Resource was communicated; then the Provenance.signature does not need to be a non-repudiation, but can be a simple integrity check (e.g. sha256). See other issues on Signature. 

IHE ITI Spring 2019

Updated with Public Comment details available here

The IHE ITI, PCC, and QRPH workgroups met in OakBrook, IL this week at the RSNA Headquarters. We still are not meeting in Treviso Italy., but we have heard that the July meeting will be in Sardinia Italy. Right before the big tourism time. Specifically we will be at the Facilities of Sardegna Ricerche at Polaris, Parco Scientifico e Tecnologico della Sardegna, in Pula (CA), Italy. Great time to join IHE and have your company send you to the meeting.

The ITI committee this week finished up one small supplement on adding Facility support to the Mobile Care Services Discovery (Provider/Services Directory). This updates the version from last meeting. 

We approved for Public Comment three brand new Supplements

1. Adding a FHIR AuditEvent feed capability to the ATNA profile. Thus the ATNA profile would now include a Query on AuditEvent to support reporting and alerting applications, and now a Feed (RESTful Create) of AuditEvent to support applications recording audit events.  This work item also updated the Query to FHIR R4, so this supplement is focused on FHIR R4. There is now good bi-directional support for the original DICOM Audit Message schema, and the FHIR AuditEvent. This gives applications flexibility on how they record auditable events. They can use:
• UDP Syslog - DICOM XML schema
• TLS/TCP Syslog - DICOM XML schema
• http/REST - FHIR JSON AuditEvent
• http/REST - FHIR XML AuditEvent
  
2. Adding support to XCA for a deferred response mode to support responding organizations that need significant time to complete a request. For example where a responding organization holds large quantities of historic paper records, which they will make available, but want specific patient request to trigger them scanning and indexing that data. In this way they can receive a request for a specific patient, they can respond that they do have data, but need a day or week to complete the request, then as they scan the data they can feed the data back in bunches.  This work is similar to a deferred mode in XCPD, and much of the technical work was done many years ago in a white paper by Karen.
   
3. Creation of a FHIR based Patient identity management system for health information exchanges. This builds on PDQm and PIXm, by adding a Feed mechanism, and a subscription to the Feed. Added to this is a set of requirements and expectations around how Merging (Link and UnLink) are to be implemented. The result is that when two identities of a Patient are linked, one become master, and all the data recorded against both are considered one Patient. This means that a system implementing the Profile will treat a query request for one of the identities as if it was a query against all the linked identities. Putting the burden of link management and comprehensiveness of the query results upon the server, so that applications don't need do multiple queries to get a comprehensive patient record.

I am confident of the text we are sending to Public Comment, but I also expect that there is a significant amount of experience we need to gain before these become final specifications. That there will be more clarifications needed based on Trial Implementation, and the use-case that drives constraints will become more clear.

There are three very short webinars by the three editors of these Public Comment versions of their supplements. In these webinars they explain the use-cases that are being addressed, how they are addressed, and specific open issues we would like the Public Comment to help us with.

The Graying, Retirements, and Renewal at Integrating the Healthcare Enterprise (IHE)

I have been involved with IHE for 20 years. So I likely am one of the 'elders'. I am graying, but not yet close enough to retirement. However this is not the case with many that were here when I first started.

The sad news is that many of the people that started IHE, and were core to the first 20 years have retired, or have been moved to new jobs that keep them from participating in IHE. Amazing resources like Ben, Charles, Elliot, Elliott, Harry, Karen, Ken, George, Gila, Manuel, Mark, Rob, etc...

The good news is that there is room at the table for new people. IHE needs and would welcome participation. You can get involved FREE by just subscribing to the mailing lists, this gives you much of the accessibility, and you CAN make contributions. However you really should JOIN, which is also not that expensive. As a member you have voting rights, can promote profile opportunities of your own, and feel good at being a member.  See the IHE Participation details.

IHE it-self is now 20 years old, so it is now reaching a maturity level that is beyond up-start. This does not mean it is irrelevant nor without improvements. IHE has been moving toward Profiling FHIR, using online publication creation tools, using GitHub, and providing a more mature Connectathon platform. The biggest change that we are attempting this year is to switch away from a annual cycle, to a continuous Profile development cycle. This enables us to work on smaller and larger projects than the annual cycle enables.

IHE is not what it was before, so please engage and help move Healthcare IT standards along. The need for IHE Profiles (aka, Implementation Guides) is critical to success of Interoperability. Standards alone are not sufficient, as they must include support for ALL use-cases. The point of an IHE Profile (Implementation Guide) is to look at a specific (yet reusable) use-case and constrain the underlying standard, fold in vocabulary, set trigger events, and set expected behaviors.

Most important fact about Standards and Profiles --> They enable everyone to set a baseline of known functionality, and build on-top-of-that. Specifically they enable things that can't be done without Interopeability. The Interoperability layer is not a feature, it is an enabling technology.

Please consider engaging with IHE.

Basic Provenance Use-cases

There is a project starting in HL7 to define an Implementation Guide for "Basic Provenance" for use with CDA and FHIR. The motivation for this project, as I understand, is to move the Healthcare industry from providing very little Provenance, to providing Provenance that provides some value.

From W3C PROV we get a very clear definition of Provenance:

Provenance is information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness.

Why Provenance?

The reason to have Provenance is because down-stream the data you create will be used by someone for some reason, and they need Provenance so that they can rely on your data. The creation of Provenance is work that must be done up-stream, and the agent doing the work to create Provenance is not benefiting from the work they are doing to create Provenance. Emphasis that created Provenance is only needed down-stream a fraction of the time. 

So, what are the most valuable down-stream use-cases where Provenance is needed, so that we can assure that up-stream provides that Provenance. Thus the use-case analysis needs to start from the down-stream use-cases to inspire the up-stream work to be done. 

Up to now, most work on Provenance has been on the up-stream use-cases, trying to inspire them to create perfect Provenance. This has failed because the up-stream use-case gains nothing from recording or providing Provenance, and thus there is no apparent value to providing Provenance. Where there is not a clear value-proposition, there will not be implementation. 

Use-case for Basic Provenance:

We could start from an infinite set of use-cases where Provenance might be needed, but we would continue to not inspire upstream implementation. So we need a sub-set of the use-cases that are clearly valuable. 

The critical question I have today is what is the "Basic" set of use-cases where data Provenance is needed, but where it is not available.  The "Basic" set needs to be understood as a reasonable sub-set of the "Comprehensive" set of use-cases where Provenance could be used. This Basic set of use-cases is critical today to inspire the creation of Reasonable guidance that is clearly justified to be imposed. 

In Scope use-case

• When I use data, I need to know the Provenance of that data so that I can assess the quality, reliability and trustworthiness.
• Where data are created by my own organization, I can trust my organization mechanism (out-of-scope is managing Provenance within an Organization)

When data are not locally created:

• When I import data, I need to know the Provenance of the data so that I can assess the quality, reliability and trustworthiness.
• The data is asserted as authored by an Organization (In-Scope, assertions of Organization)
• An individual or device is nice, but often impossible to assess quality, reliability, or trustworthiness of some other organizations individuals or devices. Thus this level of data is nice, but not useful. (Out-of-scope is identification of agents more refined than Organization)
• The data within the data may be derived from, or copies of, data originally from a third Organization. (In-Scope, origin of data that is copied or used in derivations/transforms)

Thus In-Scope

• When data are authored and exported to another Organization, there is a need to have Provenance of the authoring and exporting Organization 
• When data are exported that contain data that are derived, or copied, from another organization, then Provenance to that original organization is given.

Provenance elements

• What data 
• Who Organization authored and exported
• Accurate timestamps
• Indication of Provenance action (DerivedFrom, Export, Import)
• Reasonable mechanism to confirm data are authentic 

Not-In-Scope for Basic Provenance --> Advanced Provenance

• Provenance use within an organization for their own data -- Organizations do need this for their own purposes, but would not need to conform to a standard.
• Fine grain Provenance on workflow transitions or data lifecycle events
• Fine grain Provenance actor more refined than Organization 
• Transform methods or algorithms 
• Digital Signature proof of Integrity 
• Provenance on De-Identification or Re-Identification
• Provenance on Delete/Destroy/Deactivate activities

Reference:

• State of Healthcare Provenance Today
• IHE Profile of Provenance for Extracted data from Document Sharing
• Blockchain Provenance Service

Blockchain Provenance Service

I am inspired by the use of a public Blockchain as a repository for Provenance. That is the Provenance Service is implemented by using Blockchain technology. The most intriguing part is that with this model, everyone within a community submits in-real-time Provenance records every time they do something worthy of Provenance. This Provenance Blockchain would be a Public, Permissioned chain. That is viewable (useable) by anyone, but only updated by a defined set of permissioned entities. The Provenance record can be sufficiently opaque, while still being effective:

1. Rather than pointers (Provenance.target), there is simply the hash of the data.
2. All records of 'who' are organizational only. Where the organization is expected to keep internal record of individual, device, service, agent.
3. Activity is recorded (create, update, transform, export, import, destroy)
4. Blockchain validates the Organization (who) and the timestamp (when)

So That: When data are used, the user of the data can hash the data and look into the Blockchain for records of Provenance on that data.

Big advantage of this model is that data transfer never need to worry about what level of Provenance needs to be carried, and the pathway that data follows can be multiple hops even through hostile actors. If the data is intact, then Provenance will be found. If Provenance is found, then integrity and authenticity can be proven.

Not finding Provenance may mean the data has been improperly modified, but may also just indicate a custodian/author that is not participating in that Provenance Blockchain. These false-positive and false-negative cases do need to be addressed.

This leverages the integrity and public aspects of Blockchain, while taking careful steps to not put individually identifiable data into the Blockchain.

What is not clear is how the Patient themselves participates. They clearly can be given access to read from the Blockchain, and would encourage this as it gives them some ability to track where their data goes. This is only true of data they know about, as you must have a hash of data. There would not be a patient identifier in the blockchain, so you couldn't see all activity. The question is if the Patient needs the ability to add Provenance evidence to the Provenance Blockchain. This is not to question the Patient ability to create data, they can. But rather to point out that opening this up to the Patient is opening it up to EVERYONE on the internet, thus there is a risk of 'bad guys' filling your Provenance Blockchain with crud. Note that I have the blockchain validating the Organization, and being a Public but Permissioned chain.

Here is a handout by Grapevine World from an IHE Connectaton track on Blockchain Provenance Service

State of Healthcare Provenance today

Today, there is some provenance that is built into the Healthcare standards that are used. Some of this Provenance is not obvious, so let me expose it.

HL7 v2 has the least provenance information built into common use of the specification. This is not to say that there isn't provenance, but not much. In theory, one knows the sender of the message, but as a message, this sender information is usually discarded.

HL7 CDA has well implemented CDA header that holds Provenance. It isn't described as Provenance, but it is Provenance in that it describes: (a) Who authored the document, (b) What organization is the custodian of the document, (c) When was this document authored, and (d) Why was this document authored. Given that a CDA document is a document, and not a transport, it does not include to whom is it being sent, and from where is it being sent. These are gaps overall, but gaps that one should expect the transport to fill.

There is a CDA PROV specification, but it is not used today. This specification clarifies the basics, but also adds functionality for comprehensive Provenance within CDA.

IHE XDS/XCA/XDR/XDM/MHD is a document transport that is content agnostic. It can transport CDA, but it can also transport other content. With CDA, there is the above well defined basic Provenance. With other formats the document itself is not self declarative. Thus the XDS transports have defined metadata that explicitly carries these Provenance elements, along with other elements for other reasons (descriptive, identity, life-cycle, privacy, security, and exchange).

This metadata model was inspired by the CDA Header, but abstracted so as to work with any content type (which now includes FHIR  Documents), and many deployment models.
One Metadata Model - Many Deployment Architectures

Future on FHIR

FHIR has the most mature Provenance model. Not only does it have a Provenance Resource that can be used for any FHIR resource, but much of the Provenance data elements are often built into the core FHIR resource when that data element is fundamental to that FHIR resource. See the fiveWs page for details on this.

This model is inspired by W3C PROV, and long history in HL7 on Provenance. Thus it is intended to be comprehensive in function and ability.

FHIR Provenance Profile

There is a Profile of the FHIR Provenance resource to cover the use-case of data elements extracted from Documents that are shared in a Document Sharing (XDS/XCA/MHD) exchange, where the data are made available in Query for Element Data (e.g. Observations, Medications, Conditions, etc).  This use-case supports the case where someone is using the FHIR API to gain access to data, and they want to get the Provenance of the data they were given. Where the Provenance provides positive linkage to the Document(s) from which that data was extracted. See my webinars

Provenance Service vs Provenance with the Data

The CDA, XDS, and FHIR models defined above are all ways to carry Provenance with the data. This model is historically what is done in Healthcare, when Provenance is done at all.  The advantage of this model is that the Provenance data is conveyed with the data so that it is available when the data is used. 

However this is not the only model that could be done.

Provenance Service is a service that has the responsibility to support Provenance use-cases. When data are created, a record of that Provenance is submitted to a Provenance Service. When data are used, this service can be queried for evidence of Provenance on that data.

The FHIR Provenance resource could be managed in a standalone Service. A degenerate form of this Provenance Service in FHIR is where a FHIR Server that holds the clinical information also holds the Provenance. That is just a logical merging of the data custodian service with the Provenance Service.

The XDS model could be seen as a Provenance Service, much like FHIR. One can always lookup a document that you have in XDS to find a DocumentEntry. In that DocumentEntry is a hash and size of the document that you can confirm. There might be a digital signature association too.  If confirmed then you can look at the other elements in the DocumentEntry to see what the Provenance of that document is. Further one can see if the document has been replaced, transformed, or appended. This is not purely a Provenance Service, but the functionality does exist.

Elaboration on Blockchain Provenance Service 

When is Provenance Created?

Simply whenever data are

• created, 
• updated, 
• verified / authenticated, 
• transformed / translated / derivedFrom, 
• appended / amended, 
• de-identified / re-identified,  
• destroyed / deactivated / deleted,
• exported / published / pushed,
• imported

That is just about all actions other than Query and Read. Note all actions are AuditEvent relevant. Audit Log is not the same as Provenance. They are similar in what gets recorded and when a record is made; but the intended use and retention lifecycle of the AuditEvent is different than for Provenance. 

Having all of these records of Provenance is not valuable unless it is useful to those needing it.

When is Provenance needed?

The most important point of Provenance is that it is needed and used. A key part of use-case analysis is to look at the use of the data you are creating. If everyone created exhaustive Provenance records, but no-one used but 1% of those records, this would be wasteful.

So, lets look at Use-case for Basic Provenance

IHE produces Profiles using FHIR R4 for core functionality

Released from IHE is an update of 5 Profiles that represent a basic API to health data. The subset of IHE profiles that leverage HL7®FHIR® Release 4. The remainder of the IHE profiles that leverage HL7® FHIR® are expected to be upgraded to FHIR® Release 4 later in 2019. IHE published the following updated supplements for trial implementation as of March 6, 2019

• IHE Appendix Z on HL7® FHIR® - Rev. 2.1
• Mobile Access to Health Documents (MHD) with XDS on FHIR® - Rev. 3.1
• DocmentReference (DocumentEntry)
• DocumentManifest (SubmissionSet)
• List (Folder)
• Binary (the document)
• Mobile Care Services Discovery (mCSD) - Rev. 2.1
• Organization
• Location
• Practitioner
• PractitonerRole
• HealthcareServices
• Patient Demographics Query for Mobile (PDQm) - Rev. 2.1
• Patient
• Query for Existing Data for Mobile (QEDm) - Rev. 2.1
• AllergyIntolerance
• Condition
• DiagnosticReport
• Encounter
• Immunization
• Medication
• MedicationRequest
• MedicationStatement
• Observation
• Procedure
• Provenance

This subset is consistent with the Argonaut and US-Core subset of FHIR, yet does not include US specific constraints.   The combination of  these IHE profiles with US-Core could be a powerful focus of an IHE Connectathon "Projectathon". A Projectathon is when local constraints are added to IHE Connectathon testing.

Related to these 5 is the Mobile Cross-Enterprise Document Data Element Extraction (mXDE) which works with these profiles to provide an added value service.

The profile contained within the above document will be formally tested at the USA IHE Connectathon. The document is available for download at https://www.ihe.net/resources/technical_frameworks.

Updated:
I understand the target HHS/ONC regulation is 170.315(g)(7), 170.315(g)(10), and 170.315(g)(11). What ONC now calls the ARCH.