Pages

Thursday, January 28, 2016

My Testimony to the ONC API Task Force on Privacy and Security


I gave this verbal testimony to the ONC API Task Force on Privacy and Security today... On World Privacy Day.

I want to thank the Task Force” for inviting me to speak on behalf of GE Healthcare. I am also a co-chair of the HL7 Security workgroup, a member of the FHIR Management Group (FMG), the lead in IHE-Mobile Health Documents (MHD) , and active member and advocate of HEART .

I am pleased at the fantastic testimony this committee is receiving.

GE Healthcare is and has been a strong supporter of standards-based Interoperability, as it enables us to be a global healthcare solution provider. Any customization or specialization for any specific region or provider organization is effort that is counter to this standards-based approach. I am glad to hear others express this same solution for their own various reasons.

GE Healthcare has had APIs as part of our systems for decades. Most of these are the bread-and-butter of any healthcare organization's network backbone, drawing on HL7 and DICOM, using IHE Profiles. Many of our IT products have had web friendly APIs for some time. We have a limited use of FHIR being used at a few pilot sites, limited more due to the developing nature of FHIR right now. All of these APIs, old and new, guide my testimony as RESTful APIs don’t fundamentally change Privacy or Security, they do elevate the threat.

We place no special qualifications upon our customers to gain access to the API or documentation. Use of the API is restricted using Authentication and Authorization mechanisms.

Privacy concerns mostly involve shared roles and responsibilities between healthcare provider organization and GE as the vendor providing the system. Given that GE doesn’t have direct relationship with the patient, where the provider organization does have a relationship with the patient and controls the policies and use, the privacy concerns must fall to the provider organization. Given this reality, we do have a Privacy-By-Design approach built into our product development processes so that we build into our solutions Privacy enabling technology.

The main problem that we see is the very wide variation in security and privacy maturity of healthcare provider organizations. The very large organizations have mature capabilities and have policies, procedures and technology solutions available on which we can build a trust relationship. The vast majority of healthcare provider organizations, however, don’t yet have the full range of these operational aspects. Add to this the variation and layers in legal and regulatory policy requirements.

Technology can be used to resolve Privacy and Security issues, but they must be used in a Policy domain. Policy issues focus on the roles and responsibilities for the various requirements regarding privacy and security operation: Identity Management, Authentication, Consent, Accountability, and Incident Management. These are types of Policy and Procedures that we often don’t find at healthcare organizations.

  • Patient Identities are an especially problematic area of identity management. With no controlled Patient Identity, privacy cannot be managed or assured. This challenge applies to data management, consent management, and patient access management.

  • User Identities need to be managed by the healthcare provider organization. The healthcare provider organization must take responsibility for the functionality of User Provisioning, user De-Provisioning, Authentication, Account Recovery, Account Suspension, Account Deletion and Account Monitoring. Vendors and applications can leverage the use of standards like OpenID Connect using OAuth.

  • Incident detection and response is often never even discussed. Sharing of responsibility, identifying and assigning specific roles and tasks is critical.

  • APIs imply a more agile ability to hook applications to services. This brings up Policy, Procedure, and Technology questions around how we identify trustable applications, or trustable services; and how those trusts translate into technical trust with maintenance of that trust in a way that supports quickly recognizing broken trust and reacting appropriately.
Overall, the security and privacy challenges associated with APIs reflect and are a consequence of the wide variety of maturity of healthcare provider organizations in both policy and technology. The additional variations in regional policies add to this complexity. Complexity, uncertainty, and variability need to be controlled for Privacy and Security to be successfully achieved. These challenges clearly need effective and timely consideration given the current policy drivers to broad and deep API use in healthcare.

Thank you.

My full written testimony is available along with the others at the API Task Force site

One thing that got clarified in the comments is that I think we need to greatly constrain what we are trying to work on, so that we can make progress on something that helps many people. We then work on the next layer of complexity. Then the next layer of complexity. Josh asked me what I though this constrained use-case was. My answer is quite simple, access to Documents. A FHIR based API that gives the patient access to all the Documents they have available. This would leverage the IHE profiles (MHD, PIXm, PDQm, IUA, and consent). This is indeed small step, but it is one that would allow us to focus on User Identity, Patient Identity, Consent Authorization, and API access. It could scope out access by anyone other than the patient, a good second phase. It could scope out the patient directing the data to another location, which brings in trust issues. Focused, so that we can focus on the problems to be solved. Yet the focus is a useful thing, the focused thing gives us a Security and Privacy framework that can support other access, the focus that gives us a simple FHIR API to use, a focus that can also be an API to an XDS or XCA environment. Focused, but stepping stone.

