July 18, 2017 Security Conference Call

Back to Security Main Page

Attendees

x	Member Name		x	Member Name		x	Member Name		x	Member Name
.	John MoehrkeSecurity Co-chair		x	Kathleen ConnorSecurity Co-chair		.	Alexander Mense Security Co-chair		.	Trish WilliamsSecurity Co-chair
x	Mike Davis		x	Suzanne Gonzales-Webb		x	David Staggs		x	Mohammed Jafari
x	Glen Marshall, SRS		x	Beth Pumo		.	Ioana Singureanu		.	Rob Horn
x	Diana Proud-Madruga		.	Serafina Versaggi		x	Joe Lamy		.	Galen Mulrooney
.	Duane DeCouteau		.	Chris Clark		.	Johnathan Coleman		.	Aaron Seib
.	Ken Salyards		.	Christopher D Brown TX		.	Gary Dickinson		x	Dave Silver
x	Rick Grow		.	William Kinsley		.	Paul Knapp		x	Mayada Abdulmannan
.	Kamalini Vaidya		.	Bill Kleinebecker		x	Christopher Shawn		.	Grahame Grieve
.	Oliver Lawless		.	Ken Rubin		.	David Tao		.	Nathan Botts

Back to Security Main Page

Agenda

1. (2 min) Roll Call, Agenda Approval
2. (4 min) Review and Approval of Security WG Call Minutes July 11, 2017
3. (15 min) Comments on Break the Glass White Paper Draft Review of WG input on draft. Approval for inclusion in Security WG library and reference from FHIR Security Wiki sought. Mike Davis (See Notes below)
4. (15 min) Discussion about the difference between FHIR Literal and Logical/Business Identifier wrt FHIR Consent and potential security implications for Audit, Provenance, Accounting of Disclosures etc. John, Paul Knapp, Kathleen (See Notes below)
5. (10 min) Begin discussion on how to include clearances for ABAC in FHIR OAuth profiles. Consideration of IHE IUA profile and HEART work in this area. John, Mike, others?
6. (5 min) Are new international HCS codes needed to support GDPR, PIPEDA, etc.?- Alex and Kathleen
7. (4 min) Review News and Reminders not previously discussed.
8. (1 min) FHIR Security call is cancelled.

News and Reminders

Next Call Agenda Item

Diagnosing and Treating Legal Ailments of the Electronic Health Record: Toward an Efficient and Trustworthy Process for Information Discovery and Release Potential for renewing EHR/Security work on Lifecycle Vocabulary - Reed Gelzer

RE Agenda Item #3 New Break Glass Paper

• Emergency Access presentation
• Updated HL7 Break glass Emergency Access paper
• HL7 Break glass Emergency Access paper

HL7 codes for override reasons: _ActConsentInformationAccessOverrideReason [abstract term] Description: To perform one or more operations on information to which the patient has not consented as deemed necessary by authorized entities for providing care in the best interest of the patient; providing immediately needed health care for an emergent condition; or for protecting public or third party safety. Usage Notes: Used to convey the reason that a provider or other entity may or has accessed personal healthcare information. Typically, this involves overriding the subject's consent directives.

• Concept Relationships:

   Specializes: _ActHealthInformationManagementReason
   Generalizes (derived): OVRER
   Generalizes (derived): OVRPJ
   Generalizes (derived): OVRPS
   Generalizes (derived): OVRTPS
   Generalizes (derived): OVRINCOMP

• OVRER (emergency treatment override)Description: To perform one or more operations on information to which the patient has not consented by authorized entities for treating a condition which poses an immediate threat to the patient's health and which requires immediate medical intervention. Usage Notes: The patient is unable to provide consent, but the provider determines they have an urgent healthcare related reason to access the record.
• OVRPJ (professional judgment override) Description: To perform one or more operations on information to which the patient declined to consent for providing health care.

Usage Notes: The patient, while able to give consent, has not. However the provider believes it is in the patient's interest to access the record without patient consent.

