I was approached with a privacy use-case that is common to bring up when explaining the deficiency of today's privacy standards. I don't disagree that there is a deficiency, but do want to explain how we get there. The use-case is one where the sender of data wants to express to the receiver of data specific obligations. For example, that the receiver must get the patient's authorization before using the data. What troubling is that this requirement often times is directed toward the confidentialityCode as being insufficient to carry this obligation.
The first problem we have is that healthcare decided to call their 'data classification' metadata 'Confidentiality Code', thus anything that is related to 'confidentiality' is naturally directed toward that metadata entry. This is not the role of the confidentialityCode (Data Classification), it is the role of either static policy or patient policy or transactional policy. The confidentialityCode needs to be simply a data classification that simply represents how sensitive the data inside the object (Document) is. If it contains anything more than itself exposes information. Hence why there are efforts to deprecate confidentialityByInfoType (ETH, HIV, PSY, SDV), as these are clear indicators of sensitive medical conditions. see: Data Classification - a key vector enabling rich Security and Privacy controls. Note that this same confidentialityCode is available on CDA, HL7 v3 messages, HL7 v2 messages, DICOM transactions, as well as the IHE XDS/XCA/XDR/XDM. It is usable at a few different scopes within these as well (whole document, object, section, etc). So it is important that we have a simple concept that is used the same way everywhere.
Static policy is the kind of policy that is built up through regulations and business agreements (DURSA). Static policy is the kind of thing that is normally seen as security policy, but sometimes business rules engines enforce some of these policies. I refer to these as ‘static’ because they don’t change often. They can include dynamic shifts in the context that have different results, for example break-glass. Static policy is not to be confused with unchanging policy. The main point of static policy is that these are the defaults when there is no patient policy or transactional policy. The static policies are generally the kinds of Role-Based-Access-Control rules. That explain (over simplified) which users have which roles that have which permissions and which permissions authorize access to which type-of-data. Where type-of-data can be tied to an object-type, table-row, table-column, etc or it can be a confidentialityCode value. In this way a user is authorized through their roles to have access or NOT to specific confidentialityCodes. So Dr Bob has access to NORMAL data but not Restricted. The static policies do need to explain how patient policy and transactional policy will be handled.
Patient policy is the kind of patient specific requests and/or agreements commonly spoken of as consents, this is where most of the standards work is right now. A Patient policy applies to all data that is specific to that patient. By corollary a patient policy does not apply to data not specific to that patient, so it doesn’t apply to other patients data or generalized business data or de-identified data. A Patient policy can be just as complex as a Static policy, it is just specific to that patient. A Patient policy needs to explain how it interacts with the static policies and transactional policies. A Patient policy needs to explain what exceptions are allowed as well, for example a patient policy should explain if the patient allows a break-glass exception. A specific example is in Australia where a patient opt-out is non-overrideable, there is no break-glass. Patient policy is also where specific authorizations occur, such as identifying a guardian; and where specific denials are as well, such as estranged spouse.
Policy hopping (my term): In simple form this is what the DURSA provides and what NHIN Direct relies on. It says that once a document source decides to release documents to a document consumer, that they are fully trusting the document consumer to do the right thing. The document source must make sure that they have the right things in place to release the document, but once it is released they have no further control over the document. If the sender is not comfortable with this, then they simply should not send the document. The document consumer is given no specific authorization or restrictions in the transaction; there might have been some out-of-band ‘transactional’ agreements but they are unknown to the transport. The document consumer must do what is right in their context, if their context (State rules) require them to get a consent before viewing the documents then this is what they need to do. In the NHIN the consent that the document source has for their purposes is not transferred to the document consumer. There might be a consent that controls the ‘discoverability’ and ‘releaseability’ of the documents, but it does not authorize the document consumer beyond that.
It is not well known that in the NHIN Exchange under XCA, and regional Health Information Exchanges using XDS; that the document does stay in the control of the sourcing ‘organization’. Specifically with XDS the Document Repository holds the document until the document consumer pulls it. This Document Repository actor can be fully managed by the sourcing organization and thus an access control decision can be made at the time that a document consumer pulls the document. It is true that a Document Repository can be shared among sourcing organizations, and that a Document Repository is not compelled to make access control decisions. But the Architecture supports fully distributed and federated control. Specifically with NHIN-Exchange (XCA) the document retrieval does have access control checks that would deny access if the access requested was incomplete or inappropriate. There are HIE architectures where the data is centralized and thus the document source loses control as soon as they publish.
The use-case given above is specifically looking for a transactional policy, that is a way to communicate the policy that applies to the content of the transaction. There is so much work that needs to be completed before we can describe the policy in enough detail to place it on a transaction. This is not to say that there is nothing close, the current consent standards (BPPC, and the soon to be final HL7 CDA Consent) can be delivered over transactions. But these are very coarse policies, nothing that would really be the kind of detail expressed on a transaction by transaction basis. A Transactional policy really needs to be more associated with the transaction itself, rather than as a component of the content. Transactional policies are not being worked on in healthcare specific space, but there is much work going on in general IT. I am involved in some of these non-healthcare standards organizations and hope that they will converge.
The confidentialityCode metadata value should not be overloaded to take on policy obligations; it should stay simply a data classification.
No comments:
Post a Comment