Page tree
Skip to end of metadata
Go to start of metadata

Track overview

Short Description

Consent Management, Decision and Enforcement Services. 

Long Description

This track will focus on using FHIR consent in a number of key use cases including but not limited the use of a Consent Decision Service for use case around privacy, consent for treatment, and participation is research. In addition aspects of Consent Enforcement, Sharing, and discovery will be explored.

This track leverages the May 2020 Security Labeling Track which addressed FHIR® Data Segmentation for Privacy Implementation Guide(DS4P IG) requirements.

Type

 Issue Exploration, Testing of Implementation Guide, Resource usage testing,  Integration Testing and Related Standards

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group

Services Oriented Architecture (SOA)

Proposed Track Lead

Duane DeCouteau ddecouteau@saperi.io 

Related tracks

This track leverages the May 2020 Security Labeling Track which addressed FHIR® Data Segmentation for Privacy Implementation Guide(DS4P IG) requirement

FHIR Version

  • FHIR R4

Specification(s) this track uses

Artifacts of focus

Consent Resource

Clinical input requested (if any)

none requested

Patient input requested (if any)

None requested

Expected participants

San Diego Health Connect
Telstra Health

Zulip stream

Track Orientation

Kickoff

08/12/2020 at 19:00 EDT / 16:00 PDT 

Join Zoom Meeting
https://zoom.us/j/95408991668

Meeting ID: 954 0899 1668
One tap mobile
+16465588656,,95408991668# US (New York)
+16699009128,,95408991668# US (San Jose)

Meeting ID: 954 0899 1668
Find your local number: https://zoom.us/u/abEDZIPyVo

Follow up meetings

08/19/2020 at 19:00 EDT / 16:00 PDT 

08/26/2020 at 19:00 EDT / 16:00 PDT 

09/02/2020 at 19:00 EDT / 16:00 PDT 

Agenda

Please login to your Whova account for additional information on this track. Per our last planning meeting the track hours will be geared for our Australian colleagues.

Day 1 September 9th

Day 2 - September 10th

Day 3 - September 11th

  • Friday Wrap-ups 9:00AM-7:00PM ET

Track details

Requirements & System Roles

Participants are expected to provide one or many of the following, FHIR Consent Clients, Consent Decisioning Service, Consent Enforcement Service, or Security Labeling Services that meets the requirements of the track. Update the following Google Sheet with information about yourself and the implementation you will be demonstrating @ https://docs.google.com/spreadsheets/d/1q4HL1Jt3GXHTnoWRekKDsBdoicnMbBUom7J1B7WSTbI/edit?usp=sharing.

Detailed track instructions, sample code, and sample Messages for developer community can be found on Github at https://github.com/sdhealthconnect/leap-demos/tree/master/hl7-fhir-connectathon-sept2020-consent-track.

FHIR® Consent Client Requirements

  • Interface to Register and Manage Patient Account and Patient resource
  • Manages organization or practioner resources
  • Creates, updates, or revokes FHIR® R4 Consent resources
  • (Bonus) Allows for multiple Purpose of Uses, Policies, and Obligations

Update the track Google Sheet with information about your Consent Client and its capabilities Consent Client Info

Consent Decision Service (CDS)

  • Returns authorization decision and any obligations as a result of evaluating the patient Consent resource.

Update the track Google Sheet with information about your Consent Decision Service and its capabilities Consent Decision Server

Consent Enforcement Service (CES)

  • Forms authorization request and communicates with CDS
  • Consumes decision from CDS
  • Acts on Obligations if any
  • Orchestrates interactions with external services such as Security Lableling

Update the track Google Sheet with information about your Consent Enforcement Service and its capabilities Consent Enforcement Service

Security Labeling Services (SLS)

As described in May 2020 Connectathon, SLS will enforce 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.

  • 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 (other than confidentiality).

Update the track Google Sheet with information about your Security Labeling Service and it's capabilities Security Labeling Service

