This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR Security Issues Page"
Jump to navigation
Jump to search
Ewoutkramer (talk | contribs) |
|||
| Line 11: | Line 11: | ||
** FHIR resources? Use of REST? FHIR extensions? | ** FHIR resources? Use of REST? FHIR extensions? | ||
** For example, setting cardinality/conformance flags to allow for anonymization / restriction of disclosure / redaction | ** For example, setting cardinality/conformance flags to allow for anonymization / restriction of disclosure / redaction | ||
| + | ***''HL7 Healthcare Privacy and Security Classification System (HCS), which is included in the May 2013 Ballot, describes the use of security labels that convey privacy and security policy requirements such as those listed. This 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 and must be matched by the attributes in a requester's clearance.'' | ||
* 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 - 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? | * 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 well established "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 [http://wiki.siframework.org/SAMHSA-VA-Pilot 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? | * 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? | * Does the partitioning of Person, Patient, Location and Organization information into their own resources simplify the processes for anonymization? | ||
| − | * Are | + | * Are there structures or extensions needed to tie resource elements to policies or consents? |
| + | **''Yes, security labels.'' | ||
* Security issues from two perspectives | * Security issues from two perspectives | ||
** those familiar with healthcare security concerns, but not necessarily the use of web technology | ** 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 | ** those familiar with web technology security issues, but new to the specifics of healthcare | ||
* (Feel free to add others) | * (Feel free to add others) | ||
| − | |||
* is there a role for digital signatures in the RESTful context | * is there a role for digital signatures in the RESTful context | ||
* should the message resource have a security element like MSH-8? | * 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? | * what should the confidentiality and access control content in the document header be? | ||
| + | **''Answer is in the HCS and HCS Guide for CDA because that is the format under consideration by ONC for DS4P | ||
* 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? | * 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 05:13, 6 April 2013
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
- HL7 Healthcare Privacy and Security Classification System (HCS), which is included in the May 2013 Ballot, describes the use of security labels that convey privacy and security policy requirements such as those listed. This 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 and must be matched by the attributes in a requester's clearance.
- 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 well established "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 is in the HCS and HCS Guide for CDA because that is the format under consideration by ONC for DS4P
- 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?