Also I think I might have been misunderstood with the last question from Leslie Kelly Hall. I think she and the audience might have gotten the impression that I was against giving the patient access, transparency, and control. I was not against this. I emphasized this quickly at the end, but one never knows how that gets understood. The point I was making is that continued delay to make the perfect solution is delaying access by those that want access.  We should not restrict access to the many because a few (growing group) want to have fine grain controls on all uses of their data. I want to get the data, in full form, to the people. What they do with the data once they have it is up to them. I am very much involved in standards efforts to create a process for fine-grain control, however I am frustrated as anyone at how many people cant get a full copy of their data. I want stepping stones.

John

Monday, January 4, 2016

FHIR Oauth Scope

As FHIR matures, the security topic becomes more and more important.  I participate in HEART, an effort hosted by the OpenID community including an impressive set of experts from the OpenID, OAuth, and UMA world. They do need more participation from healthcare, it is hard to give everyone that needs attention the full attention they need.  HEART has some foundational profiles ready to be used
HEART profiles for review, comment, and approval

So the next thing up for discussion is a set of OAuth 'scope' values. A 'scope' is a way for an App to ask for less rights than the user holds, and is a good way to limit the damage that an App can do. So the question really is in what ways would it be appropriate to cut away rights that a user might hold.
The is something that has not yet been discussed in any useful detail inside of HEART. In fact the specification they have "FHIR OAuth 2 " is not open for review, yet. This specification is mostly derived from what SMART supports today. It is made up of  a set of strings that represent a few FHIR resources. It is not a complete list of FHIR resource types. This list was simply an initial attempt at coming up with a set of scope values. The list is a logical thing that someone would create given simply that FHIR is based on REST. Meaning this is a typical list for any ‘normal’ RESTful api.

Sensitivity 

This focus on FHIR resource types has the problem that in healthcare it is not the type of resource that differentiates between access allowed vs access denied. There are some FHIR resources that typically just carry data, Such as Organization, HealthServices, Location, Device, ValueSet, Conformance, etc. These resources don't carry varying sensitive information.
However Resources like CarePlan, Medication, Observation, DiagnosticReport, and others carry data that can vary widely on how sensitive it is. 

Normal is normal for Healthcare data

These Resources might be carrying what most people consider "Normal" healthcare information. Note that the word "Normal" is relative to all healthcare information, not a label relative to all information. Healthcare information, even Normal, is considered "High Risk:" overall. 

Beyond Normal

There are sensitive health topics: HIV status, drug abuse, 

Finding Normal

This is not an easy tag to set on data, so unfortunately most data is marked "Normal". Which is potentially not wrong, just not very helpful. I given advice in  How to set the ConfidentialityCode

sensitivity evaluation along a vector

What I am looking for is a way of saying "I want to be using data that is Normal or less". The _confidentiality codes are defined specifically to be a scale of not sensitive, to less sensitive, to normal,  to high sensitive, to too hot to handle. This was an explicit exercise and was done in concert with ISO 13606 so that we would have a linear assessment of risk. 

Purpose Of Use

We often focus too much on treatment workflows. Where there are many other reasons why people, applications, or services might want access to the healthcare data. This is represented by the Purpose Of Use, using the PurposeOfUse vocabulary as a starting point. This allows for the normal "Treatment", or "Billing" but also includes in the vector marketing, legal, public health reporting, eligibility, etc.

the REST

I don't mind including the classic REST viewpoint. I just don't think it is sufficient. So I would include the ability to limit the scope based on the REST operators and the FHIR Resource types.

Proposal (for discussion)

purposeOfUse “:” _confidentiality “:” resource “:” action “:” Patient

Where:
  • purposeOfUse -- value from the PurposeOfUse vocabulary
  • _confidentiality -- highest value from the _confidential vocabulary
  • resource -- FHIR resource type from the resource-types value-set
  • action -- RESTful verb (CRUDE) from the restful-interactions value-set
  • Patient -- URI to the Patient resource identifying a specific patient
  • where any can be “*” to indicate not requesting a constraint.
Further note that multiple scopes can be indicated with a "," separator. 

Further note that the authorization server can downgrade even more the scopes that were asked to the scopes that were granted. The OAuth specification doesn't explain how this is done, just that it is allowed. One example would be where the authorization server knows the app by identity, and thus restricts scopes.

Break-Glass use-case

This proposal sets up one model to support ‘break-glass’ by first asking for "Normal" data, but when a break-glass justification exists then asking for “Restricted”.  I know I need to explain this more, but this is not the topic of this blog post.

Privacy Consent Directive

I expect that a Privacy Consent Directive might also be a useful vector through the Scope. That an app could say they only want the access rights granted to the user through a specific Privacy Consent Directive. This might be especially useful when the patient can actively grant one-by-one authorizations. 

I didn't include this in the proposal because there is active work on FHIR Privacy Consent Directives, and equally interesting HEART efforts to leverage UMA.

Conclusion

This is in no-way a conclusion, but a proposal for discussion.

Historic Blog Topics