Implementation Examples

Consent Decision Service - https://github.com/sdhealthconnect/leap-cds

Consent Decision Service Clients - https://github.com/sdhealthconnect/leap-ces-java-clients

Consent Enforcement V2 Messaging - https://github.com/sdhealthconnect/leap-demos/tree/master/leap-ces-v2-orchestration

Consent Enforcement eHealth Exchange (Generic) - https://github.com/sdhealthconnect/leap-demos/tree/master/leap-ces-ccda-orchestration

Consent Enforcement eHealth Exchange (Embedded) - https://github.com/sdhealthconnect/leap-demos/tree/master/leap-ces-ccda-orchestration-embedded

Consent Enforcement FHIR Based Exchange (Proxy) - https://github.com/sdhealthconnect/leap-fhir-ces

Consent Enforcement FHIR Based Exchange (Embedded) - https://github.com/sdhealthconnect/leap-hapi-fhir-ces-embedded

Additional information can be found at https://sdhealthconnect.github.io/leap/

Available Test Servers and Demonstrations

Consent Decision Services - https://sdhc-leap.appspot.com

HAPI-FHIR Consent Repository - http://34.94.253.50:8080/hapi-fhir-jpaserver/fhir

eHealth Exchange Server (Embedded) - http://104.196.250.115:8080

eHealth Exchange Services - https://sdhc-leap-ccda-axz2tb4tma-uc.a.run.app

Directed Exchange Services - https://sdhc-leap-ccda-axz2tb4tma-uc.a.run.app

V2 Exchange Services - https://sdhc-leap-v2-56zrsoidxa-uc.a.run.app

FHIR Exchange (Embedded) - http://35.235.74.117:8080/hapi-fhir-jpaserver/fhir

FHIR Exchange (Proxy) - https://leap-fhir-ces.appspot.com

Additional Resources

Connectathon examples are available by cloning the LEAP Demos repository

> git clone https://github.com/sdhealthconnect/leap-demos.git
> cd leap-demos/hl7-fhir-connectathon-sept2020-consent-track/examples

Scenarios

Privacy Consent Scenarios

Assuming a Purpose of Use of "TREAT";

a) Patient "A" wishes to opt-in to SDHealthConnect.org HIE with No restrictions

b) Patient "B" wishes to opt-in to SDHealthConnect.org HIE but wishes to restrict access to their sensitive information.

c) Patient "C" wishes to opt-out of SDHealthConnect.org HIE.

d) Patient "D" wishes to grant access to "Dr. Bob" at Kaiser Permanente with no restrictions.

e) Patient "E" wishes to grant access to "Dr. Bob" at Kaiser Permanente by with to restrict access to their sensitive information.

f) Patient "F" wishes to grant access to "Dr. Bob" at Kaiser Permanente with no restrictions for only one day.

g) Patient "G" wishes to deny access to "Dr. Bob" at Kaiser Permanente.

Objectives:

Consent Client: Demonstrate the ability to create, update, retrieve, and revoke the FHIR consent.

Consent Decision Service: Demonstrate the ability to return authorization and (if any) obligations from above FHIR consents.

Consent Enforcement Service: Demonstrate the ability to enforce the authorization decision and any obligations, such as redaction of sensitive PHI.

Bonus - Demonstrate enforcement when exchange of patients healthcare information is based on V2, eHx, or Direct

Bonus - Demonstrate how Organization Policy may sometimes override constraints levied with the patient's consent.

Bonus - Demonstrate Emergency Access when Purpose of Use is ETREAT

Informed Consent Scenario

Assumes a Purpose of Use of "TREAT"

a) Patient "H" is having minor surgery on his left shoulder. "Dr. Bob" will be the attending orthopedic surgeon. "Dr. Bob" reviews with Patient "H" the planned procedure, any risks, and other expectations such as recovery.

Objective:

Consent Client: Demonstrate the creation and retrieval of FHIR resource for Informed Consent capturing both Patient "H" and "Dr. Bob's" signature.

