BPPC is not just for XDS/XCA

There is a general misunderstanding that the BPPC (profile of CDA for capturing patient privacy consent) profile is only useful for XDS (document based Health Information Exchange) and XCA (Federation of document based Health Information Exchanges of various types) environments. The reality is that it is most valuable when used in XDS and XCA; but it has an important role to play in push models like XDR profile and XDM (publication on removable media and zip based packages) profile. It is a different value...

BPPC could apply to any topology of exchange. The reality is that BPPC is only ever needed when ONE organization captures consent that applies to ANOTHER organization.

When no need to expose Privacy Consent

Most Privacy Consents, by number of Privacy Consents captured,  are an authorization to release within that Enterprise. This is completely local issue that doesn't need to be made visible beyond those systems involved in the capture and enforcement of that Privacy Consent, a local issue.  This is often simply allowing the Enterprise Role-Based-Access-Control to allow the authorized Roles to do the authorized Actions. This does not mean the Privacy Consent isn't important, it is important. This only means that exposing the details of the Privacy Consent using a standard adds very little value. Thus this is often managed fully within the EHR as proprietary solution. It could use BPPC or later standard.

Authorizing HIE Disclosure

The next most prevalent is a Privacy Consent that authorizes release to others. Meaning that ONE organization captures consent that authorizes them to release data they control to others (organizations, individuals, etc). In this case that ONE organization is responsible for executing (enforcing) that consent. The other organizations never need to known about the consent, certainly not the details of the consent; they either get the data or are denied the data. It might come with obligations, but those are much easier to encode on the transaction than deep within consent language. This is the most common use-case for enabling an organization to expose patient data through an HIE. Where I am using a broad term for HIE, not limited to XDS.

In this case the Privacy Consent that the organization captured is not useful for others to see. The other actors in the HIE ask for data, which they either get or not. There is little that asking organization/individual can do to change the decision.

These are why there isn’t much actual use of consent in HIE’s; because it is eventually realized to be a local matter.

When Privacy Consent is managed in the HIE

The first case where the consent is captured in a centralized way, such as where the HIE infrastructure organization is given the responsibility to capture consent. Having the HIE managing the Privacy Consent allows the consent to be region based, rather than organization-by-organization. This has scale advantages. The drawback to this model is that the singular consent needs to address all the variability that patients might need. In this case they need to publish that it is okay for specific uses.

The special cases might be broad cases, like any normal (Role-Based-Access-Control) for Treatment and Billing. This can be addressed by BPPC through an identified Patient Privacy Consent Policy, that the patient has agreed to. This enables the simple go or not case.

The special cases are where the consent is actually a set of specific ‘use’ instructions. That is that it is a policy that is not a simple authorization to release under normal Role-Based-Access-Control; but an authorization to release with conditions (constraints). --- Note, there is IHE work going on right now to address this, going beyond BPPC.

When Privacy Consent is sent to the Requesting Party

A targeted case is where there is a need to carry the evidence of consent (authorization to release) along with the documents being released. In this case the BPPC document is not there for enforcement, but rather simply as a Document of Consent. This might be more useful when the Privacy Consent can carry more exacting rules than BPPC, so we might see this show up more with the new work in IHE on "Advanced Patient Privacy Consents" (or whatever it ends up being named).

So the case for BPPC use with XDR, XDM and Direct; are less obvious. But they tend to fall into this last set of use-cases. This was the point of the blog article. The point is that there already is little need to communicate a Privacy Consent document, but where one does a PUSH through XDR, XDM, or Direct; one would only need it a fraction of the time.

Other Models

I am not trying to express all the models in one blog article. The point of the article was to show when a Privacy Consent document would need to be communicated in a PUSH transaction.

There are other models that are supported by Privacy Consent  documents like BPPC. Such as where the Requesting Party is the one that has gathered the Privacy Consent (authorization to release to the requesting party).  This use-case is used by some payers that need to express that they have gotten explicit authorization from the patient. Another use-case might be where a patient has authorized unusual access, such as when they are getting care in a different country or where they are authorizing a clinical research project.

