Privacy and Security Considerations for the use of Open APIs for Patient Directed Exchange.

I have the great honor to be hosting a panel discussion in Washington DC as part of the Office of the National Coordinator's 2nd Interoperability Forum. This event is, next week, August 6-8. My panel is scheduled for the afternoon of August 7th, from 1:30 to 3:00 pm. My panel title is "Privacy and Security Considerations for the use of Open APIs for Patient Directed Exchange."

Here is the main vision for this panel:

Assuming that we agree that patient advocates’ and privacy advocates’ vision is our goal; what lack of standards is getting in the way.  This is not a discussion about what the goal is, but rather it is meant to focus on what is still preventing the big stakeholders from embracing this vision.

General flow

Before my panel is a "Blockchain" topic and "Identity and Trust"; after my panel is a Lighting round where some new tech will be showcased.

Where Blockchain and the Lighting round will be clearly looking to new and shiny tech; I am hopeful that Identity/Trust, and my segment will be more grounded in reality. 

I have invited to my panel individuals representing very large organizations, very well established organizations. The reason I did this is because we don't get to hear publically from this perspective. Mostly the reason is because when this size of an organization makes a change, it affects MANY. However this size of an organization can't make quick changes. This size of an organization can't make risky changes. This size of an organization NEEDS some standard to guide them. This standard must be mature and have partner acceptance. 

Yes, sometimes a large organization can lead. This does happen. But it happens toward a standard. Example is Apple adopting FHIR.

What's a Standard?

Where in this panel standards is the broadest view. Inclusive of :

• Interoperability Standards -- from the likes of HL7, FHIR, and IHE;
• Vocabulary Standards -- from the likes of HL7, SNOMED, LOINC, IEEE, ISO, etc;
• Implementation Guides -- specific use-case analysis with specific solutions -- From Argonaut, IHE, or ONC;
• Standards of Practice -- professional society guidance from HIMSS, AMA, and other medical professional societies;
• Standard policy framework -- Legal framework that encompases many reglations and defines appropriate use and responsibilities;
• Trust Framework -- Multi-party trust agreement that binds the parties to a set of rules and mitigations, backed by technology (like Certificate Authority). For example Sequoia DURSA or DirectTrust;
• Reference Implementation -- software provided in open-source by a consensus body as an implementation of a standard. Such as the many FHIR open source projects;
• Standard Interpretation of Regulation -- like HHS/ONC has done with for example the use of email with patients; and
• Laws and Regulations -- we all hope for as few regulations as possible, but sometimes they are needed.

Ideal Patient Centered Privacy

Here are my notes extracted from my blog on Privacy Principles. I hope not to cover these in this detail, but am ready to if need be. I think it is important to recognize ALL of these Principles, not just "Consent".

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.

Modes of Communication

I am not constraining the mode of healthcare data communication. I want us to be inclusive of "Mediated" exchange, "Directed" exchange, "Controlled" exchange, and "Negotiated" exchange. I have not seen these formally defined, so here is my informal definition. Let me know if you know of another mode of communication.

• 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. 
• 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.
• 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
• 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 bulk data access.

Are we there yet?

So, standards in the broadest definition are important to the large organization. So I want to hear from them, what standard is still need. What lack of a standard is preventing them from achieving the vision of the Privacy and Patient advocates?

I would love to hear: "Nothing is needed, we are already there." I think we are closer than many think. I know that my efforts within the VA on their Patient Portal -- My HealtheVet -- shows that they are really close.

I do expect there is still some standards needed. Identity? Authentication? Consent? Care-Team? Provenance? Data-Tagging? Obligations? App-Validation? App-Store?

I certainly have blog articles on many of theses topics: FHIR,  Privacy/Consent, Health Exchange, Blockchain in Healthcare, De-Identification, Patient Identity, Direct, and even GDPR.

Timebound XDS queries done right

