Skip to content
/ ITI.PCF Public
generated from IHE/supplement-template

The Privacy Consent on FHIR (PCF) Profile provides support for patient privacy consents and access control where a FHIR API is used to access Document Sharing Health Information Exchanges. This profile includes both Consent profiling and access controls profiling of oAuth access token.

License

Notifications You must be signed in to change notification settings

IHE/ITI.PCF

Repository files navigation

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:

Other research to note

About

The Privacy Consent on FHIR (PCF) Profile provides support for patient privacy consents and access control where a FHIR API is used to access Document Sharing Health Information Exchanges. This profile includes both Consent profiling and access controls profiling of oAuth access token.

Topics

Resources

License

Code of conduct

Stars

Watchers

Forks

Packages

No packages published