There are models where the Privacy Consent registry is an independent agent. There are various models that put the patient at the center of the Control. In some of these models the patient gets to choose from a set of Privacy Consent registries, the one that they want to use to control their rules. This is the center of some usecases in HEART using User Managed Access (UMA). This is a very exciting concept. I am participating and expect it will produce useful specifications. This however is very radical, so I expect it will take many many years before we see this in the wild. I thus expect many years of overlapping solutions.

IHE did develop BPPC to be re-usable... More blog articles Patient Privacy Controls

Security Failure -- Availability

Security is a Risk domain, with the sub-domains of risk being risks to Confidentiality, Integrity, and Availability. Lately the failures have been in the sub-domain of Availability.

First it was the Hollywood Presbyterian Medical Center in LA. Their data got encrypted by malware and held hostage to a $17,000 ransom.

Now it is Lukas Hospital in Germany.

Many people focus their security efforts on the “Confidentiality” aspect of Security. I don’t know if either the LA or German hospital failed to protect the Confidentiality, but the attack they fell victim to could easily have happened to a database that was perfectly protected against Confidentiality risks. The database might have been encrypted by the database software with very good management of that encryption key. This protection would not have prevented the database from being Encrypted AGAIN. Yes, an encrypted system can be encrypted again.

It is possible that the databases were fully readable in the form that the malware encrypted. I am not trying to declare that they were. My point is that unless you address all aspects of the Security risk domain, then you have left unmitigated risk.

Clearly if the data is not backed up, then there is also failures to protect against Integrity risks.

See my blog articles on Security as a Risk domain 

• Security/Privacy Risk Assessment/Management

MHD in action -- XDS on FHIR

Two independent projects this week sent to the FHIR mailing list their diagrams of how they are using FHIR as an API to classic XDS environments. I thought both diagrams were fantastic illustrations of the power of the MHD, PIXm, and PDQm profiles. The power of using FHIR as a simplifying API to classic environments. These diagrams are not only technically wonderful, but also beautiful.

I have asked for permission to republish these diagrams. They are not my diagrams.

From the Jose Maria Olmo Millan working on the prevvy project, writes:


We are using a similar approach for our patient centric platform (prevvy.co). We have developed a FHIR/IHE server and we store CDA and FHIR documents in the same IHE infrastructure using IHE metadata capabilities.
 ..
FYI, this is our FHIR/IHE/DIRECT architecture



From Ioana Singureanu working on SAMHS BHITS project writes:

I'm supporting the SAMHS BHITS project to create a standard-based, open-source patient portal application (My Health Compass). Our project will use FHIR as an abstraction layer for the application. Our IExHub will expose FHIR services to the application while an HIE using standard-based SOAP services (IHE ITI) and/or HL7 Version 2 transactions.

We are not using FHIR for information exchange right now but when EHRs will support FHIR, the our users will be able to directly to one more EHRs to read and, in some cases, even create new resources (e.g. privacy consent).

Here is an overview of the component architecture:

Note that SAMHS will be at HIMSS next week, seek out Ken Salyards out at the FHA area of the HIMSS Interoperability Showcase.

Note they are also doing more than this, specifically there is also discussion on CDA<-->FHIR. Ill let Keith speak about that.

These are great examples. Well done!

MHD, PIXm, and PDQm -- aligned with FHIR DSTU2

This is the notice of Ballot on the updated Profiles from IHE on MHD, PDQm, and PIXm. This ballot to review and approve the updates so that they can be formally tested at EU Connectathon. Please review, and provide constructive comments.

In general these profiles are thinner than previous as the FHIR specification in DSTU2 is far more readable and complete. Thus there is less description and 'profiling' that IHE needs to do. As such these IHE profiles rely more on the good readability of the FHIR specification in DSTU2.

Other Blog articles on FHIR Topic

John

Updated at 9:37am Central time...

Timeline:  Ballot is open from today through Wednesday, March 15, 2016

Submitting Comments:  Please use the attached spreadsheet to compile your comments.  Submit the completed spreadsheet to ITI Comments mailing list (iticomments@googlegroups.com).

Voting Rights Reminder: Providing comments on CP ballots is a great way to obtain/retain your organizations voting rights! Make sure your voting rights stay active in 2016 by participating in CP ballots!

