Skip to content

Latest commit

 

History

History
93 lines (71 loc) · 8.16 KB

README.md

File metadata and controls

93 lines (71 loc) · 8.16 KB
Raw

Privacy Consent on FHIR (PCF)

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.

CI Build

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

ITI bi-weekly development call

ITI meets for one hour every other week to develop this work toward Public-Comment, toward Trial-Implementation publication. Target for Public-Comment is spring/summer 2023, thus first Trial-Implementation publication in Fall 2023.

  • bi-weekly - Fridays @ 10amCT/11amET/1700CET
  • Starting March 3, 2023
  • teams meeting

Best to join the ITI-Technical committee, but I am interested in diverse perspectives from anyone.

Questions

questions to the ITI committee to aid with the development of the IG.

  • none

Decided

  1. Is Explicit Basic too advanced? If so, what should be moved to Intermediate? I think that timeframe and resource by id should be in an option that is between basic and intermediate. They are more powerful than one would expect basic, but they are easy to implement without deep inspection (using fundamental Base Resource elements of .id and .meta.lastUpdated). Intermediate requires that the authorization enforcement do deeper (aka Resource type specific) inspection. Do we have four levels rather than the current three (basic, intermediate, advanced, expert)?
    1. Each incremental parameter should be its own option. So we end up with Implicit, Explicit, and Advanced; mostly as they were. The following are incrementally built upon Basic: Data Timeframe, Data by id, Named research project, data author, and data relationship.
    2. I simply made the intermediate a set of options with these 5. So there is still use of 'intermediate'. The volume three profiling of Consent would then include the profiling for these 5 in one chapter.
  2. I did bring in SLS to Appendix P
  3. HIV is still important internationally
  4. Female Health may be a sensitive topic (menstruation cycle) - possible Open-Issue
  5. SLS valueset management, Explained ICD11 as some modern terms as exemplars of the continual maintenance.
  6. break-glass -- could support Deny All with break-glass. Thus all requests for treatment get Deny, but the deny is indicated as break-glass qualifying. Thus purposeOfUse break-glass is used. harder to support that some data is returned, but not all. -- Open-Issue, request solutions
  7. Include Privacy Preference flow in Appendix P, but not within the normative text.
  8. We are not going to provide details on Questionnaire / QuestionnaireResponse use. There are mentions of the possibility, but no more is to be said. A future revision of this or a new IG could address this.
  9. We are not going to profile how the Patient Privacy Policy could be retrieved other than the mention about use of MHD.
  10. Discussed the possibility of needing to do continued maintenance, including proving that historic access would have enforced the consent at that time, and thus the need for Consent versions, Provenance, and/or AuditEvent. -- Possible Open-Issue
  11. PCF is not addressing the use-case where a Consent (dissent) would forbid the data capture or recording. This was available in BPPC, but was not found to be used.
  12. Consent.provision and .provision.provision is all that we should need for our use-cases.

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. other things beyond scope
  7. 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