HL7 FHIR Security 2016-4-19
Contents
Call Logistics
Weekly: Tuesday at 05:00 EST (2 PM PST)
Conference Audio: 770-657-9270,' Access: 845692
Join online meeting: https://meet.RTC.VA.GOV/suzanne.gonzales-webb/67LLFDYV
If you are having difficulty joining, please try:
https://global.gotomeeting.com/join/520841173
Please be aware that teleconference meetings are recorded to assist with creating the meeting minutes
Back to HL7 FHIR security topics
Attendees
| Member Name | Member Name | Member Name | ||||||
|---|---|---|---|---|---|---|---|---|
| x | John Moehrke Security Co-Chair | x | Kathleen Connor Security Co-Chair | x | Suzanne Gonzales-Webb CBCC Co-Chair | |||
| . | Gary Dickinson EHR Co-Chair | . | Johnathan ColemanCBCC Co-Chair | . | Mike Davis | |||
| . | Reed Gelzer RM-ES Lead | x | Glen Marshal | . | Galen Mulrooney | |||
| . | Dave Silver | x | Rob Horn | x | Judy Fincher | |||
| x | Diana Proud-Madruga | . | Beth Pumo | Oliver Lawless | ||||
| . | Bob Dieterle | . | [mailto:] | [mailto:] |
Agenda
- Roll; approval of agenda and the April 12, 2016 minutes
- Test ability of AuditEvent and Provenance to track security label changes.
- Review CP 9840 Provenance.entity.provenance and Provenance.entity.agent cardinality - see discussion.
- Discuss updates to CP 9812 Add a note to AuditEvent explaining PurposeOfEvent and PurposeOfUse
Parking Lot Items
- Review Security CP 9407 Align AuditEvent and Provenance action/activity element definition Continue work on activity definitions in spreadsheet
- Review John's interaction diagrams for Provenance and AuditEvent showing how these may be generated by both the user system and the recipient server.
- Review Provenance/AuditEvent front matter changes.
Discussion CP 9840
Revised CP: [1] Add optional [0..*] Provenance.entity.provenance with datatype Reference(Provenance) defined as "Relevant provenance about a predecessor entity, which reflects the activity of any provenance.entity.agent and expresses the agent's responsibility for the entity. [2] Current state: Provenance.agent is now 0..*. Input Entity to Provenance Resource - Provenance.entity.agent is now 0..1. Issue: Any predecessor entity to the target of the Provenance Resource may have 0..* Provenance.entity.agent . Recommendation is to correct what seems to be a modeling error by increasing Provenance.entity.agent cardinality from 0..1 to 0..*. Effect is that all agents whose activities impacted any predecessor entity can be conveyed.
Background from April 12 call
- RE: Provenance.entity.provenance: Kathleen recommended adding an optional reference to an input entity's associated Provenance Resources based on two use cases based on the principle that the Provenance Resource author should be able to choose which if any Provenance.entity Provenance Resource it wishes/is considered more trustworthy:
Use Case 1
[1] The target of Provenance Resource C is the result of an agent's activity on a predecessor entity, e.g., a Family History Resource generated by a provider and a patient.
- Both the Patient and the Provider record separate Provenance Resources about the Family History Resource they collaboratively generated.
- I.e., same entity version associated with two different Provenance Resources [Patient Provenance Resource A and Provider Provenance Resource B]
[2] Provenance Resource "C" author records its aggregation activity on the Family History Resource entity, which resulted in the Provenance Resource C's target Family History List Resource.
- Provenance Resource C author only wants to track the provider authored Provenance Resource B for the predecessor Family History Resource [predecessor entity] because the author has more confidence in the integrity, authenticity, and reliability of this provenance record for purposes of tracking in the provider's EHR [a policy decision].
NOTE - this use case requires that the cardinality of a Provenance.entity.agent be 0..* rather than 0..1. The current cardinality is incorrect because the cardinality of a Provenance.agent is 1..*, so it is currently the case that more than one agent may be involved in the generation or changes to the Provenance Resource Target. Since the Provenance.entity may also be a Provenance Resource Target, then more than one agent may have been involved.
Use Case 2
[1] The target of Provenance Resource D is the result of an agent's activity on a predecessor entity, e.g., a Family History Resource generated by a provider. In this case, the agent has declassified the input Family History Resource [predecessor entity] from Confidentiality Label = Restricted to Confidentiality Label = Unrestricted.
- Because changes to FHIR Security Labels do not require a change to the version, locating the Provenance Resource for Family History Resource [predecessor entity] cannot be done based on a search on the Provenance.entity.reference, which would include the entity's version id [not sure it matters what identifier type is used for version control here].
- In order for the Target Resource Custodian to track changes made to its Security Label, the Custodian will need to have a Provenance Resource that records all classification changes to that Target version's predecessor Security Labels tags. This can only be done, it seems, with a Provenance Resource that supports Provenance.entity.provenance element with a reference to the predecessor entity's Provenance Resource.
Three Solutions Explored: [1] Search on entity version will return all entity Provenance Resources, and the Target Provenance Resource author may choose which if any entity predecessor Provenance Resources to reference. [2] A bag of entities could include all entity predecessor Provenance Resources and the Recipient can open all entities to decide which Provenance Resource entity to match with any referenced entity. [3] Each entity has an optional reference to that entity's Provenance Resource deemed trustworthy by the Target Provenance Resource author. Kathleen strongly recommends option 3. John preferred solution [2]. Kathleen will submit CP for option 3 with this documentation to continue the discussion.
Minutes
- John Chaired. Agenda approved: Suzanne moved; Diana seconded [6-0-0] and Minutes approved as amended [use cases removed for discussion on this call] Kathleen moved; Glen seconded [6-0-0].
- RE: Test ability of AuditEvent and Provenance to track security label changes. John discussed background for this topic, which began in the Security WG call 4/19. Issue is coming up with solutions to tracking changes of security labels on Resources when there's no versionID change. Idea was to test how current AuditEvent and Provenance Resources can be used to do so if policy requires tracking such changes.
- AuditEvent Security Label tracking solution proposed by John: If AuditEvent T1 records that AuditEvent.entity with versionID 1.0 is CREATED [optional AuditEvent.action], and if AuditEvent T2 records that AuditEvent.entity with versionID 1.0 is UPDATED, then a system could flag this as a reason to investigate e.g., the server's database journal, to discover what changes were made to AuditEvent.entity metadata [or other elements, where policy deems that some changes to those element values does not trigger a versionID change - e.g., if the value were entered in error or otherwise transformed}.
- Kathleen questioned whether this would be burdensome especially were the sender of a labeled Resource does not control one or more of the servers in which the sender had sent that Resource.
- Discussion ensued with some participants thinking that changes in security labels seems to be a "fringe" case.
- Kathleen asked if the extensible AuditEvent.type or AuditEvent.subtype DICOM value sets could be augmented with a code such as "relabeled". Those involved with the development of these DICOM value sets cited the difficulty in reaching consensus for such a change in the standard code systems from which the AuditEvent.type/subtype were drawn.
- Kathleen suggested putting John's solution, which both Rob and Glen agreed with, into a Security Risk and Privacy Impact note as suggested by Lloyd. John, Rob, and Glen indicated that they would not support a CP for such a note since this could be interpreted as limiting implementer design choices [or some reason along these lines.] No decision was made about the success of the test.
- John moved the discussion to CP 9840 on Provenance.entity.provenance and provenance.entity.agent cardinality.
- RE Provenance.entity.agent cardinality: Kathleen wanted to know why the provenance.entity.agent is [0..1] while the Provenance.agent is [1..]. John asserted that the current definition of provenance.entity.agent is incorrect based on discussions with Grahame, and that the correct definition provides rationale for limiting entity.agent to [0..1]. This CP 9840 issue remains unresolved.
- RE Provenance.entity.provenance: CP 9840 requests a new optional element that would point to this entity's provenance. John's solution is to include both the entity and its Provenance if needed. Kathleen asked how these would remain associated if there are multiple entities with multiple Provenances, and John replied that each entity's Provenance would indicate which entity it is associated with. Kathleen indicated that this solution would be okay with her, and she is willing to accept this partial resolution to this CP.