Ballot #32 contents:  The CPs listed below, the updated Trial Implementation Supplements, and the comment spreadsheet are in the attached zip file and on the IHE FTP site at ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2016/CPs/Ballots/ballot_32/

• CP-ITI-884 - PIXm changes for DSTU2
• CP-ITI-885 - PDQm changes for DSTU2
• CP-ITI-886 - MHD changes for DSTU2
• CP-ITI-919 - Split FHIR-specific Appendix Z out of PDQm supplement & update for DSTU2

Guidance on HTTP Access Denied

A web-server, especially hosting FHIR, must choose the response carefully when an Access Denied condition exists. Returning too much information may expose details that should not be communicated. The Access Denied condition might be because of missing but required Authentication, the user is not authorized to access the endpoint, the user is not authorized to access specific data, or other policy reasons.

To balance usability of the returned result vs appropriate protection, the actual result method used needs to be controlled by policy and context.

Typical methods of handling Access Denied used are:

• Return a Success with Bundle containing zero results – This result is indistinguishable from the case where no data is known. When consistently returned on Access Denied, this will not expose which patients exist, or what data might be blinded. This method is also consistent with cases where some results are authorized while other results are blinded. 
• Return a 404 “Not Found” – This also protects from data leakage as it is indistinguishable from a query against a resource that doesn’t exist. It does however leak that the user authentication is validated. 
• Return a 403 “Forbidden” – This communicates that the reason for the failure is an Authorization failure. It should only be used when the client and/or user is well enough known to be given this information. Thus this method is most used when the user is allowed to know that they are forbidden access. It doesn’t explain how the user might change things to become authorized. 
• Return a 401 “Unauthorized” – This communicates that user authentication was attempted and failed to be authenticated. 

I hesitated to include 451 "Unavailable For Legal Reasons", but couldn't seriously consider this given the specific context of 451. Which is specifically intended to expose information that is not allowed to be exposed.

Patient as a User - becoming "known to a practice"

The current practice is ‘in person proofing’… as the first encounter with the patient is as a … patient… Now many patients are not at their ‘best’ when they first appear, so the understanding of their identity evolves over the first hours and days and weeks. Thus in healthcare practice we often know the patient by many identifiers that we have either merged or linked. And there are cases where a merged or linked patient needs to be unmerged or unlinked. Very messy business. Ultimately the patient gets billed for the services they have received, and the identity gets confirmation that they paid, thus stronger. This is just a discussion of the patient id, not the patient as a user.  See my topics on Patient Identities.

Patient as User

The patient as a User usually starts with this in-person relationship. Most often the healthcare organization uses the identity they know, and the billing address to send them postal-mail (covered by strong fraud laws). This kickstarts an online confirmation workflow that binds the human patient identity to a user identity. Unfortunately this often is by way of a hospital managed user account, and not an internet friendly OAuth identity.

There are increasing cases where an internet friendly OAuth identity is used. However these (Facebook, Google, etc) are very low assurance identities, as anyone can claim to be anyone. To use these in healthcare we elevate the LoA using the above described online confirmation workflow so that the result is an identity that the patient wants to use, elevated to a higher assurance level through the healthcare driven identity confirmation workflow.See my User Identity topics.   Specifically getting to mHealth solutions - real People

User Identity and Authentication 

• HEART profiles for review, comment, and approval  
• mHealth Identities using trusted intermediary
• getting to mHealth solutions - real People
• getting to mHealth solutions - Users
• Internet User Authorization: why and where
• IHE efforts in RESTful security
• IHE-IUA - Internet User Authentication for HTTP profiles
• Identity Proofing and Authentication -- Patient vs Provider
• Level setting on Level of Assurance 
• etc...

Patient Identity

• PDQm - Patient Demographics Query for Mobile API
• Policy needs to get out of the way of good Patient Identity management
• HIE Patient Identity problem
• Identity Proofing and Authentication -- Patient vs Provider
• Patient Identity Matching
• Universal Health ID -- Enable Privacy
• The Basics of Cross-Community Patient Discovery (XCPD)
• NwHIN-Exchange use of XCPD for Patient Discovery
• Direct addresses- Trusted vs Trustable
•  etc...

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