• OVRPS (public safety override)Description: To perform one or more operations on information to which the patient has not consented for public safety reasons. Usage Notes: The patient, while able to give consent, has not. However, the provider believes that access to masked patient information is justified because of concerns related to public safety.
• OVRTPS (third party safety override)Description: To perform one or more operations on information to which the patient has not consented for third party safety.Usage Notes: The patient, while able to give consent, has not. However, the provider believes that access to masked patient information is justified because of concerns related to the health and safety of one or more third parties.
• OVRINCOMP (incompency override)- New from July 2017 Harmonization

Description: To perform one or more operations on information to which the patient has not consented because deemed incompetent to provide consent. Maps to v2 CON-16 Subject Competence Indicator (ID) 01791 Definition: Identifies whether the subject was deemed competent to provide consent. Refer to table HL7 Table 0136 - Yes/No Indicator and CON-23 Non-Subject Consenter Reason User-defined Table 0502 - Non-Subject Consenter Reason code NC “Subject is not competent to consent”.

RE Agenda Item # 4 - Difference between FHIR Literal and Logical [aka "Business Identifiers"]

• Question for Security WG is what are the audit, accounting of disclosure, right to be forgotten, and provenance impacts of tracking both a literal and logical (Business) identifier?
• Context: This issue surfaced in the FHIR CBCC call about the Consent Resource use of Consent.source[x]
  • Definition: The source on which this consent statement is based. The source might be a scanned original paper form, or a reference to a consent that links back to such a source, a reference to a document repository (e.g. XDS) that stores the original consent document. Control 0..1
• Type Attachment|Identifier|Reference(Consent | DocumentReference | Contract | QuestionnaireResponse)

[x] Note See Choice of Data Types for further information about how to use [x] Comments: The source can be contained inline (Attachment), referenced directly (Consent), referenced in a consent repository (DocumentReference), or simply by an identifier (Identifier), e.g. a CDA document id.

• The issue has been an ongoing FHIR discussion about the Reference.identifier
• Definition: An identifier for the other resource. This is used when there is no way to reference the other resource directly, either because the entity is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference.
• Note This is a business identifer, not a resource identifier discussion)
• Comments: When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier), but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it. See CapabilityStatement.rest.resource.referencePolicy.
• When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference.
• Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it.
• 2.28.3.2 Resource Identity Each resource has an "id" element which contains the logical identity of the resource assigned by the server responsible for storing it. Resources always have a known identity except for the special case when a new resource is being sent to a server to assign an identity (create interaction). The logical identity is unique within the space of all resources of the same type on the same server. Once assigned, the identity is never changed.
• Note that if the resource is copied to another server, the copy might not be able to retain the same logical identity.
• The unique identifier of a resource instance is an absolute URI constructed from the server base address at which the instance is found, the resource type and the Logical ID, such as http://test.fhir.org/rest/Patient/123 (where 123 is the Logical Id). When the literal identity is an HTTP address, this address can generally be used to retrieve or manipulate the resource. Note that implementations SHOULD NOT assume that the identity of a resource is always resolvable to a literal server - it may be temporarily unavailable, or not available by policy (e.g. firewalls) or in some cases, it may not actually exist (e.g. use of resource outside a RESTful environment).
• Resources reference each other by their identity. These references are allowed to be absolute or relative (see Resource References for further discussion). Copying or moving resources from one server to another means that resources acquire a new identity. For further details, see Managing Resource Identity.
• 2.28.3.2.1 "Business" Identifiers In addition to the logical id and literal identity discussed above, many resources contain an element named "identifier", which, if populated, contains a different kind of identifier. As resources are copied from server to server, their literal identity will change, and their logical id may change.
• However, all copies of the resource refer to the same underlying concept, and this concept may also be represented in other formats (variously, HL7 v2, CDA, XDS, and many more). Each representation carries the same identifier that identifies it consistently across all contexts of use. This is known as the business identifier, and is found in the identifier element. In a few resources, there is a url element that serves a similar purpose, but is constrained to be a literal URL for implementation reasons.
• All resources that have an identifier element support searching by the identifier, so that records can be located by that method. So if an HL7 v2 message that has the following OBR: OBR|1|845439^GHH OE|1045813^GHH LAB|1554-5^GLUCOSE^LN|||200202150730|...Then the DiagnosticReport it represents can be located using the following query: GET [base]/DiagnosticReport?identifier=1045813
• If a FHIR server is a stable server that is the canonical master source for the definition of a concept, the business identifier for all systems may be the same as the literal identity of the resource on the master server.

