PCF_18: Advanced required sensitivity codes.

[JohnMoehrke]

In the Advanced is a required subset of ConfidentialityCodes (N, R), and Sensitivity codes (ETH, ETHUD, OPIOIDUD, PSY, SEX, and HIV). Is this enough? Is this too many? What should be required of the PCF? Note that required in the PCF does not mean that a deployment implementation must use all of these codes.

There is likely no minimal set that is universally globally required. After Public-Comment the current list of Sensitivity Codes that are mandatory is likely to be trimmed. Should the sensitivity classifications that are moved out of the mandatory requirement still listed as a useful mention?

[slagesse-epic]

IMO, the Confidentiality Codes are generic enough to be required, but the Sensitivity codes will be highly dependent on the Patient Privacy Policy. Requiring those codes in a technical specification opens the development of the specification to debate over which policies are reasonable or unreasonable, which are discussions better left to the development of the policies themselves.

[JohnMoehrke]

I could see us having a specific use of Restricted that is not differentiated as to WHY it is restricted. Thus the data are presumed to be in either Normal or Restricted, and thus Consents and Access Controls can focus only on N vs R. One example that has been discussed is business rules that are applied to any data within that organization that might fall into any restricted sensitivity. This kind of a rule might not need to be as specific to 'why'.

[JohnMoehrke]

regardless of if we remove any of these sensitivity codes, we must make it more clear that organizations should be able to define additional sensitivity codes that they can distinguish (SLS) and for which they want Consent and Access Control to address. We might explain this with a legitimate sensitivity code that we don't mandate, or might explain this with a fake code. Possibly a use of SEX as an emerging sensitivity topic, but one that we have no examples to build upon. (See issue #33 )

[JohnMoehrke]

discussed today on the PCF call.

There is interest in adding clarity. The important thing to consider is that each of the actors may be provided by a different vendor. Thus the Consent Recorder, and the Consent Enforcement Point must be aligned in the realworld. (The Consent Registry and Consent Decision Service can likely deal with undefined codes)

The fact that the enforcement point is free to implement the SLS functionality in an undefined way does lead to less deterministic testing and conformance claims. This fact is true if we use standard codes or if we use as a minimum made up codes like fooBar sensitivity.

One possibility discussed is to have the Consent Enforcement Point declare in the IHE-IntegrationStatement the sensitivity codes that it can support, and explain to the Consent Recorder that it needs to be able to be configured with the list of codes it can offer to the patient. --> Note that this is likely needed even with a defined sub-set of sensitivity codes.

The defined sub-set does enable the Consent Recorder to have workflows that explicitly handle these codes. Having an undefined, or made up code, makes this much harder to implement.

Could we have at least two defined standard codes? Is the 6 too many, but 2 codes would be reasonable?