Simplified #FHIR Privacy Consent Directive resource

The most simple Privacy Consent Directive would really just be a YES/NO flag, so I don't actually mean that simple. What I mean is more simple than the last update I made, yet still functional. With the previous version I learned a few more things to be simplified.  The most shocking that I forgot is that the most prevalent exception is to exclude data published duing a date/time range.

So now I have updated the Privacy Consent Directive resource that has a base that identifies the patient, authority, domain, location, recipient, grantor, data, and actions. These are the elements needed for an all-or-nothing kind of consent.

Simple FHIR Consent

Much discussion around consent (Privacy) in HL7 FHIR. It seems that much of the seamingly endless circular arguments come down to getting everyone on the same page.

1. HL7 can only produce Interoperability standards. It can't define Policy, Architecture, or Implementations.
2. We thus can't just pick one architecture (e.g. OAuth+UMA) and stop. We must build to fit a reasonable set of architectures.
3. We thus can't jut pick one policy (e.g. patient home) and stop. We must build to fit reasonable a set of policies.
4. We thus can't just pick one implementation (e.g. single server) and stop. We must build to fit a reasonable set of implementations.
5. FHIR should focus on only what systems do today, not what we want them to do.
6. FHIR should put into common extensions those things that we want them to do (e.g. Identified disclosure notification endpoint)
7. Simple is always better

This means that sometimes a specific Policy, Architecture, and Implementation might not need our solution at all. This is likely the case if someone picks the HEART (OAuth+UMA) model, were the current FHIR Consent adds no value since all the consent policy management is handled inside the UMA authority.

Adrian 'working defintion of consent' is much like what we have used. I reproduce it here with attribution as I like his structure:

I (Adrian) propose a working definition of consent as:

• A contract between a person and an institution that describes a policy of the person and a duty of the institution.
• A policy is not an attribute. An attribute can be measured and asserted by a lab or a nurse. A policy can only be asserted by the patient or their custodian - hence, the need for a contract.
• A contract combines a series of terms into one accountable transaction. 
• The terms of a consent transaction MUST include:
1. An institution that carries the duty of interpretation.
2. A subject - the patient
3. A custodian who is allowed to assert a policy (the patient or legal guardian of the patient)
4. A resource (potentially any non-aggregated FHIR resource, including de-identifed person-level resources)
5. A policy to be interpreted by the institution related to use of the resource (this will become a scope for authorization to access the resource at some future time).
6. A notification endpoint chosen entirely by the custodian for transparency in how the institution is interpreting the policy to issue each authorization.
7. A signature of the custodian
8. A signature of the institution that will issue the authorizations
9. A jusrisdiction for the contract,

This definition of consent is based on my amateur interpretation of international Agency Law. If we can agree on this, then the role of FHIR in capturing consent would be immensely clearer.

I think this maps well to what I have already created in the FHIR Consent resource:

I think you will find it matches quite well. With a few exceptions that we have not yet thought of (thanks for bringing them up), or things we might put into extensions due to the 80% rule.


That said, we can always improve. I welcome these constructive comments. I welcome suggestions for better name of the Resource (Consent) and better names and definitions for the element names.

I have already realized through discussions with Adrian, Oliver, Rob, Kathleen, and Lloyd that the model I have could be further simplified, extended, and clarified. 

First generation FHIR Consent Scope

I would like to assert that we are focused on enabling a reasonable set of policy architectures and policy sets. What we create must degenerates nicely to support environments that want a simple indicator of opt-in, opt-out, none. But we want to go a bit further, we want also to support opt-in with some reasonable exceptions, and opt-out with some reasonable exceptions. Where these exceptions are only those currently implemented: List of objects, List of authors, List of recipients, List of Organizations, List of purposeOfUse, and Date Range. --- This scope is however not properly said so far, but I would be glad to indicate it or a sub-set as the goal.

Improvement Opportunity:

1. Simplify Actor to the specific kinds of actors in a consent. using specific elements, not a list with type.

