Privacy Consent on FHIR (PCF)

formal publication https://profiles.ihe.net/ITI/PCF/index.html

project proposal

Note where decisions are made and a concept is put into the IG, it is generally removed from the README. Thus the readme is not comprehensive, it is focused mostly on open-issues, questions, and parking lot.

Approved for TI: 2023-07-25

CI Build

http://build.fhir.org/ig/IHE/ITI.PCF/branches/master/index.html

• Update Z.8 to indicate PCF is available for Patient Consent on FHIR.

Multi-Generation Plan?

I suspect that everyone sees a different scope to this general problem. Consent is often very complex as one digs deeper. So I present a plan of attack that starts with a well defined "Community", the MHDS community; and a well defined object-to-be-controlled, the document.

1. MHDS -- The Central MHDS Document Registry enforcing Consents, just controlling Document Consumer actor. I think this will need to call upon the new SeR to provide tokens that a distributed repository would be expected to enforce. Note that Consent would be recorded in the central FHIR server (adding a Consent Registry actor), there would not be a distributed Consent Registry. Likely one Consent per patient with rules for the whole Community.
2. MHDS + mXDE/QEDm -- adding access rules around resources derived from Documents
3. MHDS + XCA -- given that XCA is used to connect a MHDS community to broader network of community; then this use-case would add Consent terms for requests coming in from the outside.
4. QEDm standalone -- this is later in the generation plan as there is no pre-defined community or terms of connection defined. However this likely is not unlike the previous, just needing the previous to be worked out fully before this is added. This use-case bring switch it FHIR Resource based object control (prior the object to be controlled is a document)
5. Residual Obligations/Refrains - same as above but there would be 'permit' provisions that require some refrain or obligation
6. support for tagging at an element level, rather than just Resource. An example is within the Patient resource there are various addresses and phone numbers that might need to be tagged with specific sensitivities that might have release rules indicated in either overall policy or Consent instance. Other examples are needed to fully justify this added overhead.
7. Defined full workflow for break-glass
8. use of FHIR R5 Consent

Research

Other IGs that have constrained Consent for Privacy purposes

Note that there are many IGs that have profiled Consent for Advanced Directives / Living Wills; and for Consent to treat.

Data pulled from the new FHIR Guides Stats page - which is constantly being updated. (24 indications of profile on FHIR Consent)

Privacy Consent:

• DaVinci Health Record Exchange (HRex)
  • HRex Consent Profile
• SDOH Clinical Care
  • SDOHCC Consent release authorization
• Specialty Medication Enrollment
  • Specialty Rx Consent
• UK INTEROPen Care Connect FHIR Profiles
  • CareConnect Consent 1
• Switzerland Core
  • CH Core EPR-Consent

Other research to note

• HL7 FHIR DS4P
  • STU Publication of HL7 FHIR® Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1
  • FHIR Data Segmentation for Privacy - CI build
• John Moehrke blog
  • RelatedPerson Consent
  • Explaining FHIR Consent examples
  • FHIR Consent mapped to BPPC
  • Security Labeling Service
  • Consent with Segmented Data
• Mohammad Jafari blog
  • A Developer's Guide to Security labeling in FHIR
  • Consents Revocation and Redisclosure
  • Consent Overarching Policy
• ONC LEAP Computable Consent Project
  • High-Level Architecture
  • Scalability in Consent Management
  • Future Directions for the LEAP Consent Project