As the author of the soon to be published IHE "Document Sharing Metadata Handbook", I have been involved in some very deep and disturbing discussions on how to do timebound queries in XDS/XCA. I say very deep because this discussion included almost a dozen of the best minds on the XDS Metadata and Query models. Disturbing because the discussion showed that the simple concept of timebound queries in XDS/XCA is not understood well. Perplexing because we have figured this out many times. If it takes us this long to re-invent this understand, then it must be much harder for others.

Mistakes have been made

I wrote an article on our first attempt. I thought it was good. It was not wrong. But it would have resulted in false-positives, and false-negatives that can be avoided. See Basics of doing Document Sharing Query right. 

For the version of the Metadata Handbook that we sent to public comment, we flipped the logic, thus making a very bad mistake.

Back to the mostly right logic I had in my article, a couple of optimizations were determined this week in the solution we came up with. 

One adjustment, to add wiggle-room on the query parameters, helps because although we want everyone to have well synchronized clocks, many of these times are based on human statements of start and stop. Thus adding wiggle-room extends the times you are looking for to put your start a bit earlier, and you stop a bit later.

The other adjustment is to use the other two service time query parameters to eliminate document entries that have only one of the service times (start or stop, but not both). Clearly if something stopped before the time you are interested in, then it s not what you are looking or; same is true about something that didn't start until after then timeframe you are looking for.

When we got to the final understanding, it became clear that it is possible our readers don't understand this too. Some form of this might end up in the Technical Framework, as this handbook (and blog) have very limited audiences.  We also felt we had done this before, and had written up changes to the Technical Framework. We had, but had only discussed the CreationTime, which is  point in time. Service Time is a range, which brings more complexity...

serviceStartTime - serviceStopTime 

When there is a timerange of the service event that you are interested, you will query against the serviceStartTime and service StopTime metadata element to find documents that indicate they fit your timerange. . The service times are specific to the time range of the treatment or episode. This is different than the document creation time, which is when the document was created. The query results will return any document whose “service time” falls within that range. It is important to note that these parameters work together to give a period of time.

Given you are interested in a specific time range (Start -> Stop).

The serviceStartTimeFrom and serviceStopTimeTo are clear they should bound that time with a little slop to deal with poor timeclocks:

• serviceStartTimeFrom parameter in the query should be set to a few minutes before the time you are interested in being the Start of the service time range
• serviceStopTimeTo parameter in the query should be a set to a few minutes after the time you are interested in being in the Stop of the service time range

When either or both service time is missing on a DocumentEntry, it will be included in the above query results. So we need to look for ways to eliminate these false-positives. 

Some DocumentEntries will have a service start time but not have a service stop time. This is common in chronic care, radiology, and other circumstances where the end of the service has not happened or where the end is unknowable;  therefore you should include a query parameter that would eliminate DocumentEntries that have a declared start time well after the time range you are interested in:

• serviceStartTimeTo parameter in the query should be set to a few minutes before the time you are interested in being the Stop of the service time range

Some DocumentEntries will have a service stop time but not a service start time. This is not common, but will happen where there is no clear start time to an observation, therefore you should include a query parameter that would eliminate DocumentEntries that have a declared stop time well before the time range you are interested in:

• serviceStopTimeFrom parameter in the query should be set to a few minutes after the time you are interested in being the Start of the service time range

Some DocumentEntries will have neither service start or stop. These will be returned regardless of any timeframe query parameters. Your Community Metadata Specification should encourage all metadata publications populate the serviceStartTime and serviceStopTime element as much as possible to avoid false-positive query results.

Post processing to eliminate false-positives

Ultimately one will get false-positive results from the query, the solution is to look at ALL of the metadata to find reasons to find and eliminate these false-positives.

Conclusion

The only real way to avoid false-positives is to force all DocumentEntries in the Community to have at least ONE service time. Most of the time Service Start Time can be determined.  It might be only to the accuracy of the day, or month, or year. But even that eliminates many false-positives. When there is not one of these times available, one is sure to have false-positives. For the Metadata Handbook, this is a fantastic observation as it can become a community rule that at-least one, preferably both times must be filled in.

