FHIR Security Issues Page

FHIR is a brand new initiative that gives HL7 a somewhat green field for "doing things right" and also promises to bring a lot of new players to the healthcare interoperability table. Rather than waiting until FHIR sees significant adoption before looking at security considerations (and possibly needing to retrofit things into existing implementations), it makes sense to take a good look at security now, while the specification is in its formative stages. This topic provides a starter-list of considerations that may be relevant to the FHIR space. Feel free to add additional considerations and to contribute your view-point to the answers. I'm hoping some of these might spark a project or two within the HL7 Security Work Group, but contributions and solutions are welcome from other quarters as well.

Questions

• Should there be a Security chapter that is part of the FHIR standard?
  • There should be a Privacy and Security chapter as part of the FHIR standard.
• If so, what would it contain?
  • An explanation of how to use security labels to convey the confidentiality, sensitivity, integrity, and handling caveats required to comply with jurisdictional, organizational, and patient privacy policies (consent directives) governing a FHIR resource.
• Can we provide a quick summary of security & privacy considerations around
  • FHIR resources? Use of REST? FHIR extensions?
  • For example, setting cardinality/conformance flags to allow for anonymization / restriction of disclosure / redaction
    • FHIR should reference and extend as needed the HL7 Healthcare Privacy and Security Classification System (HCS), which is included in the May 2013 Ballot. HCS describes the use of security labels to convey privacy and security policy requirements such as those listed. HCS is based on a number of well-established NIST and ISO standards. HCS requires the use of HL7 Privacy and Security Vocabulary for the "tags" or metadata that are assigned to protected resources in security labels, which must be matched by the attributes in a requester's clearance in order to access and use the resource.
• Is there anything intrinsic to the design of FHIR - resource design, extensions, profiles, REST that could be improved to better support security considerations?
  • Use HCS security labels as metadata to protect the resource.
• Is there anything intrinsic to the design of FHIR that provides significant security benefits over more traditional approaches?
  • Yes, FHIR resources are discreet units of healthcare semantics or aggregation of such units so as to allow security labels to be applied at different levels and to support the roll up of the security labels in accordance with "dominance rules" to create a "high water mark" for the aggregation of resources. This permits the sender to inform the receiver about privacy and security requirements that must be complied with at the aggregate (e.g., a clinical document) and disaggregated level - e.g., each medication, procedure, order/result, and diagnosis that may be extracted for another use. For more information see ONC Data Segmentation for Privacy (DS4P)VA/SAMHSA Pilot videos and papers.
• Can/should there be a version of the security cook-book for resource design? Extension design? Profile design?
• Does the partitioning of Person, Patient, Location and Organization information into their own resources simplify the processes for anonymization?
• Are there structures or extensions needed to tie resource elements to policies or consents?
  • Yes, security labels.
• Security issues from two perspectives
  • those familiar with healthcare security concerns, but not necessarily the use of web technology
  • those familiar with web technology security issues, but new to the specifics of healthcare
• (Feel free to add others)
• Is there a role for digital signatures in the RESTful context
• Should the message resource have a security element like MSH-8?
  • MSH-8 doesn't provide much in the way of security and is not broad enough for use outside of a legacy system. According to v.2 Chapter 2: "MSH-8 Security (ST) 00008 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified."
• What should the confidentiality and access control content in the document header be?
  • Answer in the HCS and HCS Guide is for CDA header and XD* document entry wrapper because that was the format under consideration by ONC for DS4P. CDA has several limitations that make application of privacy and security metadata (security labels) more difficult. FHIR resource document header should make assigning metadata more flexible. Again, FHIR resources should be able to be "tagged" at the necessary levels, so if a FHIR document is an aggregation of discrete clinical facts, each fact should be "taggable".
• Caching is an important feature to make service endpoints web-scalable. However, when you do caching (presumably using some dedicated middle tier caching servers) you lose the ability to track who has seen which data. Should we disallow caching?