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).