Minutes - Security WG 2023-04-18

Attendees

• Bart Decuypere
• Brecht Van Vooren
• Dominiek Leclerq
• Jan Stinissen
• José Costa Teixeira
• Karlien Erauw
• Nico Vannieuwenhuyze
• Philippe Baise
• Stef Hoofd, smals/vitalink
• Steven Van den Berghe
• Werner De Mulder

Excused/Not present

• Anthony Maton
• Benny Verhamme
• Brian Thieren
• Cyprien Janssens
• Didier Temans
• Elien De Koker
• Erwin Bellon
• Félix De Tavernier
• Filip Veldeman, BMIA
• Isabelle Pollet
• Jan Lenie
• Jean-Michel Polfliet
• Marco Busschots
• Nick Hermans

Agenda

• agenda item from Vitalink
• data capabilities hospital projects
• UUID

Minutes

• Agenda item:

• As Vitalink we store FHIR resources in scope of multiple business projects and for different software vendors to write and/or consult data.
• Soon we will have two projects (let’s say A and B) that will be using the same resource type (R).

Actors for project A will be allowed to create and read resources of type R created by other actors of project A. Same for B. There will be possible integrators (C) that will be allowed to read both: resources in scope of project A and B.

• I made this as general as possible, because the use case we have now will not be the only one.

How can we (as Vitalink) enforce access management on resources of type R but made in scope of two different projects A and B? Can we require the client to add a security-label to the meta-part of the resource? This will enable a way to manage access for consultation based on the label. In case we require a security-label on an eHealth standardized profile definition, I assume we are still compliant to the implementation guide as it’s an optional field. But can we deny resources without a security label?

• What we have in mind is to configure an access matrix where a client is linked to (a) label(s) for each resource type. Project A will be allowed to do CRUD operations on resources R with label A, same for B. Project C will be allowed to search on resources R with label A and B.
• Vitalink would like to have the opinion of the WG on this.
• obliging client to add a certification is an option

• what if you want to share the resource with others afterwards

• • • OLD

• Filip works toward semantic interoperability and on implementing a single structured problem list within a hospital (using NLP to migrate to Snomed CT)
• caresets & FHIR come into play here, therefore Filip joins this WG

• CoZo: FHIR resource received from pharma softs

• should URL be put in the resource
• it is technically possible but not the best way to go
• what type of coding is best to use the vendor number

• Data capabilities projects call from FOD VG/SPF - deadline 17 April

• projects on hospitals network level that look into structured data
• linked to federated structured problem list within one hospital & sumehr so caresets & FHIR
• there are different levels: hospital, hospital networks, hub/metahub level

• there is ambition to do it on the top level in the right way ; what is the best way ? which people are needed to include ?
• there is the need to be interoperable with the European level

• maturity of FHIR resources is still quite low at European level, the data modelling part is mature though

• using provenance is an option

• identifier management

• linked to referral project that will produce millions of prescriptions yearly
• what if the request is being cancelled
• FHIR allows multiple identifiers per resource, some can be temporary, a period of validity can be added
• can the prescribing system use an identifier ?
• Anthony will write up a proposal

• Please continue to provide your feedback to Use cases for Permission and Consent and respective need for interoperability and computability: see document here

• Please note that the next meeting is on Tuesday 17 April at 10AM (due to easter holidays)

Action items

• Security controls: continue work on use cases for permission and consent
• 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

Next meeting

• Wednesday 3 May at 19AM