Difference between revisions of "Minutes - Security WG 2023-02-22"

From Health Level 7 Belgium Wiki
Line 25: Line 25:
  
 
===== Agenda =====
 
===== Agenda =====
* Context / needs
 
* Determine meeting schedule
 
 
* Security controls
 
* Security controls
 
* [https://build.fhir.org/references.html Literal references in FHIR resources]: need for guidelines ? see issue from WG referral (linked to Vitalink/brecht VV)
 
* [https://build.fhir.org/references.html Literal references in FHIR resources]: need for guidelines ? see issue from WG referral (linked to Vitalink/brecht VV)
Line 33: Line 31:
  
 
===== Minutes =====
 
===== Minutes =====
 
+
* Use cases for Permission and Consent and respective need for interoperability and computability
TBC - to be confirmed
+
::* Scenario 1: Patient 1 has chronic alcohol addiction.
* Security controls: this group has to provide technical guidance supporting the functional requirement
+
::::* Patient 1 has a Problem (Condition) - describing the type of condition
::* Brecht V.V. to explain
+
::::* Patient 1 has a treatment plan, including some psychiatric consultations and a prescription for Antabuse 400mg (dissulfiram)
+
::::* Patient does not wish the condition to be revealed to anyone except their family physician
* Phrase point of view on R4 & R5 release
+
::::* Regulation determines that all psychiatric treatments are not to be shared with health professionals other than people involved in care
 
+
::::* Hospital sends the prescription for Antabuse, the pharmacy consults it - at which moment the pharmacist infers the condition of the patient from the medication.
* FHIR readiness of hub/metahub system
+
::::* The same medication treatment will be in different flows, and each flow may be subject to different, specific rules and controls.
Use cases for Permission and Consent and respective need for interoperability and computability
 
 
 
 
 
Scenario 1: Patient 1 has chronic alcohol addiction.
 
Patient 1 has a Problem (Condition) - describing the type of condition
 
Patient 1 has a treatment plan, including some psychiatric consultations and a prescription for Antabuse 400mg (dissulfiram)
 
Patient does not wish the condition to be revealed to anyone except their family physician
 
Regulation determines that all psychiatric treatments are not to be shared with health professionals other than people involved in care
 
Hospital sends the prescription for Antabuse, the pharmacy consults it - at which moment the pharmacist infers the condition of the patient from the medication.
 
The same medication treatment will be in different flows, and each flow may be subject to different, specific rules and controls.
 
 
 
 
 
 
This use case shows that there is no absolute rule because the information that we want to hide is going to be disclosed implicitly anyway.
 
This use case shows that there is no absolute rule because the information that we want to hide is going to be disclosed implicitly anyway.
 
One possibility to prevent this unforeseen disclosure would be to include the pharmacist in the patient’s care team.
 
One possibility to prevent this unforeseen disclosure would be to include the pharmacist in the patient’s care team.
Line 60: Line 46:
  
 
This means the information needs to be controlled based on  
 
This means the information needs to be controlled based on  
Data type (e.g. “prescription”)
+
::* Data type (e.g. “prescription”)
Role (e.g. “pharmacist)
+
::* Role (e.g. “pharmacist)
Actual data (e.g. type of medication)
+
::* Actual data (e.g. type of medication)
Context (e.g. current encounter)
+
::* Context (e.g. current encounter)
 
 
  
 
In addition, the propagation of such permission is an attention point - can the permission be automatically extrapolated to derived records?
 
In addition, the propagation of such permission is an attention point - can the permission be automatically extrapolated to derived records?
  
 
+
::* Scenario 2: Patient decides they do not want their TB infection status to be shared with the authorities because that may prevent them from traveling.  
 
 
Patient decides they do not want their TB infection status to be shared with the authorities because that may prevent them from traveling.  
 
 
Patient gives an explicit negative consent to conceal data related to the MERS diagnosis
 
Patient gives an explicit negative consent to conceal data related to the MERS diagnosis
 
However, this is not expected to have any effect on concealing the data as MERS is notifiable disease
 
However, this is not expected to have any effect on concealing the data as MERS is notifiable disease
Line 84: Line 67:
 
The data itself.
 
The data itself.
  
 
+
::* Scenario 3: 17 year-old patient decides that parents are not allowed to see the hormonal or contraceptive prescriptions.
 
 
17 year-old patient decides that parents are not allowed to see the hormonal or contraceptive prescriptions.
 
 
This is a known case. eHealth has information. We can ask Stephane Houpresse  
 
This is a known case. eHealth has information. We can ask Stephane Houpresse  
  
 +
::* Scenario 4: Patient data is transmitted to outside of the place where the permissions and consent are valid
 +
::::* Patient data is transmitted based on Consent, but the consent is not sent out too
 +
::::* We also need to consider traceability - i.e. track where the information went  and what consents/labels/permissions were assigned to it at any moment.
  
 
+
::* Scenario 5: Hospital needs to provide the GDPR Art 30 registry
Patient data is transmitted to outside of the place where the permissions and consent are valid
 
Patient data is transmitted based on Consent, but the consent is not sent out too
 
We also need to consider traceability - i.e. track where the information went  and what consents/labels/permissions were assigned to it at any moment.
 
 
 
 
 
 
 
 
 
Hospital needs to provide the GDPR Art 30 registry
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DZOP need: How do we prevent unintended sharing of broad resources like communication? E.g. we want a given project to access the DZOP communications, but not the VIDIS-related communications.
 
DZOP need: How do we prevent unintended sharing of broad resources like communication? E.g. we want a given project to access the DZOP communications, but not the VIDIS-related communications.
 
 
Related: how do we prevent the misues of _has and _include search parameters
 
Related: how do we prevent the misues of _has and _include search parameters
  
 +
::* conclusion: 3 places where (metadata about sharing) is present:
 +
::::* Policy catalog
 +
::::* In transit
 +
::::* On servers/endpoints
  
 
+
::* See: https://build.fhir.org/ig/HL7/fhir-security-label-ds4p/
3 places where (metadata about sharing) is present:
 
Policy catalog
 
In transit
 
On servers/endpoints
 
 
 
 
 
https://build.fhir.org/ig/HL7/fhir-security-label-ds4p/
 
  
 
===== Action items =====
 
===== Action items =====
* security controls: start document describing the current access matrix and the possible FHIR functionalities
+
* security controls: update document describing the current access matrix and the possible FHIR functionalities
 
* prepare feedback on FHIR readiness hub/metahub system  
 
* prepare feedback on FHIR readiness hub/metahub system  
  
 
===== Next meeting =====
 
===== Next meeting =====
 
* Wednesday 8 March at 9AM
 
* Wednesday 8 March at 9AM

Revision as of 07:44, 8 March 2023

Attendees
  • Anthony Maton
  • Bart Decuypere
  • Benny Verhamme
  • Brecht Van Vooren
  • Brian Thieren
  • Félix De Tavernier
  • Jean-Michel Polfliet
  • José Costa Teixeira
  • Steven Van den Berghe
Excused/Not present
  • Cyprien Janssens
  • Didier Temans
  • Elien De Koker
  • Erwin Bellon
  • Isabelle Pollet
  • Jan Lenie
  • Jan Stinissen
  • Karlien Erauw
  • Marco Busschots
  • Nick Hermans
  • Philippe Baise
  • Werner De Mulder
Agenda
  • Security controls
  • Literal references in FHIR resources: need for guidelines ? see issue from WG referral (linked to Vitalink/brecht VV)
  • Position of HL7 Belgium on the FHIR R5 release (to cover the already upcoming questions from players and stakeholders in Belgium)
  • FHIR readiness of Belgian metahub-hub system: see preparation work
Minutes
  • Use cases for Permission and Consent and respective need for interoperability and computability
  • Scenario 1: Patient 1 has chronic alcohol addiction.
  • Patient 1 has a Problem (Condition) - describing the type of condition
  • Patient 1 has a treatment plan, including some psychiatric consultations and a prescription for Antabuse 400mg (dissulfiram)
  • Patient does not wish the condition to be revealed to anyone except their family physician
  • Regulation determines that all psychiatric treatments are not to be shared with health professionals other than people involved in care
  • Hospital sends the prescription for Antabuse, the pharmacy consults it - at which moment the pharmacist infers the condition of the patient from the medication.
  • The same medication treatment will be in different flows, and each flow may be subject to different, specific rules and controls.

This use case shows that there is no absolute rule because the information that we want to hide is going to be disclosed implicitly anyway. One possibility to prevent this unforeseen disclosure would be to include the pharmacist in the patient’s care team.

Depending on the context, the pharmacist may be expected to see the full medication list or not. In some cases we can give the disclosure for a specific encounter, not more.

This means the information needs to be controlled based on

  • Data type (e.g. “prescription”)
  • Role (e.g. “pharmacist)
  • Actual data (e.g. type of medication)
  • Context (e.g. current encounter)

In addition, the propagation of such permission is an attention point - can the permission be automatically extrapolated to derived records?

  • Scenario 2: Patient decides they do not want their TB infection status to be shared with the authorities because that may prevent them from traveling.

Patient gives an explicit negative consent to conceal data related to the MERS diagnosis However, this is not expected to have any effect on concealing the data as MERS is notifiable disease

This shows that consent by patient would always be checked against the actual rules (e.g. according to GDPR’s Public Health justification for data sharing). In this case, consent is not really determining the access to data. Rules can dictate the impact of consent.


Some patients pertain to special social groups for which health information may be required to be disclosed e.g. vaccination status for a given profession or for attending school. Such flows of data need to be well defined and controlled. We see a good opportunity to enter the granularity that is needed to do this properly - sharing data according to rules depending on: The expected use of the data, The role of the person accessing the data The data itself.

  • Scenario 3: 17 year-old patient decides that parents are not allowed to see the hormonal or contraceptive prescriptions.

This is a known case. eHealth has information. We can ask Stephane Houpresse

  • Scenario 4: Patient data is transmitted to outside of the place where the permissions and consent are valid
  • Patient data is transmitted based on Consent, but the consent is not sent out too
  • We also need to consider traceability - i.e. track where the information went and what consents/labels/permissions were assigned to it at any moment.
  • Scenario 5: Hospital needs to provide the GDPR Art 30 registry

DZOP need: How do we prevent unintended sharing of broad resources like communication? E.g. we want a given project to access the DZOP communications, but not the VIDIS-related communications. Related: how do we prevent the misues of _has and _include search parameters

  • conclusion: 3 places where (metadata about sharing) is present:
  • Policy catalog
  • In transit
  • On servers/endpoints
Action items
  • security controls: update document describing the current access matrix and the possible FHIR functionalities
  • prepare feedback on FHIR readiness hub/metahub system
Next meeting
  • Wednesday 8 March at 9AM