Consent Decision Service: Demonstrate CDS interactions (authorzation decision) as part of pre-surgical checklist flow.

Research Consent Scenario

Assumes a Purpose of Use of "HRESCH"

a) Patient "I" as has recently recovered from severe case of COVID-19 requiring hospitalization. "Dr. Dave" at Kaiser Permanente suggests that she participate in RESEARCH project at University of Arizona to determine long-term effects of this virus. She agrees.

Objectives:

Consent Client: Demonstrate ability to create, update, retrieve, and revoke when information exchange is for research purposes.

Consent Decision Service: Demonstrate the ability to return authorization and (if any) obligations from above FHIR consents.

Consent Enforcement Service: Demonstrate enforcement of RESEARCH Consent authorization decision and any obligations returned from CDS.

Bonus Demonstration how Consent Enforcement Service can facilitate De-Identification of patient healthcare record.

Advanced Directive Scenario

TBD

Other possible Scenarios:

  • Consent to Treatment / Participation in research trial
  • Check for Treatment Consent
  • Join trusted Consent provider pool
  • Update/Add new consent
  • Validate Consent for research trial
  • Validate Consent for treatment  [Both accept and deny] 

Other Possible Issue to explore:

  • Consent and Interactions with Terminologies and Ontologies
  • Consent and Policy execution
  • Extended Consent Discovery

TestScript(s)

Check the HHS ONC LEAP demo repo on github to access the HL7-FHIR-Connectathon-Sept2020-Consent-Track project

> git clone https://github.com/sdhealthconnect/leap-demos.git
> cd leap-demos/hl7-fhir-connectathon-sept2020-consent-track/examples

Security and Privacy Considerations

These consideration can be found in github project repo @ https://github.com/sdhealthconnect/leap-demos/tree/master/hl7-fhir-connectathon-sept2020-consent-track

and will be updated as more information becomes available.

Report Out


Track Goals

This track focused on using FHIR consent in a number of key use cases including but not limited the use of a Consent Decision Service for use case around privacy, consent for treatment, and participation is research. In addition aspects of Consent Enforcement, Sharing, and discovery are explored.  Key Components in this track's approach were;

  • FHIR® Consent Client - To engage the patient in developing their consent.
  • FHIR® Consent Decision Service (CDS) - Returns authorization decision and any obligations as a result of evaluating the patient Consent resource.
  • FHIR® Consent Enforcement Services (CES) - Enforces the "permit" or "deny" decision and/or orchestrates delivery of response, obligations, and actions to downstream systems for granular controls.
  • FHIR® Security Labeling Services (SLS) - Determines if a given resource, v2 message segment, or observation in C-CDA is sensitive.
  • FHIR® Privacy Protective Services (PPS) - Acts on authorization obligations, actions, and recommendations from SLS to perform such tasks as "REDACT" of sensitive information as defined by patient's consent resource.

Track Attendees

Name Organization
Duane DeCouteauSaperi Systems
Mohammad JafariSan Diego Health Connect
Tracy OkuboOffice of National Coordinator for Health IT
Kathleen ConnorU.S. Department of Veteran Affairs
Zoran MilosevicDeontik
Russell McDonellTelstra Health
Mukundan ParthasarathyHewlett Packard Enterprise
Sathya KrishnasamyAnthem
Tom HickeCognitive Medical Systems


