This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Security Issues Page"

From HL7Wiki
Jump to navigation Jump to search
Line 24: Line 24:
 
* should the message resource have a security element like MSH-8?
 
* should the message resource have a security element like MSH-8?
 
* what should the confidentiality and access control content in the document header be?
 
* what should the confidentiality and access control content in the document header be?
 +
* 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?
  
 
== Discussion ==
 
== Discussion ==

Revision as of 20:15, 8 September 2012


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?
  • If so, what would it contain?
  • 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
  • Is there anything intrinsic to the design of FHIR - resource design, extensions, profiles, REST that could be improved to better support security considerations?
  • Is there anything intrinsic to the design of FHIR that provides significant security benefits over more traditional approaches?
  • 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 their structures or extensions needed to tie resource elements to policies or consents?
  • 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?
  • what should the confidentiality and access control content in the document header be?
  • 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?

Discussion