October 28, 2014 Security WG Conference Call

Meeting Information

Back to Security Main Page

using GotoMeeting.com with ID of 667556909

Attendees

x	Member Name		x	Member Name		x	Member Name		x	Member Name
x	Mike DavisSecurity Co-chair		x	John MoehrkeSecurity Co-chair		.	Trish WilliamsSecurity Co-chair		.	Alexander Mense Security Co-chair
.	Chris Clark		x	Johnathan ColemanCBCC Co-Chair		x	Kathleen Connor		x	Duane DeCouteau
.	Reed Gelzer		x	Suzanne Gonzales-WebbCBCC Co-chair		x	Rick Grow		.	Ken Salyards
x	Mohammed Jafari		.	Don Jorgenson		x	Galen Mulrooney		.	Amanda Nash
.	[1] Steve Jones		x	Diana Proud-Madruga		.	Harry Rhodes		.	Aaron Seib
.	Ioana Singureanu		x	[mailto: Zack(?)] Kaiser		.	Tony Weida		.	Paul PetronellimHealth Co-chair
x	Paul Knapp		.	Steve Hufnagel		.	Gary Dickinson		.	Tim McKay

Back to Security Main Page

Agenda DRAFT

1. (05 min) Roll Call, October 21 Meeting Minutes
2. (15 min) Financial Management and changes within FHIR
3. FHIM S&P Information Model - Galen and Kathleen
4. Security WG Time Change - Discussion and Vote
5. (05 min) Data Provenance & Patient Friendly Language/FHIR CD Update - Kathleen and Suzanne
6. (10 min) Bringing SPO to SNOMED CT
7. (10 min) PSS EHR, Privacy and Security Joint Vocabulary Alignment Project - Diana
8. (10 min) Question on the FHIR Security Event sensitivity wrt to Security Labels
9. (as time allows) FHIR disposition - review/discussion, ongoing agenda item
10. separate call/additional time for Security/Privacy DAM revision/update (January Informative ballot, Security-SOA ballot)
11. (05 min) Other business, action items, and adjournment

Meeting Minutes

Approval of meeting minutes

Meeting minutes for October 21 unanimously approved.

Security Time Change

Discussion and Vote

Suggest: Keep the Security WG meeting on Tuesday, but move it to a 3-4 p.m. Eastern slot (confirm time with Alex M). Establish a weekly Federal Health Information Model (FHIM) WG meeting on Tuesdays in the 5-6 p.m. Eastern slot.

Notification to the Security List with the proposed time changes: Security WG to 3-4 p.m. Eastern / 12-1 p.m. Pacific and FHIM call to 5-6 p.m. Eastern / 2-3 p.m. Pacific // Suzanne to send meeting information out

Discussion on Signatures in FHIR

Problem Statement:

The digital signature gets broken after transport when the recipient takes the resources and places them in the new system. This happens because the reference information associated with the resource is location specific. As a result, when those same resources are sent to a third party, the original signature is broken and the resources would need to be signed again. This is true whether or not the second recipient actually changed any of the other information within the resources. This results in a lack of confidence that the information going to the third party is the same as the information that originated with the first party. Nor is there any way to know that the information ISN’T the same. This leads to a lack of trust in the information.

Proposed Solution:

1. Do not create a new message and then re-attach the resources: If resources need to be sent to multiple parties, only forward the original message with the resources still embedded.
2. Do not include reference information in the resource digital signatures: When a resource is signed, the digital signature hash is created from only the immutable information. Mutable information that is not critical to the integrity of the record, such as the resource information, is excluded. If there are multiple references, each reference has its own unique signature minus the immutable information.

In a case where there are multiple resources that go together, the base resource would have a second overarching digital signature associated with it, created by hashing the digital signatures from all of the resources included in the “bundle.” If this signature is broken, it means that either one of the resources changed, or that a resource is missing.

Upon transport, all of the resources are bundled together and an integrity digital signature is applied to the entire bundle, including the resource information. The only purpose of this signature is to ensure integrity during transport and it is understood that this signature will be broken when the resources are incorporated into the recipient’s system. A new integrity signature will be applied by the new sender anytime the resources are sent to another recipient.

Two types of Digital Signatures in FHIR

• Integrity Signatures
  • Applied to a bundle of resources
  • Includes immutable and mutable information
  • Only good for one transport session

• Document Signatures
  • Any digital signature on a resource needs to consist only of immutable information
    • Reference information is location-dependent and therefore is mutable

Both the overarching and resource digital signatures need to remain intact through multiple transportation events unless content within the resource is changed.

The integrity digital signature is only good for one transportation event and is used to ensure nothing was changed in transit.

Meeting Adjourned at 1736 PDT