Submitting WG/Project/Implementer Group

Security WG

Agenda for Friday 5/15: Plan is to reconvene at 10 ET to walk through progress and record for our track findings.

See Report Out: Security Labeling Track Connectathon 24 for roster and notes.

Justification and Objectives

Track will exercise the FHIR DS4P IG being balloted in May 2020, which is a deliverable for the FHIR Data Segmentation for Privacy (DS4P) Implementation Guide Project

Zulip Chat

https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/May.202020.20.20Virtual.20Connectathon.20.20Security.20Labeling.20Track

Technical Requirements

(Please check the Github repository for more details and test scripts.)

This track is aimed at testing minimal support for Security Labeling (based on the FHIR DS4P ballot) in a FHIR server. The participants will provide a FHIR server to be tested for meeting the minimum requirements. The following are the minimum technical requirements that will be tested in this track:

  • The FHIR Server must provide a CapabilityStatement resource at the /metadata endpoint with an implementationGuide attribute that includes the following:
       http://hl7.org/fhir/uv/security-label-ds4p/ImplementationGuide/hl7.fhir.uv.security-label-ds4p

  • The FHIR Server is capable of accepting labeled resources including labels bearing the extensions defined by the DS4P IG by ensuring the labels (including the extensions) are persisted.

  • The FHIR Server enforces the 1..1 cardinality constraint for confidentiality labels by either:

    • Rejecting a labeled resource that does not bear a confidentiality label, or
    • Labeling the resource after accepting it and assigning a confidentiality label to it.

  • The FHIR Server is capable of adding high-watermark confidentiality label to a response bundle based on the contents of the bundle.

  • (bonus) Supporting high-watermark on the response bundle for other types security labels.

Report Out: Security Labeling Track Connectathon 24

Video GMT20200515-190441_Security-L_2560x1440.mp4

Purpose of the Track

What’s the purpose of hosting this Connectathon track? What do you hope to achieve?

The purpose of this track is to test:

  • Sender and Receiver ability to create Security Labeling CapabilityStatements describing their capacity to assign policy specific security labels in the meta of a Bundle and a Resource. 
    • Policy specific security labels will be provided to participants for CUI, 42 CFR Part 2, Title 38 Section 7332, and Michigan MDHHS-5515 consent
    • CapabilityStatement validation service will provide programmatic verification of CapabilityStatements?
  • Sender and Receiver ability to make their Security Labeling CapabilityStatements discoverable
  • Sender and Receiver ability to retrieve Security Labeling CapabilityStatements for perspective trading partners
  • Receiver requests to register with Sender as a Client.
  • Sender compares Receiver's Security Labeling CapabilityStatement with its own, and determines that Receiver has the capability to consume and enforce the Sender's Security Label for a set of Sender's labeled Resources.  This is the "Happy Path".
  • Receiver requests labeled Resources, which match the Security Label capabilities in its Client registration.
  • Bonus Point: Sender determines whether there are any additional authorization requirements, e.g., a consent directive authorizing the Sender to disclose the requested information to the Receiver.
  • Sender determines that Receiver is authorized to receive the labeled Resources.
  • Receiver demonstrates the ability to consume Security Labels with extensions on sample Bundles and Resources.
  • Bonus Point: Receiver enforces Security Labels.
  • Bonus Point: Receiver ability to consume security labels with extensions to create a List of labeled Resources.

This track will use R4/R5 version of FHIR

Clinical input requested (if any)

Does your track have a need for input from the clinical community? If so, what are the needs?

At this time, we are  anticipating input from the clinical community from participants, including WebShield and VA.  We have engaged the clinical community in previous security labeling in previous Connectathons (Bulk Data and Analytics Track May 2019) and the HIMSS 2019 Consumer Centered Care Plan Interoperability Showcase.  We anticipate further engagement as we get closer to the May 202005 Virtual Connectathon. 

We will also be reaching out to the Patient Community for participation via the HL7 Patient Empowerment WG

Related tracks

