The mechanism for dealing with this in HL7 is a recirculation ballot. A targeted ballot to those that participated in the original ballot asking them to consider the outstanding negative ballot comments and either vote Affirmative to override the negative ballot comments, Negative to agree with the negative comments, or Abstain. The details are in the recirculation ballot package.
The concerns are not unfounded, they are just not related to what the HCS is defining. The HCS is a ‘conceptual level’ concept of using broad concept of security-tags to aid with Access Control for Privacy or Security purposes. It is not a ‘platform dependent’ nor ‘organizational policy’. The specific concerns to be considered are (these are in the recirculation ballot package):
- Data tagging is fragile: I would agree that tagging data is a fragile thing when the tag is conveying current policy. However the HCS is just defining ‘conceptual level’ concept of security-tags, not defining that they must be used or the ‘platform specific’ mechanisms to communicate. Separation of Metadata tags, from Package tags, from Consent Policies is important to robustness and to be agile to policy changes:
- Metadata – Metadata is descriptions of the data, and only the data. This level of security tag really needs to only describe the data.
- Package – The package is the abstract concept of the interaction between parties. It would include push or pull interactions. It thus would include something like assertions of who the user that is requesting (pull) data, and under what purposeOfUse. This level of security tag can carry specific obligations about the communication agreement. It would not be duplicative of Metadata, but could be summarization of the Metadata. It could carry obligations related to the interaction (do-not-print), it could carry pointers to consent policies (see next).
- The unfortunate reality is that the –platform specific -- package level tag carrying is not very mature. Thus Metadata tags often carry these Package tags, or they are part of the overriding policies (e.g. DURSA).
- Consent Policies – This is an independently managed policy information point (PIP) that holds the current status of patient authorizations (aka Consent). This only appears where the parties that are interacting both agree upon one Consent Policy Point. Most of the time a sender and recipient have independently managed Consent Policy Points, as consents tend to be specific to a data-holding organization. There could be a common Consent Policy Point, it would be an independent communications pathway from the package. Most of the time a consent to release is indeed independent of the policy the recipient would need to gain to continue to use or disclose.
- Fine grain tagging could paralyze medical practice. – I don’t necessarily disagree, but this is the concern of Policy, and specific on fine-grain the CDA internal tagging discussion. The HCS is defining only at the ‘conceptual level’ and not indicating if this is fine-grain or coarse-grain. The HCS has no CDA specifics in it. The CDA specific use of the HCS is part of the DS4P ballot, which is being re-balloted. I have pointed at the use of "Transforms" as an alternate model.
- LOINC and SNOMED should be used and not a security/privacy specific vocabulary – It is hard to argue that universal and perfect use of these vocabularies would make life easier. Security nor Privacy are going to change that. However from the engine that needs to control security/privacy access, operating on a much smaller subset that represents the rollup from a security/privacy perspective is more efficient and more likely to enforce the right rules. This roll up is done once, rather than at each access (typically). This further supports security/privacy codes as actionable when the content is free-text or graphical or minimally coded. The HCS can also be used in DICOM or IHE standards.
- Vocabularies pointed at include some dangerous codes – YES they do. The fact that the code exists does not mean it must be used. Even LOINC and SNOMED have some questionable codes, more so in history. Thus the comment should be directed at policies that would be choosing a value-set from these vocabularies. The HCS is just pointing at existing vocabularies and doesn’t forbid other vocabularies.
- Rules are regional – this was not mentioned in the negative comments, but has come up. The rules in one region, the sending region, might not be the same as the rules in the receiving region. Thus presuming that the proper thing will be done will fail. See Rob’s excellent article on this. http://fairhaven.typepad.com/my_weblog/2013/12/confidentiality-code-use-cases.html
- The HCS is predicate work to the DS4P ballot. The DS4P ballot is being re-balloted.
- The HCS is being referenced in IHE as a way of using the multi-valued metadata entry – confidentialityCode.
- The HCS is being referenced in FHIR
If you were involved in the original HCS ballot, when the recirculation ballot opens on Monday, please set your vote to Affirmative.
Patient Privacy controls (aka Consent, Authorization, Data Segmentation)
- Defining Privacy
- Safety vs Privacy
- Privacy Consent State of Mind
- Defining Privacy
- 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
- Data Segmentation - now I know where the term comes from
- Healthcare access control scope constraints on OAuth tokens
- Advanced Access Controls to support sensitive health topics
- Policy Enforcing XDS Registry
- Healthcare Metadata
- Texas HIE Consent Management System Design
- IHE - Privacy and Security Profiles - Access Control
- Data Classification - a key vector enabling rich Security and Privacy controls
- Healthcare Access Controls standards landscape
- Handling the obligation to prohibit Re-disclosure
- Access Controls: Policies --> Attributes --> Implementation
- IHE - Privacy and Security Profiles - Document Encryption
No comments:
Post a Comment