Explicit OPT-IN is most simple and effective Privacy Consent model for Health Information Exchanges (HIE). It can be managed and enforced local to where the data lives. Being Explicit OPT-IN it offers no surprise to the Patient, limiting the 'ick' factor.
Background:I am encouraged by many HIE efforts that are developing. John Halamka offered his opinion on HIE Consent Policy. Through some clarifications with him in comments on his blog article I understand and agree with what he is proposing. I have further refined the understanding in a Google+ discussion thread.
I have pointed at the Connecticut policies which are consistent. I understand that within the private walls of the Regional Extension Centers (REC) they are running a survey that is coming up with similarly simple yet effective system. I have also been involved in other HIEs doing similar.
The proposal is the most basic of Consent policies where the patient has control from the start. That is that nothing is shared with other organizations until the patient chooses to share (OPT-IN). It doesn’t stop there, but also includes ability to change their mind (OPT-OUT). The critical aspect is that it is a rather binary state, either you are sharing or not.
Background:I am encouraged by many HIE efforts that are developing. John Halamka offered his opinion on HIE Consent Policy. Through some clarifications with him in comments on his blog article I understand and agree with what he is proposing. I have further refined the understanding in a Google+ discussion thread.
I have pointed at the Connecticut policies which are consistent. I understand that within the private walls of the Regional Extension Centers (REC) they are running a survey that is coming up with similarly simple yet effective system. I have also been involved in other HIEs doing similar.
The proposal is the most basic of Consent policies where the patient has control from the start. That is that nothing is shared with other organizations until the patient chooses to share (OPT-IN). It doesn’t stop there, but also includes ability to change their mind (OPT-OUT). The critical aspect is that it is a rather binary state, either you are sharing or not.
I spoke of this long time back in Stepping stones for Privacy Consent. John Halamka and I have covered his space 2 years ago in Consumer Preferences and the Consumer. And many other blog article: The meaning of Opt-Out, Opt-In, Opt-Out.... Don't publish THAT!, Consent standards are not just for consent, Consumer Preferences and the Consumer, and RHIO: 100,000 Give Consent.
Implicit vs Explicit:The main statement here is that the ‘default’ value is OPT-OUT. Meaning if you don’t know the state of the Privacy Consent, then you must assume OPT-OUT. In an ‘implied’ consent environment, like HIPAA the default value is OPT-IN, meaning the assumption is that the patient wants their data shared. The difference is important only at what the understanding is to start with. HIPAA is Implied Consent, the suggestion for an HIE is Explicit Consent. Once a state for Consent is known, the mechanism works the same way when the patient chooses to change their mind. The difference is simply what the default is to begin with.
I think it made sense in HIPAA to have implied consent, as the scope of HIPAA consent is for use within the Covered Entity. The explanation in HIPAA for this implied consent is that the patient has already chosen to walk into the healthcare facility, it is this act of walking into the facility that is their expression of Consent. Yes there is lots of argument that this should have been Explicit, but it isn't. I am just saying that I do understand the logic given in HIPAA.
I think it is equally logical for HIE to totally change that default behavior to an Explicit Consent. The Patient is not walking into the virtual HIE environment, they are visiting their care provider; thus it is right to ask the patient how far and wide they want their data available. When the patient isn't surprised, they feel more in-control.
Enforcement:A key to making this both simple and effective is to have the data holder enforce this control. Adding this factor greatly simplifies Consent Management, as it makes it totally a local problem. Local in this case meaning that the data holder is the only one that needs to know what the current status of Consent is. That is when someone asks for data about a specific patient, the data holder looks at the status of Consent and either returns the data asked for, or returns no data.
The requester doesn’t need to know the status of Consent, as they either get information or not. This is an important, but hard to understand, simplicity. This is a core part of the NwHIN-Exchange today. This simplicity is both elegant and effective across the various privacy landscape that makes up the USA.With something like NwHIN-Exchange or even NwHIN-Direct; this model is very easy to implement.
XDS specific enforcement:This enforcement gets a little harder when you have some central infrastructure that knows something about the patient, like found in XDS -- Registry. In this case one does need to think a little harder on what the Policy (OPT-IN and OPT-OUT) mean to this Registry. In the XDS environment one needs to determine if the central Registry should be blinding entries when the Consent is in OPT-OUT state.
It might be that disclosing what documents are available is not considered a problem, but it might be.
Enforcing Consent at the Registry is not too hard, but does mean that each organization involved in the HIE must communicate to the HIE their current state of consent for that patient. And the Registry must determine for each source of data if it has an OPT-IN for that organization. This is not as simple, but still is rather simple. This is the primary domain where BPPC is used, as the flag indicating OPT-IN vs OPT-OUT.
There is also the question of if this same thing needs to be done with the XDS wide Affinity Domain Patient ID system. In the most formal form defined in XDS, this should not be necessary as the only thing one learns from a XDS Affinity Domain Patient ID is – given your patient ID, what is the Affinity Domain ID. This doesn't tell you anything about any data sources, just that the patient is known. The issue comes with some implementations of this is more like a Multiple-Patient-Identity cross-reference (PIX Manager). Meaning that what you get back is not just the Affinity Domain ID, but also all the cross-referenced ID values. This is not called for in XDS, but is often just done because the data is known.
Special Cases (Sensitive topics):There is some data that is so sensitive that it likely should simply not be shared until we get far more complex Controls designed and deployed widely. This doesn’t mean that they are completely not portable, but rather they should be shared very carefully. This can again be simply and effectively controlled at the data holder. When data is created a decision can be made as to if this data falls into the special topics, or falls into the normal clinical data.
I might even suggest that this kind of data is exactly the kind of data that calls for the Direct push model. Many people look at Direct and get angry that it has no Consent or Access Control built in; I will point out that it actually very explicitly pushed these as Pre-Conditions. Meaning that there is some decision PRIOR to pushing the data that determines if it is the right thing to do. In the case of Sensitive Topics this decision is clear and clean. What the Direct Project has going for it is that it is indeed a directed push from the one with the data to the one who needs the data (and has the legitimate authorization). The security model is strong, if somewhat hard to execute.
Break-Glass:The topic of 'break-glass' is very broad, but needs to be discussed. First, what is it that everyone thinks is Break-Glass. Please don't use the emergency room as break-glass; this may not be scheduled from the patient's perspective, but it is very controlled from the Healthcare Provider perspective. Access by people in the emergency room is simply, access by people in the emergency room. This is a functional role. It needs to be clear what rights this functional role has regarding OPT-IN and OPT-OUT.
Advancements:This simple and effective HIE Consent is NOT the final solution. It is proposed as a stepping stone. It is useful for a large number of patients. There is plenty of standards work going on now to define better solutions. The good news is that these solutions are building on existing standards. Both standards we are using today for Consent, but also standards that are used in other industries. Healthcare is special as the data is very personal about the patient; and the patient has a strong right globally to control their data.
Conclusion:Start sharing using an Explicit OPT-IN environment. Where the OPT-IN is gathered and enforcement at the data holder location. Stepping stones will advance the state-of-the-art.
There is also the question of if this same thing needs to be done with the XDS wide Affinity Domain Patient ID system. In the most formal form defined in XDS, this should not be necessary as the only thing one learns from a XDS Affinity Domain Patient ID is – given your patient ID, what is the Affinity Domain ID. This doesn't tell you anything about any data sources, just that the patient is known. The issue comes with some implementations of this is more like a Multiple-Patient-Identity cross-reference (PIX Manager). Meaning that what you get back is not just the Affinity Domain ID, but also all the cross-referenced ID values. This is not called for in XDS, but is often just done because the data is known.
Special Cases (Sensitive topics):There is some data that is so sensitive that it likely should simply not be shared until we get far more complex Controls designed and deployed widely. This doesn’t mean that they are completely not portable, but rather they should be shared very carefully. This can again be simply and effectively controlled at the data holder. When data is created a decision can be made as to if this data falls into the special topics, or falls into the normal clinical data.
I might even suggest that this kind of data is exactly the kind of data that calls for the Direct push model. Many people look at Direct and get angry that it has no Consent or Access Control built in; I will point out that it actually very explicitly pushed these as Pre-Conditions. Meaning that there is some decision PRIOR to pushing the data that determines if it is the right thing to do. In the case of Sensitive Topics this decision is clear and clean. What the Direct Project has going for it is that it is indeed a directed push from the one with the data to the one who needs the data (and has the legitimate authorization). The security model is strong, if somewhat hard to execute.
Break-Glass:The topic of 'break-glass' is very broad, but needs to be discussed. First, what is it that everyone thinks is Break-Glass. Please don't use the emergency room as break-glass; this may not be scheduled from the patient's perspective, but it is very controlled from the Healthcare Provider perspective. Access by people in the emergency room is simply, access by people in the emergency room. This is a functional role. It needs to be clear what rights this functional role has regarding OPT-IN and OPT-OUT.
Advancements:This simple and effective HIE Consent is NOT the final solution. It is proposed as a stepping stone. It is useful for a large number of patients. There is plenty of standards work going on now to define better solutions. The good news is that these solutions are building on existing standards. Both standards we are using today for Consent, but also standards that are used in other industries. Healthcare is special as the data is very personal about the patient; and the patient has a strong right globally to control their data.
Conclusion:Start sharing using an Explicit OPT-IN environment. Where the OPT-IN is gathered and enforcement at the data holder location. Stepping stones will advance the state-of-the-art.
No comments:
Post a Comment