This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

FHIR Consent Directive Use Case Examples by Tarik Idris

From HL7Wiki
Jump to navigation Jump to search

Back to CBCC Wiki: Meetings

Back to HL7 FHIR Consent Directive Project

Back to FHIR Consent Directive Use Cases

Allow sharing data published by organization X

Some HIEs we encountered (esp. in the US) required each participating organization to provide a consent document per patient that authorizes them to add their data to the longitudinal record. The consent is often primarily tracked in an EHR and communicated to the HIE as part of an HL7v2 ADT message (commonly using a PD1 flag instead of a CON segment). The value of a FHIR interface would be allowing simple HL7 message adapters (e.g. in an integration engine) to check the consent status and allow changing it if necessary.

Allow access using access level L for organization X or for a particular user

This is an approach we often see in US and european HIEs. A management application allows a user (either a clerical user/front desk or a nurse or doctor, and sometimes the patient herself through a patient portal) to determine different access levels for different organizations or sometimes individuals (esp. in europe). The number of different access levels is usually quite low (e.g. 5 in Switzerland). A structured representation of the access levels is usually not necessary, because they are legally defined (as in Switzerland) or they are so few and stable enough that they can be pre-arranged and configured by the participating systems.

Example 1 for access levels:

  1. Access to all medical data
  2. Access to medical data meant for external communication (includes transfer notes, discharge notes, sometimes surgery reports; does not include imaging data, temperature and similar measurements, etc.)

Example 2 for access levels:

  1. administrative data (includes demographics)
  2. limited data (includes demographics, allergy/diabetes/clotting information, advanced directives)
  3. normal data (includes demographics, allergy/diabetes/clotting information, advanced directives, normal sensitivity clinical documents like summaries, images, etc. that do not "stigmatize")
  4. extended data (includes demographics, allergy/diabetes/clotting information, advanced directives, normal sensitivity clinical documents, but also "stigmatizing" data like mental illness & STDs)
  5. all data

Allow access to a specific identified encounter/episode/object… for organization X or for a particular user

This is common in German HIEs, where the user or their whole organization is only allowed access to a specific subset of data. The subset of data is not based on the type of data, but on a specific instance. This could be an encounter, where a a referring physician is allowed to see the referral results and similar data linked to the encounter, but nothing else. A similar case is the "episode of care" record, where a care team jointly treats the patient and is allowed to add and see data related to that episode of care (which may encompass multiple encounters at different facilities). Sometimes it is even limited to a particular shared document that multiple named users are supposed to collaboratively edit for that patient, e.g. a multi-page running documentation of a pregnancy. In all of these cases there must be a link to an object instance (encounter, episode of care or a document) and one or more organizations and / or individuals.