Pages

Monday, February 29, 2016

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

Saturday, February 27, 2016

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 

Thursday, February 25, 2016

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!



Wednesday, February 24, 2016

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.

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

Thursday, February 18, 2016

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.


Tuesday, February 2, 2016

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 

Patient Identity