RE Agenda Item #6 - Need for additional International HCS codes

Canadian Privacy Law

• Personal Information Protection and Electronic Documents Act (PIPEDA)
• The Global Reach of Canadian Privacy Law: Federal Court Issues Landmark Ruling in Globe24h
• Example of International Use Case for additional HCS codes: Rene Spronk in his "GDRP Impact on Healthcare Data Interoperability" suggested: A label on an item of data that states "data subject to the Data Portability rights" would be useful for any 'downstream' processors of that data, for that specific data item would also be subject to the Data Portability right within a receiving application.

Minutes

• Chaired by Kathleen
• Agenda Approval
• Approved Security WG Call Minutes for July 11, 2017 ( Alex, Mike)
• Discussion about the difference between FHIR Literal and Logical/Business Identifier wrt FHIR Consent and potential security implications for Audit, Provenance, Accounting of Disclosures etc. John, Paul Knapp, Kathleen (See Notes below) Presented by Paul
  • In circumstance when recourse has no ID it can be referred to as identifier
  • Identifier element is in the re fence data type
  • If for example you do not have ID of Practitioner, can use other Identifier (eg: Drivers license Number)
  • Challenge/Issue: What identifier are we identifying? While having the identifier, one may not have the recourse. Eg: While having the DV license number of practitioner, one may not be able to identify if the DV license belongs to a practitioner or another type of recourse.
  • Mitigation (Reference Identifier): To deal with the challenge with no identifier to recourse, a sibling defined element is added to mitigate.
  • Business identifier in a reference is identifiable. Anything that can be identified can be used in FHIR.
  • Signature: When signing over something you use a business identifier; However, when using the resource ID it changes reference ID. Therefore, identifier is contained within source ID.
  • Eg: (referencing documents) If someone has a Consent Directive it can be used as an reference identifier. However, If a CDA document would not be a identifier since it is a document, to mitigate this issue a source identifier cam instead be used to identify the CDA document.

• Comments on Break the Glass White Paper Draft Review of WG input on draft. Approval for inclusion in Security WG library and reference from FHIR Security Wiki sought. Mike Davis (See Notes below) -

- Mike:

• • John and Mike Davis will discuss the purpose of use of Declaring an emergency ( in a Emergency Room)
  • Break the Glass should only be used in emergency, and not just to obtain patient information
  • The purpose to Break the Glass should only be in an emergency (eg: emergency room)
  • Emergency Room purpose of use of emergency would be declared
  • Access control decision can be used for Break Glass decision for the requesting clinician who must provide a code (reason/purpose) as to why they need to break glass (declaring the emergency) if they do not typically speak to the other organization to obtain information for their patient to over ride the restriction

• Begin discussion on how to include clearances for ABAC in FHIR OAuth profiles. Consideration of IHE IUA profile and HEART work in this area. John, Mike, others?

- Mike:

• • Looking at the legality of disclosure
  • Some concerns over health care legal record as there are several definitions for legal record
  • The paper helps explain the vocab and functional models in defining Health Care legal Record
• Are new international HCS codes needed to support GDPR, PIPEDA, etc.?- Alex and Kathleen
  • The working group for Harmonizing Security and EHR Vocab maybe re-established
  • Comment (Sarafina): Legal record has yet to transition in Electronic record, and continue to remain as paper record
• Are new international HCS codes needed to support GDPR, PIPEDA, etc
  • Alex will need more time to review
• Review News and Reminders not previously discussed.
  • Included in Agenda
• FHIR Security call is cancelled.
• Call adjourned