Yes we know that there are MANY other query parameters. Yes we know that one could design better query language support. The point though is that this is the system we have. AND when used properly it will work just fine. Any data publisher that doesn't follow the rules will mess up Any well designed system. This is not a case of a poorly designed query system, this is a fact. Query is at the mercy of the data, bad data gives bad query results.

FHIR patient extensible data portability

Discussions at FHIR DevDays raised this question of a basic way to leverage FHIR API capability to enable the Patient beyond the limited Apps their provider has approved.

If a healthcare provider offers a FHIR API (e.g. argonaut) -- meeting the Meaningful Use "API" requirement. Would it be reasonable to expect that the Meaningful Use "Download" (from View/Download/Transfer) capability would be offered in FHIR format?

Proposed quick-and-dirty solution?

This could be something like a zipped Bundle containing the results of $everything for that Patient, given that patient as the user.  The zipping would help with the potential huge size.

The amount of data would be limited to that which is available on the FHIR API offered, which is often not all possible data.

Concern would come up when this export of $everything includes other data such as documents and images. The theory is that they are all necessary to export, but the problem is the overwhelming size that might result. (Unfortunately compression would be less helpful with documents and images where they are slight variations that are mostly the same, but because of the base64 encoding they all look very different)

Should this be a FHIR Document?

It might be more well-formed to have this be a FHIR Document, but it is not clear to me that adds much benefit over simply an export of all data that is known (aka $everything). 

There would be benefit that the Bundle would then be far more identifiable as coming from a specific Organization on a specific Time for a specific purpose. This could also be simply a Provenance resource on the bundle. This might be very important to a downstream recipient of this blob so that it can be authenticated and proven as complete (Principles of a Document)

Essentially the CCD provides this today, and is often the solution for "download", so this is just a different mime-type (FHIR).

I think just getting an export is more important than making sure it is a FHIR Document.

Why would anyone do this or want this?

The reason why this is useful is for patients that want to use Apps that are not (yet) approved by that provider.  Waiting for each of their providers to approve a useful App can be limiting on the Patient and on the Marketplace.

Counter this with the potential stupid patient that doesn't realize what they are doing with their data... This is going to happen, and when it does there will be an outcry. This outcry will complain that the provider was not acting as a parent to that child, but this kind of an outcry should not be a reason not to do this. Better that the patient be warned, but not forbidden from getting all their data in an download of FHIR format.

Who does this?

If this is reasonable, who does this today? 

GDPR

Note that this would also be helpful in support of GDPR Article 20 - Right to data Portability. 

IHE ITI Document Sharing Metadata Handbook Published for Public Comment

Those implementing or improving their XDS or XCA community are the intended audience of this Handbook. As a Handbook, it strives to inform on critical aspects of Metadata management. Please review and comment. Please forward to those with experience.




IHE IT Infrastructure Handbook Published for Public Comment

The IHE IT Infrastructure Technical Committee has published the following new handbook for public comment in the period from June 13 through July 13, 2018:

• Document Sharing Metadata - Rev. 1.0 

The document is available for download at http://ihe.net/Public_Comment. Comments submitted by July 13, 2018 will be considered by the IHE IT Infrastructure Technical Committee in developing the subsequent version of the handbook. Comments can be submitted at ITI Public Comments.

Presenting IHE on FHIR at FHIR-DevDays

I am getting excited to give two IHE on FHIR tutorials at FHIR DevDays in Boston. The FHIR DevDays event is focused on educating IT professionals in the newest standard in healthcare, FHIR – Fast Healthcare Interoperability Resources. The FHIR specification may be the newest standard in healthcare, but it is backed by all those that have developed the previous standards (e.g. HL7, CDA, IHE, XDS,  DICOM), taking the best from experience and using the latest in RESTful API technology. For more on FHIR Dev Days https://www.fhirdevdays.com/ 