1.a) Be specific about recipients, and allow device to be a recipient. Where recipient is a named identity of something that is given authority under the consent.

2. Simplify the attachment to just one, no need to differentiate between legal and friendly today. Maybe in the future

3. Simplify to remove the rule element. Possibly move it to extension

4. Add exceptions for date-range

5. Make the exception more clear

Public Comment period for IHE Advanced Patient Privacy Consents profile

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment The IHE IT Infrastructure Technical Committee has published the following Technical Framework Supplements for public comment in the period from May 27 to June 26, 2016: Add RESTful Query to ATNA Advanced Patient Privacy Consent (APPC) Re-documentation Register On-Demand Document Transaction Mobile Alert Communication Management (mACM) The documents are available for download at http://ihe.net/Public_Comment/. Comments received by June 26, 2016 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation versions of the supplements. Comments can be submitted at ITI Public Comments.

A turning point for Privacy in America?

Out this week by Pew Research is this article that I find so amazing while at the same time there are so many instances where the public appears to be willfully giving away their Privacy. The Pew Research output says enough. Not much more I can say, except I am excited we might be turning the corner. Here is just the first paragraph, where it is clear no turning point has yet happened, but an awareness is!  An awareness of many of the Privacy Principles, not just confidentiality.

The cascade of reports following the June 2013 government surveillance revelations by NSA contractor Edward Snowden have brought new attention to debates about how best to preserve Americans’ privacy in the digital age. At the same time, the public has been awash with news stories detailing security breaches at major retailers, health insurance companies and financial institutions. These events – and the doubts they inspired – have contributed to a cloud of personal “data insecurity” that now looms over many Americans’ daily decisions and activities. Some find these developments deeply troubling and want limits put in place, while others do not feel these issues affect them personally. Others believe that widespread monitoring can bring some societal benefits in safety and security or that innocent people should have “nothing to hide.”

Some of my Privacy blog articles

• Healthcare Blockchain - Big-Data Pseudonyms on FHIR
• Start at Consent as a FHIR Resource
• FHIR Consent as a Resource or Profile
• Consent given to authorized representative
• Patient ID is critical to Enabling Privacy
• Consent to grant read access to a specific types of FHIR Resource
• electronic Privacy Consent -- Patient choice
• BPPC is not just for XDS/XCA
• How to set the ConfidentialityCode
• Strawman on Consent Directive
• Privacy Principles
• Break-Glass on FHIR
• Healthcare Patient Consent -- Lessons learned from Creative Commons
• Enabling Patients to Delegate Healthcare Information Access Authority
• Define Atom -- Too many definitions in use today 
• Defining Privacy
• Safety vs Privacy
• Privacy Consent State of Mind
• Universal Health ID -- Enable Privacy
• Texas HIE Consent Management System Design
• Simple and Effective HIE Consent
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
• 
  

Healthcare Blockchain - Big-Data Pseudonyms on FHIR

Grahame challenged us all to think about a realistic use-case for blockchain technology in Healthcare.

Blockchain is a hugely hyped technology, because of the excitement of bitcoin. The technology is really not new, it is just a special mixture of crypto technologies, not unlike Digital Certificates; except rather than proof through decoupled proofs, blockchain has a public ledger where transactions must be recorded with proof that the transaction happened.

