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
• 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

• using provenance is an option
• setup attribute access control is an option

• client id will be checked whether he can access the resource
• an extension might be needed

• permission resource is added to FHIR R5

• info on R5: "This 5th Major release of the FHIR specification is labeled as 'trial-use' because the entire ballot cycle that led to this release was performed under the HL7 STU (Standard for Trial Use). None of the content in this specification is considered "Normative", but the content that was previously normative in Release 4 is still labelled as Normative to preserve the status through the publication and implementation of this release. HL7 plans to publish the next release as a normative specification.

• the use case can be added to Use cases for Permission and Consent and respective need for interoperability and computability: document here. We might come up with 2 solutions:

• the ideal world where the permission resource can be used
• a temporary solution

• identifier management

• linked to referral project that will produce millions of prescriptions yearly
• Anthony wrote up a proposal but there are security concerns

• versioning of resources: how to handle in FHIR

• you can add version in metadata meta.profile
• link structure definition to resource, then you can add a version

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 9AM