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

HL7 FHIR Security 2017-01-31

From HL7Wiki
Jump to navigation Jump to search

Call Logistics

Weekly: Tuesday at 05:00 EST (2 PM PST) 

Conference Audio: 770-657-9270,' Access: 845692
Join online meeting:  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 . Rob Horn . Judy Fincher
. Diana Proud-Madruga . Beth Pumo . Oliver Lawless
. Bob Dieterle . Mario Hyland . Joe Lamy
. Rick Grow . [mailto: Richard Etterma] . [mailto: Wayne Kubic]

Agenda

  • Roll;
  • approval of agenda
  • approval of the HL7 FHIR Security 2017-01-24 Minutes
  • All security open http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677&tracker_query_id=4967
  • September Ballot items must address by February 5, 2017 -- see http://wiki.hl7.org/index.php?title=FHIR_Ballot_Prep
    •  ???None of them are structural, so we could work on them during QA phase??? (Prior to Feb 26)
  • I have submitted an exception to W5 ordering rule for AuditEvent and possibly Provenance.
  • Would like following vocabulary items approved. Might be refined over next few weeks.
    • See block below
  • Defer other action items. We can continue to work on them, but agree to formally defer them for post STU3
  • Kathleen
    • 11071 Improve security label guidance - 2016-09 core #90 ()
    • 10343 Three additional Signature.type codes ()
  • John
    • 9167 AuditEvent needs to make more obvious how to record a break-glass event ()
    • 10579 New Security and Privacy "Module" page needs content ()
    • 10580 How should test data be identified? ()
    • 10581 something should be said about de-identification ()
  • New business?

FHIR Security block vote

Approve all Persuasive with Mod

    • 9042 Add RBAC as value set for AuditEvent.participant.role ()
    • 9043 Add ABAC as alternative value set for AuditEvent.participant.role ()
    • 9052 Add SNOMED Stuctural Roles as value set for AuditEvent.participant.role ()
    • 10382 Provenance activity codes are insufficient/inappropriate ()
    • 6303 Add Record Lifecycle Events to AuditEventObjectLifecycle Set ()

Outline for Security & Privacy Module

Use this CR or create a set of new CR as needed.

    • 10579 New Security and Privacy "Module" page needs content ()

http://build.fhir.org/secpriv-module.html

Use of Security Labels

From email discussion between Kathleen and John -- Summary by John

The FHIR community is unclear on how how to use the security-labels. When is it appropriate to use each type. Where is it appropriate to use each type? Specifically what are the risks they need to consider.

I agree with this.. This is hardly understood by the core people in the security wg... I am however concerned at declaring any specific policy -- such as the sensitivity codes shall never be used.

Seems we could create a few scenarios that outline proper use, and include description of the security considerations that went into that use.

1) Use of HCS tags within a highly-trusted environment (All inside my security boundary, within my own trust environment. my own trust framework). -- This is minimally use between the Access Control services and the REST server, including use of an SLS to enable access control decisions. I could see this highly-trusted environment being bigger than this, but think that most people need to understand that exposing the full HCS security-labels does present a risk.

2) Exposure of Resources to a Moderate-Trusted environment (They are outside my security boundary, but we have a trust framework that assures me they can protect sensitive information and follow obligations) -- the HIE environment. As you say, where _confidentiality and obligations. This is where we can talk to Bundle being a high-water, of only the _confidentiality codes; and where obligations would go.

2.1 ) The placement of obligations seems important enough that we should have a specific scenario just for that, so as to highlight it.

3 ) Having a USA specific example using 42 would be useful too. This is a rollup of all the things we want to say. I think it is okay to be USA centric, but when we do this we should explain the situation in terms that are not overly USA centric.

4) Use of HCS tags when in a low-trusted environment (I trust they will not expose what I give them, but they have limited ability to protect highly sensitive information or to enforce obligations) -- Where you are going to block access to anything sensitive. Showing that blocking access might be silent, or might be explicit (we have outlined this in the http error codes for security). Both are useful policy choices.

4.1 ) do we include your concern around returning obligations only when you KNOW that the recipient will enforce them? It needs to be said somewhere. Here might be good place.