Notable Achievements

  • 2 FHIR® Consent Decision Services were demonstrated (Mohammad Jafari, Russell McDonell)

           LEAP-CDS - Key feature was use of Policy Rule and Provision in Decisioning

           Telstra Health CDS - Key feature use of Class in request with Consent for Decisioning

           Both had strong combining methods for discovery of patient, and consent across multiple  FHIR® instances

  • The 8 Privacy-Consent Scenario's were demonstrated against the LEAP-CDS passing 7 (Duane DeCouteau)
  • FHIR® Consent Enforcement Services (CES) was demonstrated in V2 Message and C-CDA exchange (Duane DeCouteau)
  • FHIR® Security Labeling Services (SLS) was demonstrated in V2 Message and C-CDA exchange (Duane DeCouteau)
  • FHIR® Privacy Protective Services (PPS) was demonstrated in V2 Message and C-CDA exchange (Duane DeCouteau)
  • FHIR® PROXY Consent Enforcement Services (CES) was demonstrated  in FHIR® exchange which included granular controls at class level (Mohammad Jafari)


Items that still need further investigation were;

FHIR® Consent Client - There was no suitable interface for engaging the patient demonstrated

Informed Consent - Not addressed 

Research Consent - Much discussion on whether FHIR® Consent resource can support this.

Advanced Directives - Not addressed


Demonstrations

This session was recorded and can be viewed or downloaded in following link.

Topic: Consent-Management Connect25's Personal Meeting Room
Start Time : Sep 10, 2020 06:46 PM

Meeting Recording:
https://zoom.us/rec/share/FSZt-AKVGdiryZ97whKL0j3MoKJDgxU-c0Gu_X3kMIrECzImwHm-Xba_lUC96PLc.XYv76HgNz6VL5XNk

Access Passcode: a2?J?5L&


Demonstration Screenshots

Evaluating authorization decision LEAP-CDS Privacy Consent Scenarios


Orchestration V2 exchange LEAP-V2-Orchestrator, LEAP-CDS, LEAP-SLS, LEAP-PPS, FHIR AuditEvent of disclosure


Orchestration CCDA exchange LEAP-CCDA-Orchestrator, LEAP-CDS, LEAP-SLS, LEAP-PPS, FHIR AuditEvent of disclosure


Telstra Consent Decision Service (CDS)




LEAP FHIR Consent Enforcement Service Proxy (CES-Proxy)



Discovered Issues

(Russell) There's no 'confidentiality', no 'sensitivity' in the FHIR Consent resource - well, nothing called that, or looking like that. Everything seems to be dropped, like a grab bag of stuff, in 'securityLabel'. But the cdsHooks response seems to split it out - some how ...
I have assumed any with a 'v3-Confidentiality' is an "id" - each in it's own "id" and everything with a 'v3-ActCode' is a 'parameter'.
So, if there's two 'v3-Confidentiality' and four 'v3-ActCode' in a securityLabel, then that's two 'id's, each with four 'parameters'. And then you have to keep the logical OR of all of that across all actors, across all Consent resources, across all FHIR servers ...


(Russell) the connectathon documentation showed an example of a cdsHooks type interaction, with a JSON structure, but no JSON Schema - no cardinality. Now the test JSON has no 'class' - so my service rejects it. WIth out 'class' the Concent Decision Service does not know 'over what' the caller is seeking consent. With out 'class' it's just an ambit claim for access, with the hope that if the patient has ever lodge a Consent, then the caller can get back knowledge that there is a Consent out there somewhere, and what the 'secuityLabel's are ... My Consent Decision Service rejects ambit/fishing exercises, but I haven't found any guidance as to whether that is correct, or incorrect.


(Russell) Is anyone around who can help with mapping the request to the Consent resource, and the Consent resource to the response? For instance, the request has 'class' of value/system, but Consent has 'class' of code/system. Do I test that the code == value? And the Consent resource has securityLabel, but the response has id and many codes per id. Do I sort/filter/split securityLabels some how?


(Mohammad & Duane) Issue with Provision, which is discussed in detail on San Diego Health Connect LEAP project blog at https://sdhealthconnect.github.io/leap/blog/2020/05/13/provisions.html.


(Kathleen) Consent resource can not meet requirements of Research Consent in its current form.  Consider Contract Resource.


Now What?

All agree that R4 Consent is not ready for consumer use.  Much work to continue as US Office of National Coordinator for Health IT is tackling many of these issues.




  • No labels