Minutes - Security WG 2023-02-22
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
