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

July 18, 2017 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

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. (5 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

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

Retrieved from "https://wiki.hl7.org/w/index.php?title=July_18,_2017_Security_Conference_Call&oldid=142607"