(used to help guide seating arrangements and possibly drive track consolidation)

None known to date.

Proposed Track Lead

Name, email. Track leads must be registered users on http://chat.fhir.org

Mohammad Jafari mohammad.jafari@bookzurman.com

Kathleen Connor kathleen_connor@comcast.net

Expected participants

Who do you expect to be present? How many do you expect to attend?

VA - 2

WebShield - 2

Other implementers signed up for FHIR Data Segmentation for Privacy (DS4P) Implementation Guide PSS - such as Perspecta, PRA, eHealth Exchange and Sequoia, but have not yet confirmed their participation.

Track Orientation

A webinar will be hosted on date at time to share further participation information about this track.

Webinar will be scheduled in early May.

System Roles

Describe each type of system that could participate in the track

Please include information here regarding how much advance preparation will be required if creating a client and/or server.

Sender/Receiver servers generate Security Label CapabilityStatements.

  • Advanced preparation: TBD

CapabilityStatement Verification testing service.

  • Advanced preparation: TBD

Server capable of labeling prepopulated Bundles and  Resources conformant with the sender's CapabilityStatement(s).

  • Advanced preparation: TBD

Client capable of consuming labeled Bundle and Resources, persisting the labels, and relabeling when disclosing stored Resources in accordance with the receiver's CapabilityStatement.

  • Advanced preparation: TBD

Role 1 Name

Scenarios

Describe the different scenarios participating systems can engage in during the conenctathon. Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.

Scenario Step 1 Sender/Receiver generation of Security Label CapabilityStatements with FHIR DS4P extensions

Scenario Step 2 Sender capability to provide labeled Bundles and Resources with FHIR DS4P extensions conformant with the sender's CapabilityStatement(s).

  • Action: Server labels prepopulated Bundles and Resources in accordance with Sender's CapabilityStatements
  • Precondition: Sender Security Labeling Capability Statement
  • Success Criteria: Verification of conformant security labeling
  • Bonus point: None

Scenario Step 3 Receiver capability to consume labeled Bundle and Resources,

persisting the Resource labels, and relabeling when disclosing stored Resources in accordance with the receiver's CapabilityStatement.

  • Action: Receiver consumes labeled Bundle and Resources with FHIR DS4P extensions
  • Precondition: Sender Security Labeling Capability Statement
  • Success Criteria: Verification of consumed security labels with FHIR DS4P extension
  • Bonus point:
    • Receiver demonstrates ability to consume security labels with extensions for a List of labeled Resources
    • Receiver demonstrates ability to demonstrate access control capabilities based on security labels

Scenario Step 4: Receiver capability to persist Resource labels with FHIR DS4P extensions

  • Action: Receiver persists Resource labels with FHIR DS4P extensions
  • Precondition: Receiver Security Labeling Capability Statement indicating ability to persists Resource labels with FHIR DS4P extensions
  • Success Criteria: Verification of persisted Resource labels with FHIR DS4P extensions
  • Bonus point: Receiver demonstrates ability to persist security labels with extensions for a List of labeled Resources

Scenario Step 5: Receiver capability to relabel stored Resources with FHIR DS4P extension  within Bundle with High Water Mark security label when further disclosing in accordance with Receiver CapabilityStatement

  • Action: When disclosing Resources, receiver relabels received Resources in accordance to receiver Security Labeling  CapabilityStatement, which may mirror or diverge from sender security labels per applicable policy
  • Precondition: Receiver Security Labeling Capability Statement indicating how the receiver will label outbound Resources
  • Success Criteria: Verification that receiver disclosed Resources are labeled in accordance with the receiver's Security Labeling CapabilityStatement
  • Bonus point: Receiver redisclosed labeled Resources in a List

TestScript(s)

Indicate any test scripts that will be used to help verify system behavior

TBD - Will reach out to test script services or host ourselves.

Security and Privacy Considerations

Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate

Precondition that authentication and authorization policies have been met, as these are not the focus of this track, but noted as significant requirements.

  • No labels