The magic of Bitcoin is that it creates value as it is used, and this created value supports the financial burden of the infrastructure/technology. One might even argue that bitcoin is approaching a nexus where the value created is not worth the burden ; and that this could cause the whole thing to collapse (like a pyramid scheme -- but I didn't say that)

What is very important to point out is that blockchain is PUBLIC, and PERSISTENT. Meaning we can't put sensitive information there. We can't put data there that needs to be corrected. Thus putting healthcare information onto the blockchain is just not going to happen. Sure we can encrypt it, but that doesn't use the blockchain.  What you put on the blockchain can't be revoked, it is persistently in the public view. So we also have to be very careful. Bitcoin isn't worried about this because these are exactly what it needs, it is a public journal of transactions and these need to exist forever.

So we can either figure out was to use the bitcoin system, where we primary focus on the monetary value; which is useful. Some have proposed ways that insurance, or at-least a trust-fund, could be used to pay for medical procedures. Including putting executable script into the blockchain that expresses when the money would be released.

I however think that the real challenge Grahame is putting forth is can we use the blockchain technology to build a uniquely Healthcare blockchain? For this we need to solve the fundimental funding problem, that is how do we financially support this blockchain?

I might suggest that a potential solution is as a journal of public pseudonyms linked to data access points (FHIR API) and authorization servers. The chain would assert (signature) the authenticity and pseudo-provenance of the data. While also enabling accessibility under he control of that data owner's control (UMA/OAuth).  The patient would initiate this, get their pseudonym, scrub their data as much as they want while still adhering to structure (FHIR profile) and integrity (hard to enforce) rules.

The important part about this is that it addresses the Identity problem; in that patient controls the identity. This can't start from the provider (although they can participate upstream). These identities are opaque, verifiable, and permanent. All the attributes that bitcoin leverage.  The patient can choose to be known, by linking their blockchain identifier to their Patient resource; or they can choose to publish a pseudo-Patient resource.

This leverages FHIR as the API; and UMA as the decision engine and source of disclosure rules... So everything that we are working toward in the standards is still needed.

Fraud is still a problem. Not in use of the data, as I covered that; but in publishing false data. This system doesn't address a malicious individual that invents healthcare data and publishes it for value. One individual could invent millions of data and pseudonyms; thus poisoning the actual big-data pool.   Solution might be that some set of authorities do strong identity proofing prior to issuing a pseudonym... so, someone other than the patient knows the true identity... ugg.

This is inspired by the "New Deal on Data"; an effort to build massive big-data while having sufficient rules around abuse.

My articles on  De-Identification, Anonymization, Pseudonymization

• De-Identification for Family Planning 
• FHIR does not need a deidentify=true parameter  
• NIST seeks comments on De-Identification 
• Is it really possible to anonymize data?
• PCAST - Big Data: A Technological Perspective 
• De-Identifying free-text  
• De-Identification: process reduce risk of identification of entries in a data-set
• Fake it properly
• De-Identification - Data Chemistry
• Guidance Regarding Methods for De-identification of Health Information
• The Emperor has no clothes - De-Identification and User Provisioning
• De-Identification is highly contextual
• Redaction and Clinical Documentation

Start at Consent as a FHIR Resource

Last week I posted about the stalemate on Consent, Grahame challenged me to complete it by the end of the week. This week I put a proposal forward. I have taken the examples that have been presented to the HL7 CBCC committee, and created a Consent resource. I did take as much of the Contract resource as was needed by these examples, however I customized them specifically for Consent. This also means many elements are not needed.

I also simplified many elements to just those that our examples need. This does not mean that we won't need to bring back these elements, but rather that they are not needed by the examples.

This is the critical 'Agile' method that I was wanting to use, vs the method of building everything that might ever be needed by an infinite set of imagination. This Agile methodology is a bit more than is required by the FHIR Principles, but is very much a good methodology to assure the focus on implementations and the 80% rule is adhered to.

The important part is that we are hearing from those on the outside (you are all welcome to come inside) that what we have done is too hard to understand, too hard to use, and confusing.

This means that if someone thinks something is missing, they first must describe an example, possibly showing how it can't be encoded today and how they think the model should be improved. This will result in incremental improvement and advancement of the model.

Note I also renamed 'term' to 'except' as the way we are using it in Consent is to list the exceptions to the rule at the base of the consent. Thus it is not all the terms, just the exceptions. This works for both Positive and Negative Consent - Opt-IN with exceptions (exceptions are things not allowed); and OPT-OUT with exceptions (exceptions are things that are allowed).

So, I present the FIRST DRAFT (yes, I expect many improvement opportunities)


This is Consent Resource

Vs Contract Resource

6.7.3 General Model 

The following is the general model of Privacy Consent Directives.

There are context setting parameters:

1. Who - The patient
2. What - The topic - all or specific resources are listed
3. Where - The domain and authority - what is the location boundary and authority boundary of this consent
4. When - The issued and applies - When was this captured and over what timeframe does it apply
5. How - The actions and actor - What actions are covered, what actors are covered. (such as purposes of use that are covered)

There are set of patterns.

1. No consent: All settings need a policy for when no consent has been captured. Often this allows treatment only.;
2. Opt-out: No sharing allowed for the specified domain, location, actions, and purposes;
3. Opt-out with exceptions: No sharing allowed, with some exceptions where it is allowed. Example: Withhold Authorization for Treatment except for Emergency Treatment;
4. Opt-in: Sharing for some purpose of use is authorized Sharing allowed for Treatment, Payment, and normal Operations; and
5. Opt-in with restrictions: Sharing allowed, but the patient may make exceptions (See the Canadian examples).

For each of these patterns (positive or negative pattern), there can be exceptions. These exceptions are explicitly recorded in the except element.

6.7.4 Realm specifics 

6.7.4.1 US Realm sample Use-Cases 

Five categories of Privacy Consent Directives are described in the Office of the National Coordinator for Health Information (ONC) Consent Directives Document released March 31, 2010, and include the following US-specific “Core consent options” for electronic exchange:

1. No consent: Health information of patients is automatically included—patients cannot opt out;
2. Opt-out: Default is for health information of patients to be included automatically, but the patient can opt out completely;
3. Opt-out with exceptions: Default is for health information of patients to be included, but the patient can opt out completely or allow only select data to be included;
4. Opt-in: Default is that no patient health information is included; patients must actively express consent to be included, but if they do so then their information must be all in or all out; and
5. Opt-in with restrictions: Default is that no patient health information is made available, but the patient may allow a subset of select data to be included.

6.7.4.2 Canada Realm sample Use-Cases 

The following scenarios are based on existing jurisdictional policy and are realized in existing systems in Canada. The default policy is one of implied consent for the provision of care, so these scenarios all deal with withdrawal or withholding consent for that purpose. In other jurisdictions, where an express consent model is used (Opt-In), these would examples would contain the phrase "consent to" rather than "withhold" or "withdraw" consent for.

1. Withhold or withdraw consent for disclosure of records related to specific domain (e.g. DI, LAB, etc.)
2. Withhold or withdraw consent for disclosure of a specific record (e.g. Lab Order/Result)
3. Withhold or withdraw consent for disclosure to a specific provider organization
4. Withhold or withdraw consent for disclosure to a specific provider agent (an individual within an organization)
5. Withhold or withdraw consent for disclosure of records that were authored by a specific organization (or service delivery location).
6. Combinations of the above

6.7.4.3 Non Treatment Use-Cases 

Also shown is an example where a Patient has authorized disclosure to a specific individual for purposes directed by the patient (possibly not a treatment case).

End-to-end FHIR testing

There is renewed discussion, much like back in January, around the need to go beyond testing just the FHIR Resource 'interoperability'. Testing Interoperability is not easy, and there are struggles with getting this first level testing done right. But this level testing is not complete enough to give confidence that an application, server, intermediary, analytics engine, or other are really ready to be used.

What we need is a higher level specification to focus on. I think the HL7 "Implementation Guide" could be this, but I am thinking something much higher than is normally documented by HL7. This because what is needed is not a "Standard", but a "Reference System". A 'system' in the broadest of definitions. A system as in a system of systems in a defined environment, and policy framework.

A reference system of systems:

I think it is possible to have a "reference system of systems' as a proof of completeness, that could be used during connectathons and certification.

This reference system needs to pick a minimum-useful set of FHIR resource centric workflows. The 'minimum' part of this is so as to have an end-to-end workflow, but also to not have the end-to-end workflow be the center of attention. 

This is more than just a selection of FHIR Resources. One can show that any one client can 'communicate' with itself through storing and retrieving a Resource on a FHIR Server. This does prove that there is connectivity, but not Interoperability.

Interoperability requires that one can not just communicate but also use the result. Thus it needs an end-to-end workflow where each actor has more than communication as a responsibility. Each actor must do something useful. At least the receivers of data must do something useful. The FHIR Server might just be an intelligent, and important carrier of data.

This reference system of systems needs to pick a specific 'setting'. The setting is the environment being simulated. Again it isn't to declare a best-practice, but simply a reasonable reference. There are an infinite set of settings that healthcare is ultimately working in. We need to pick one. 

What is important in this 'reference' system is to then define a set of reference policies. These policies are not held-up as best-practice, but rather 'one reasonable practice'.  These policies would include Privacy Policies, Security Policies, data retention policies, service level policies. Where policies include Privacy policies, Security policies, authentication policies, audit logging policies, audit reporting policies, data retention policies, service level agreement policies. Also identity policies, like what is a User, and their roles, and their relationships. What is a Patient, with what quality of demographics, cross-reference matching criteria, linking and unlinking responsibilities.

These are not best-practice policies, but rather simply realistic-policy that is representative of reality. Reality is that there is an infinite set of policies too, even an infinite set of realistic policies.

A more controversial aspect might be User Experience expectations. Expectations that might be broad, so as to define just usability goals. How fast can a brand new user understand how to use the system?

All the non-standard stuff

From this combination of a minimal-useful FHIR workflow, environmental setting, and a set of policies; you can then fill the middle with some specific configurations of services. So you define a single Authentication service, choosing one OAuth service with a set of enforcement policies. You choose a consent management system, from the many being defined (FHIR Consent, UMA consent, paper consent, etc). You define an expectation of what security events would be recorded in an AuditEvent, would likely even include actor that does auditEvent reporting. You define response-time expectations. 

A complete system... as a reference system... not as a 'best-practice'.

Doing the work

Back in January I proposed Document Sharing - ala MHD profile centric; which got shot down by HL7 leadership due to the fact I proposed it in the HSI workgroup. ... I failed, should have pursued a solution. HL7 Project Scope Statement 1231

Argonaught could do similar using their flavor of DAF. 

CommonWell could do this. 

Any organization that can take a two steps away from the standards definition could do this. It is not unlike what every HIE, Hospital, Clinic, and PHR must do. The difference is that you are explicitly defining it as a reference system; not as the ONLY system.

HEART can be used, but is, like FHIR, just one part of the system. HEART can't do it alone as they don't have the end-to-end workflow. They don't have the setting context. The HEART profiles would be something included in the reference system.

Focus on end-to-end system of systems

The hard part is that no-one will agree on these Setting and Policy choices. Yet, the specifics of the setting and policies are not important. What is important is setting someting reasonable so that the next stage can be set.

I hope I can participate...

FHIR Consent as a Resource or Profile

For the past year there has been a stalemate that I have tried to control. I think it is time for this stalemate to come to a conclusion. The topic is Patient Privacy Consent; the discussion is if this should be modeled as a core FHIR Resource, or as a core FHIR Profile upon the Contract Resource.

The owner of this discussion is the Community Based Collaborative Care (CBCC) workgroup. This workgroup has produced the CDA Consent Directive, and the original Privacy domain model. The Security workgroup is the one that has the infrastructure to decide and enforce Access Control. Thus the two workgroups work together on this topic. With the CBCC workgroup focusing on how to capture a Patient Privacy Consent, and the Security workgroup focusing on how to enforce this. I am co-chair of the security workgroup and an active member in CBCC.  There are other factors that I won't cover.

When we first started to model Privacy Consent Directive in FHIR, we had just finished (mostly finished) the CDA Privacy Consent Directive. So we had fresh knowledge of what was needed. As we started to do initial modeling, aka working with napkins, we came to a general consensus that what we would end up with would be much like a Contract. There were some that were insistent that this would be perfectly true, while others preferred to just do a Consent.

We took the path of those that were actively involved, vs those that were passive. A moment that I really would like to have changed. But this is exactly the "consensus" process... so any one complaining, simply needs to get actively involved, being more passive is not helpful. Standards are not built by the passive aggressive.

There was an attempt to address this in the Paris Workgroup Meeting; but CBCC didn't formally meet, and thus all the efforts of the community that went to Paris were ignored.

So now we have a Privacy Consent Directive -- Implementation Guide; which is a Profile of the Contract Resource. It is working.articles show that it does respond to the use-cases. It however is not as simple as it could be. This statement is not a statement that the Profile system doesn't work, but a Profile is a layer of complexity. Further because of this Profiling layer we end up with concepts in Contract that are not what would be thought of by those wanting to do a Consent.(Like Contract.topic, Contract.action, Contract.subject).
My blog

I vote for Agile:

I would like us to start over,  I would like a Privacy Consent Directive "Resource" to be defined. Break away from Contract. This does not mean that we loose all the good work we have done, but it does mean we start over.

Use Agile. I want this effort to use Agile, and NOT use a top-down approach. That is to focus on real-world use-cases, and build the Consent Resource only with what is necessary to build. There is no need to build complex layers, when simple layers will do.

This Agile approach does not mean we ignore good available standards. ISO/TS 17975 -- "Health informatics - Principles and data requirements for consent in the Collection, Use or Disclosure of personal health information"  is a fine foundation, along with the work HL7 has done on the CDA Consent Directive. I simply want these to be seen as foundational, and not seen as a demand for some preordained structure.

ISO/TS 17975 has a very simple abstract model of what a consent record should include

— identify the sender, recipient and subject of care,
— include the Purpose of Use or set of purposes which are permitted to be collected and used or disclosed,
— specify the activity permitted: Collection and Use and/or Disclosure,
— include the validity date range,
— be linked directly to the data to which it applies,
— persist with the data to which it applies, and
— be secured in order to preserve confidentiality, integrity, availability in order to provide proof of authenticity of the process and the consent record.

Most of that we get free with the FHIR RESTful model; and simple data elements.

The real work

What we don't get free is the part that we haven't even started to model. The way that the RULES would be encoded.  The above is just the part that identifies the broad meta; the WHO, WHAT, WHEN, WHERE, WHY. This does not address the HOW rules. How do I describe the kind of data I want protected in a kind of way from a kind of people...

More on this topic, when I cover what IHE has just finished - for Public Comment - on the Advanced Patient Privacy Consent (APPC) -- the next generation from Basic Patient Privacy Consent (BPPC).

Transition

I have been unfortunate to have been caught in a broad layoff -- Reduction In Force -- at GE Healthcare. GE Healthcare has been my home for just short of 18 years, and I have loved every minute of it. I have been part of many product, either directly on the team or through consulting with them on the use of Interoperability Standards, Privacy, and Security. These have been fantastically fun exercises in Systems Design.

I have the luxury of taking my time to find a new opportunity. Over the last two months I have spoken to some of you, and your excitement for my list of opportunities has been very gratifying. Over the next few months I will reach out to others, and welcome you reaching out to me.

I describe myself as a System Engineer, Principal Engineering Architect; but am most excited to help enable Privacy respecting Information Exchange. This might be between two healthcare practicing organizations, this might be centered on a Patient managed system, this might be for the purposes of Research. My passion wants to get data moving to where the stakeholder of that data wants it to go, and move it most efficiently, effectively, and accurately.  This means using Interoperability Standards, developing new standards, and working with leadership.

I know there are many opportunities for me as a Consultant, however I would like to find a vendor that has grown up over the past few years and now realizes that they need to take an active role in standards development, possibly a leadership role. I could build their program and fill many of the roles. I come with two leadership positions within HL7, and less formal leadership in IHE and DICOM. I am thankful of HL7 for having a nice transition program that allows me to maintain my membership and thus positions for a short time.

More details on me and my Resume can be found at my LinkedIn page https://www.linkedin.com/in/johnmoehrke