5) Always good to remind people that they are not to expose information when the trust is not there.

Not sure if it is proper to use highly-trusted, moderate-trusted, and low-trusted -- I think the trust framework is key

is this what you are proposing? Did I miss a concept? I think this would be a good discussion today.


Access Control

  • Outline for a FAQ improvement on the module page
  • Access Control
    • Access Control diagram from Mike (Inputs – Decision – Enforcement – Outputs)
    • Using OAuth
      • Identity
        • Leverage OpenID Connect
        • Federate (cross-reference, mapping) to local identity descritions
          • Informally, or Formally
      • Roles
        • Using Standard roles from HL7
        • Using local codes
        • Clearance
      • Scopes
        • Using SMART scopes
          • Basic starter set
          • Supports Organizational use-cases with simple consent
          • Doesn’t support fine-grain
          • Doesn’t support complex consent
        • Using HEART – UMA
      • Using Cascading Authorization Servers
        • Bridging SMART and UMA and organizational requirements
    • Using Security labels
      • HCS conformance
        • MUST have a _confidentiality value (1..1)
        • Use of persistence label
        • Bundle use of security_tags – high-water
        • Comprehensive security_tags on each resource communicated to a trusted peer
        • Using security lables from a consent directive (privacy policy) on goverened resources
        • Using Clearance with security labels
    • Bring in stuff from the Privacy Consent Implementation Guide (Consent IG)
      • TODO
    • Should we create a new page, parellel with security.html -- privacy.html
      • Privacy Principles
      • Consent as a way to control Collection/Use/Disclosure
      • ISO four models (In, Out, In with exceptions, Out with exceptions)
    • Trust Framework
      • impact on the Conformance resource published by partners.
      • Establishing trust Contracts between trading partners

Minutes

  • John Chaired
  • Agenda approved - Glen Marshal/Suzanne Gonzales-Webb: 3-0-0
  • Minutes approved - Glen Marshal/Suzanne Gonzales-Webb: 3-0-0
  • Vote to approve block vote as Persuasive with Mod, with corrections as needed over QA period - Kathleen Connor/Glen Marshal: 3-0-0
    • 9042 Add RBAC as value set for AuditEvent.participant.role ()
    • 9043 Add ABAC as alternative value set for AuditEvent.participant.role ()
    • 9052 Add SNOMED Stuctural Roles as value set for AuditEvent.participant.role ()
    • 10382 Provenance activity codes are insufficient/inappropriate ()
    • 6303 Add Record Lifecycle Events to AuditEventObjectLifecycle Set ()
    • 12677 AuditEvent object-type vocabulary needs FHIR Resource types (John Moehrke) Persuasive
  • Vote to approve adding Identifier to Provenance.entity - Kathleen Connor/Glen Marshal: 3-0-0
  • Vote to defer reminder - Glen Marshal/Suzanne Gonzales-Webb: 3-0-0
    • 9167 AuditEvent needs to make more obvious how to record a break-glass event (John Moehrke) Considered for Future Use
    • 10343 Three additional Signature.type codes (Kathleen Connor) Considered for Future Use
    • 10579 New Security and Privacy "Module" page needs content (John Moehrke) Considered for Future Use
    • 10580 How should test data be identified? (John Moehrke) Considered for Future Use
    • 10581 something should be said about de-identification (John Moehrke) Considered for Future Use
    • 11071 Improve security label guidance - 2016-09 core #90 (Kathleen Connor) Considered for Future Use
    • 12462 Security/Privacy Module page should explain W5 realty that provenance elements in other resources vs use of Provenance as a resource (John Moehrke) Considered for Future Use
    • 12463 explain relationship between Provenance and AuditEvent. (John Moehrke) Considered for Future Use
    • 12501 Provenance.reason and Provenance.activity should be CodeableConcept (Grahame Grieve) None
  • note one more was auto deferred
    • 12502 Provenance.agent.relatedAgentType is nonsensical (Grahame Grieve) None
  • need to address FMM in future meeting.
  • adjourned
Retrieved from "https://wiki.hl7.org/w/index.php?title=HL7_FHIR_Security_2017-01-31&oldid=133042"