IHE on FHIR

Both tutorials will focus on IHE use of FHIR. The first tutorial will focus on a high-level view of how IHE and FHIR interact, and a broad view of the current 22 IHE Profiles that leverage FHIR. This tutorial will be most interesting to a general audience interested in Standards organizations and evolution of IHE Profiles. This tutorial is a shortened version of the IHE-on-FHIR tutorial I gave at the HL7 Workgroup meeting in Cologne.

XDS on FHIR

The Second tutorial will go deeper into the IHE use of FHIR to enable API access to Document Sharing infrastructures based on XDS and/or XCA. These Document Sharing environments exist within USA, Canada, Europe, and elsewhere. The Document Sharing environment provides a way for Clinical Practitioners to publish documents (e.g. CDA, C-CDA, DICOM, PDF, etc) such as medical summary, episode of care, discharge summary, laboratory results, x-ray, CT, MRI, and other. The IHE MHD Profile defines how FHIR enabled apps can discover these documents, retrieve them, and publish new documents.

Advanced IHE Profiles that will be discussed show how these documents could be decomposed into FHIR Resources that are more naturally made available, with Provenance linkage back to the source document from which the FHIR Resource information comes.

Conclusion

The emergence of HL7 FHIR is very exciting, and the collaboration with IHE shows a strong endorsement. I am always excited to work with this new platform to accelerate the advancement of Healthcare.

My blog articles on the topic of FHIR, Document Sharing, and Privacy

Erasure Receipt

During the GDPR discussions at the HL7 workgroup meeting in Cologne, we uncovered a potential 'nice to have' in the general information technology space, an 'Erasure Receipt'. The idea is that GDPR includes Article 17 the Right to Erasure (Recital 65 - Right of rectification and erasure), which is similar to the 'Right to be Forgotten' (Recital 66 - Right to be forgotten). In GPDR there are requirements that the data controller must pass on the Erasure request to other downstream Controllers that they have disclosed the data to; AND they must inform the Individual of each of these downstream Controllers (Article 19 - Notification obligation regarding rectification or erasure of personal data or restriction of processing). The Erasure Receipt would focus on making statements about the act of Erasure. 

I think this would be good to get as domain independent, not something that Healthcare does alone.

Like a Consent Receipt

Much like the "Consent Receipt" work that Kantara has developed. Where the Consent Receipt is a consistent concept that states the facts about a Consent that an individual has agreed to. The first versions of this Consent Receipt was not structured or coded, but had some requirements of the text and would be delivered to the Individual. The main goal of a "Consent Receipt", much like any cash register receipt, has very little use when everything works as expected, but is there as evidence in the case where things do not progress as expected. Specifically when the terms of the Consent are not enforced, the Individual can leverage their Consent Receipt against the violating custodian.

Erasure Receipt

So an "Erasure Receipt" would be given to the Individual after they have asked for data to be Erased. When that Erasure works as expected, the Erasure Receipt has very little usage. However if at a later time it is found that the data was not properly erased, then the Erasure Receipt can be used against the violating custodian. We also envisioned that the Erasure Receipt might be useful to probe the custodian to check that there is no current evidence of the data that was erased. So the Erasure Receipt is an artifact that shows due diligence, transparency, and trustworthiness. 

One reason why an Individual might request Erasure is when they withdraw their consent. In this case the Erasure Receipt and Consent Receipt might be the same.

"... where a data subject has withdrawn his or her consent or objects to the processing of personal data concerning him or her, ..."

Requirements of an Erasure Receipt

I am not a lawyer, so this is not legal advice... So the overall requirements that I think an Erasure Receipt has is:

• Date of Erasure Request
• Date of Erasure Receipt (typically must be within 90 days of request)
• Jurisdiction
• Human Language
• Identification of the individual
• Identification of the data controller
• Description of data to be Erased
• Purpose of Use the data was collected under
• Type of data that was collected
• Identifier of previously capture Consent Receipt
• Exceptions
• Reason why data could not be Erased (e.g. Medical Records Retention, Obligation to Report)
• Identification of Purpose and Type of data not deleted
• Success
• Identification of Purpose and Type of data deleted
• Method used to Erase (e.g. Deleted, De-Identification, etc)
• Downstream Recipients
• For every downstream Recipients of the data being asked to be Erased.
• Identification of downstream Processer
• Response if any received from request made to downstream Recipient
• Pseudonym -- given the Individual has been Erased, a pseudonym (i.e. GUID) can be assigned to the remaining data, proof of erasure, and the Erasure Receipt.
• This might be useful by the individual in the future to probe the erasure facts
• This might be most useful where the data are de-identified and maintained for other required purposes. A probe of the pseudonym would show integrity of that data, while assuring the Controller no longer knows who the individual is.

Once the Erasure has happened, and the Erasure Receipt has been delivered. The Custodian must now erase the individual details around the Erasure Request. Thus the power of the Erasure Receipt is that it is placed into the Individuals hands and only that Individual. Thu the Erasure Request likely does need to be Digitally Signed by the Custodian.

Erasure Exceptions

Given my discussion is most around Healthcare, the first clarification that I always express is that the GDPR Erasure Request does not override a Healthcare organizations regulated requirements (Article 23 Restrictions), such as Medical Record Retention regulations. Thus an Erasure Request in these cases might be completely denied. The likelihood is that there might be some data held by the Healthcare organization that is not protected by a regulated responsibility, such as social contacts and interactions. This exception puts many in Healthcare at ease. I then remind them that under GDPR, once that regulated reason expires they MUST erase the data. Thus if your country has a requirement to maintain Healthcare data for 30 years, once that has expired the data must be erased.

Other similar use-cases

This similar concept might also be applied to the Article 16 - Right of rectification, Article 18 - Right of restriction of processing, and Article 21 - Right to object.  I simply did not look further into this.

Conclusion

Erasure is different than Consent, but the receipt processing and overall use as a token when things do not progress as expected is similar. The big advantage of an Erasure Receipt comes when it can be Digitally Signed and include structured content. 

I am not a Lawyer, this is not legal advice...

GDPR on FHIR

I just finished a very long week in Cologne at the HL7 workgroup meeting and FHIR Connectathon. I had the idea that I could host a discussion of how to use FHIR in a GDPR compliant organization. So I created a FHIR Connectathon track. This track was hopeful that we could do testing with various parts of the FHIR specification. We ended up talking more about generally how to use the various capabilities that exist in FHIR to meet the various Articles in GDPR.

FHIR is GDPR enabled

The Security Workgroup and the Privacy (CBCC or CBCP) are global workgroups, so we have been aware of GDPR for many years. As concrete needs came up we would add that capability. Thus FHIR includes many capabilities that can be leveraged to meet GDPR needs. From a purely geek perspective the GDPR is not technically unusual, it simply places some higher emphasis on Privacy and Security capabilities. Thus overall the GDPR is a good thing to me, as it validates and will leverage the work I have spent 20 years developing in HL7, IHE, and DICOM.

More on this later in this article

GDPR is more than Privacy

I have heard a few people express that GDPR is more than Privacy and Security. I think that these people are misguided at the extent of the real definition of Privacy. The Privacy Principles that are generally included in many standards and guidance are inclusive of giving the Individual the right of Access, the right of Correction, and the right to control how their data are used.  Too often people think Privacy is only about restricting access. The HL7, IHE, and DICOM workgroups I have participated in have always used the more expansive definition of Privacy Principles.

Even the GDPR right to Erasure, related to the EU Right to be Forgotten, is an extension of the Privacy Principles rights to control data about the individual and the rights of the individual to correct improper information.

