IHE / ITI.PCF

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.
Creative Commons Attribution 4.0 International
2 stars 2 forks source link

PCF_22: Multi-Generation possibilities #39

Open JohnMoehrke opened 1 year ago

JohnMoehrke commented 1 year ago

The first release of PCF has many use-cases and applicability; but there are specific use-cases that are not included. These were excluded due to unclear how realistic they are. They are in theory useful, but not clear how soon they would be implemented in real-world products. So we await market showing interest in these or other use-cases:

  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
  9. etc

Please contact IHE to express need for any of these. New Work Item Proposals would be the proper way to start improving PCF.