This article covers the constraints often placed on an approved use of healthcare data. These are the conditions, restrictions, obligations, or handling caveats.
When a Patient allows use of their data, there is almost always restrictions. Some restrictions are supported in access control rules. That which I have already covered in Vectors through Consent to Control Big-Data Feeding frenzy. I am not going to re-describe "Vectors". The Vectors are used in rules to determine if an access is allowed or denied.
Some of those Vectors are similar to constraints, such as the discussion about "Treatment", "Payment", or "Operations. That I covered in Consent Basis in Controlling Big-Data Feeding frenzy. An important message from that specific example is "Purpose Of Use". This is both a "Vector", and a "Constraint". That is a rule can be based upon a user requesting, where the request indicates that the user is asserting that they will only use the data for a specific Purpose Of Use (e.g. "Treatment"). In this case the "Purpose Of Use" is satisfied at the "Vector" stage.
Purpose Of Use can also be a "Constraint", in that data might get released with a constraint attached indicating a set of Purpose Of Use that are allowable. This might be done when the user indicates too many Purpose Of Use, where the Privacy Consent only allows a subset. Or it might be used when the User request context didn't have a clear Purpose Of Use declared.
A Constraint, in some technology is called an Obligation, in other technology it is just part of an Authorization Decision. What I am focused on here is some constraint that goes along with the data that will further restrict use or cause specific action.
Some Constraints are not explicitly said in the technology layer, but are part of Policy that enabled communication. Such is the case with a "Data Use" agreement. Here is where Purpose Of Use is seen again, often a communications "Data Use" agreement authorizes only specific kinds of uses. Some Health Information Exchanges have a restriction on"Treatment", Some Health Insurance Exchanges have a restriction on "Payment". Some Research networks have a restriction on "Research".
Up to now I have mostly talked about Purpose Of Use; which is relatively easy to understand and enforce. The following are more specific constraints. These too might be in the Data Use policy, might be represented in Vectors, or might be communicated with the data.
The following is some of the ideas in the space of constraints. Many of these have specific Obligation, or PurposeOfUse codes.
When a Patient allows use of their data, there is almost always restrictions. Some restrictions are supported in access control rules. That which I have already covered in Vectors through Consent to Control Big-Data Feeding frenzy. I am not going to re-describe "Vectors". The Vectors are used in rules to determine if an access is allowed or denied.
Some of those Vectors are similar to constraints, such as the discussion about "Treatment", "Payment", or "Operations. That I covered in Consent Basis in Controlling Big-Data Feeding frenzy. An important message from that specific example is "Purpose Of Use". This is both a "Vector", and a "Constraint". That is a rule can be based upon a user requesting, where the request indicates that the user is asserting that they will only use the data for a specific Purpose Of Use (e.g. "Treatment"). In this case the "Purpose Of Use" is satisfied at the "Vector" stage.
A Constraint, in some technology is called an Obligation, in other technology it is just part of an Authorization Decision. What I am focused on here is some constraint that goes along with the data that will further restrict use or cause specific action.
Some Constraints are not explicitly said in the technology layer, but are part of Policy that enabled communication. Such is the case with a "Data Use" agreement. Here is where Purpose Of Use is seen again, often a communications "Data Use" agreement authorizes only specific kinds of uses. Some Health Information Exchanges have a restriction on"Treatment", Some Health Insurance Exchanges have a restriction on "Payment". Some Research networks have a restriction on "Research".
Up to now I have mostly talked about Purpose Of Use; which is relatively easy to understand and enforce. The following are more specific constraints. These too might be in the Data Use policy, might be represented in Vectors, or might be communicated with the data.
The following is some of the ideas in the space of constraints. Many of these have specific Obligation, or PurposeOfUse codes.
- Purpose Of Use
- Treatment
- EmergencyTreatment
- Payment
- Operations
- Resarch
- PublicHealth
- Marketing
- Donation
- Access
- no access beyone given user
- Persistence
- do not persist -- delete after use
- do not print
- persist only in encrypted form
- De-Identification
- declassify
- mask
- redact
- minor
- Auditing
- audit rail
- notification of subject on use
- Future Consent
- re-use requires new consent
- restrict to specific users
Conclusion
It is very unusual for a Privacy Consent to allow access without Constraints. Most of the time the constraint is built into the Policy that enabled communications, so it doesn't need to be said in the communication. Much of the time the constraint can be handled as part of the Access Control decision. Sometimes the constraint needs to be communicated along with the data, often referred to as an Obligation. This is only done when there are assurances that the residual constraint, Obligation, will be enforced..
No comments:
Post a Comment