Stop using OPT-IN and OPT-OUT

In various conversations on Consent, including #FHIR Consent, discussions often get mixed-up because we use the terms "OPT-IN" and "OPT-OUT". These terms are trouble. We need to stop using “OPT-IN” and “OPT-OUT”.

I want to propose a set of terms. I will never get everyone to stop using opt-in and opt-out, but where better terms can be used, I propose better terms. Better, as in, more descriptive and accurate communications.

The reason is that these terms can mean very different things based on what the person listening is thinking. They can mean a consent ‘model’ or they can mean a consent ‘state’ or they can mean an 'action' by the patient. Especially confusing because there is a possibility for all thee to be the same and not the same.

State Model --

In this model we look to consent as a state-diagram, also called a finite-state-machine, or a directed-graph. In a state-diagram is made up of a finite number of 'states' diagrammed as circles, with arrows indicating events that can occur.  A state-transition-table, and uml representations can also be used.

At the most gross level of Privacy Consent we recognize that there is a 'state' where data is shared, for legitimate medical treatment purposes, with trusted partners, who are authorized by their licensing and role. And another state where data is NOT shared, except for legitimate and authorized medical emergency...

Note I am defining a Treatment purpose of use, setting parameter that indicate that the sharing would be for legitimate and authorize purposes. This is to counter distracting arguments, distracting from my point. Insert any caveats necessary, and there is still an understanding of OPT-IN and OPT-OUT as a state of consent.

as a State:

• OPT-IN state – Permitted to sharing the patient's data for Treatment purpose
• OPT-OUT state – Denied to share the patient's data for Treatment purpose

I think this is better said using the terms Permit and Deny

Event Model

This might also be called the 'action'.  It is often predominately determined by regulation. 

Some view OPT-OUT as a model where absent an indication from the Patient, their data can be used. This is to say that the patient must OPT-OUT if they don't want their data shared.

Some view OPT-IN model as one where absent an indication from the Patient, their data can not be used.

You will note that this model uses terms that are also aligned with the 'first action' that a patient can do.

I think this is better represented by the "event" or "action" of the patient giving authorization, that is to "Authorize"; or the patient revoking that authorization, that is to "Revoke".

First state

This perspective uses the term to define the starting point, as the state.

• opt-in environment, the patient is automatically put into opt-in state. 

That is improper definition, as it uses the term to define the term. So I will re-write it using the "Permit" state term

• opt-in environment, the patient is automatically put into Permit state. 

This perspective is important to understand, but does not help with any clarity. As once the patient has made that first action then the distinction is not valuable. That is to say, the second or third or fourth action just confuse the perspective.

I propose we use:

States (Leveraging these terms as used in XACML):

• Permit – a ‘state’ data is shared 
• Deny - a ‘state’ of NOT sharing 

Model - Initial State

• Implied-Consent – A ‘model’ where without a consent the patient data sharing is Permitted.
• Start in Permit state
• Explicit-Consent – A ‘model’ where without a consent the patient data sharing is Denied
• Start in Deny state

The Initial State is usually driven by regulation. Such as Such as HIPAA, which is a model where patient data is allowed to be used for Treatment, Payment, and Operations without getting a consent from the patient.  It is common for HIPAA to be called an Implied-Consent environment, for the patient has implied their consent by seeking treatment.

Where as EU has as an Explicit-Consent dominant model. That is that no action on data without consent from the individual that data is about.

Explicit-Consent is also common with sensitive topics, that are considered more sensitive than normal health topics. Likely due to stigma. These topics are often held to an Explicit Consent model, even where normal health topics follow Implied Consent.

Also some regions, or even organisations simply choose to use an Explicit-Consent model for various reasons. Explicit-Consent can be seen as more Privacy Principled, but can also impede progress that might be 'implied'

I propose a set of terms, while not defining terms for the 'actions'. This because the actions are what tends to be very realm specific. Some environments allow a verbal consent, others allow a web-form checkbox, others require digital signatures, others have very specific language, others have special technology, others allow for delegation and assignee, etc. So the actions, or 'state transitions' are much harder to agree upon.

And, there are certainly more states...

Updated: 4/6/2017 to include recommended "Event" description and diagram