Adding emphasis: GDPR is very much patterned after "Privacy by Design", indeed it requires that "Privacy by Design" is used.  I have lots of experience with Privacy by Design, and like it. In my GE days, I made it the backbone of the Security and Privacy guidance for all products at GE Healthcare.

Thus GPDR is primarily about Privacy...

GDPR is more than technology

This is a fundamental truth. GDPR will drive far more work in the space of writing Policies, Procedures, Communications, and such. There are many publications, consultants, and lawyers that can help with this. There are many publications that will explain GDPR to you. I am not going to try to explain GDPR.  The law itself is not that hard to read.

So at this point I assume the reader is knowledgeable in GDPR. If not, then go learn that much first....

How is FHIR GDPR enabled?

This week we agreed to write a whitepaper that will explain this. It has the general ouline

1. Introduction and Scope -- that will explain we are only addressing FHIR specific topics
2. Mapping of GDPR Articles to the existing Security or Privacy capability in FHIR -- this section will provide terse guidance on how we visualize the use. 
3. Identification of some gaps we identified -- nothing critical, mostly nice-to-have operations
4. Conclusion -- FHIR is GDPR enabling

We are targeting the audience that is aware of FHIR and GDPR, that just needs some help extracting out the specifics. This paper should be about 8-10 pages.

The expectation is that once published, the external community may ask for clarification, or for specific actions. We might revise the paper. We might make it more visible through balloting as informative. We might convert it into an Implementation Guide.

Which parts of FHIR are useful?

Not to get ahead of myself. The following are the capabilities that we have already in the FHIR Specification today:

Security & Privacy    and  Security

• Provenance, Resource
• Includes a signature mechanism that can be leveraged in many comprehensive ways.
• AuditEvent Resource, and Guidance
• Consent, Resource
• any Resource can be tagged with Security/Privacy tags
• De-Identification guidance
• Secure Communications
• Common recommended use of TLS (HTTPS)
• May use Client Authentication
• Recommend follow good TLS principles such as BCP195
• Authentication and Authorization
• SMART-on-FHIR - leverage OpenId Connect for User Authentication. Provides a pattern for OAuth scopes
• IHE  - Internet User Authorization - defines a set of OAuth token attributes
• HEART -- a mechanism for externalized Consent to be managed and Authorization decisions made
• Identity -- various FHIR resources are tied to identities that can be used in Policy (e.g. Consent), and would be used in AuditEvent and Provenance to record Who did some action.
• Patient
• RelatedPerson
• Practitioner
• PractitionerRole
• Group
• Organization
• Location

Gaps -- those that we found this week.

We did identify some gaps. But all of these gaps are 'nice to have'. They all are new functionality that helps automate an Organization's actions on the Individual actions:

• Operation that would provide response to an Individual "Right of Access" Article 15
• assemble all the PurposeOfUse the organization utilizes, which would be beyond those used in the FHIR infrastuture
• For each PurposeOfUse assemble the types of data utalized
• And how the data are processed
• etc...
• Operation that would provide response to an Individual "Right to Data Portability" Article 20
• assemble ALL the data in the best encoded format. 
• This includes data not found in FHIR format
• Possibly that data can be just described in meta terms
• Possibly that data can be encapsulated in DocumentReference + Binary
• etc...
• Operation that would provide capability and response to Individual "Right to Erasure" Article 17
• NOTE that Erasure does not override other regulated reasons to keep the data. Thus Medical Records are not subject to Erasure.
• Erasure affects all data, not just FHIR data
• Identity must be confirmed. 
• Action must be confirmed
• Various Erasure methods might be used
• simple delete
• de-identification
• etc
• An Erasure Receipt might be useful to define as a standard.
• Possibly others...

Although these were discussed, it is very unclear how realistic their use would be.

Conclusion

I assert that FHIR is ready for GDPR use. I welcome engagement that helps enlighten me.