Difference between revisions of "Minutes - Security WG 2023-10-18"
From Health Level 7 Belgium Wiki
KarlienErauw (talk | contribs) |
KarlienErauw (talk | contribs) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 3: | Line 3: | ||
* Bart Decuypere | * Bart Decuypere | ||
* Benny Verhamme | * Benny Verhamme | ||
| + | * Brecht Van Vooren | ||
* Brian Thieren | * Brian Thieren | ||
* Dominiek Leclerq | * Dominiek Leclerq | ||
* Elien De Koker | * Elien De Koker | ||
* Félix De Tavernier | * Félix De Tavernier | ||
| − | |||
* Hanne Vuegen | * Hanne Vuegen | ||
* Jean-Michel Polfliet | * Jean-Michel Polfliet | ||
| − | |||
* Karlien Erauw | * Karlien Erauw | ||
* Maxime Caucheteur | * Maxime Caucheteur | ||
| Line 18: | Line 17: | ||
===== Excused/Not present ===== | ===== Excused/Not present ===== | ||
| − | |||
* Cyprien Janssens | * Cyprien Janssens | ||
* Didier Temans | * Didier Temans | ||
* Erwin Bellon | * Erwin Bellon | ||
* Filip Veldeman | * Filip Veldeman | ||
| + | * Filoretta Velica | ||
* Isabelle Pollet | * Isabelle Pollet | ||
* Jan Lenie | * Jan Lenie | ||
* Jan Stinissen | * Jan Stinissen | ||
| + | * José Costa Teixeira | ||
* Marco Busschots | * Marco Busschots | ||
* Nick Hermans | * Nick Hermans | ||
| Line 33: | Line 33: | ||
===== Agenda ===== | ===== Agenda ===== | ||
* review feedback on pseudonymization of FHIR resources | * review feedback on pseudonymization of FHIR resources | ||
| − | * [https://docs.google.com/document/d/10i3qI-2i3MHpCHP1fD5Umfc601GgSOLB/edit proposal] | + | * [https://docs.google.com/document/d/10i3qI-2i3MHpCHP1fD5Umfc601GgSOLB/edit proposal on attachments] |
===== Minutes ===== | ===== Minutes ===== | ||
| − | * | + | * Pseudonymization technical document: there is an urge from some eHealth projects to move forward faster due to the deadlines on some projects (Vialink FHIR and UHMEP project) |
| − | ::* | + | ::* there have been discussions on a higher level outside the HL7 Belgium community and the decision was to publish asap |
| − | + | ::* the proposal fitted the projects so it will be published | |
| − | + | ::* an IG in architecture & security will be published, following the slides discussed the previous weeks, the work on the technical artefacts is still ongoing but will be ready in the coming days | |
| − | + | ::::* this will not include an overview of the pseudonymization service, it is linked to the cookbook that is published | |
| − | + | ::* the link to the publication will be shared with this group ; as always it will be open for comments | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | * | + | * [https://docs.google.com/document/d/10i3qI-2i3MHpCHP1fD5Umfc601GgSOLB/edit Presentation of proposal on how to handle attachments] |
| − | + | ::* all the pros and cons of the 3 options (binary, media, DocumentReference) have been listed in the document | |
| + | ::* the storage solution is out of scope of this proposal | ||
| + | ::* the document proposes Binary asthe best option | ||
| + | ::::* remark: DocumentReference can include a link to the resource and can be more flexible for some use cases | ||
| + | ::* what do we want to standardize as all of the options are already standardized: there is not a one size fits all/ there cannot be an advice that you should always use binary ; this was not the goal of the proposal. An attachment can have a reference/url | ||
| + | ::::* it will result in a communication resource as a profile for Vitalink FHIR, there are some concerns on the performance ; alternative is to have a filesystem but then you need an access system | ||
| + | ::::* the group is looking at the int'l profile, payload attribute: https://hl7.org/fhir/R4/communication.html | ||
| + | ::::::* BeCommunication will be included in the BeCore profile that will also include the recipient; attachment datatype will be in there, with DocumentReference you can have additional properties, but they might already be in the BeCommunication ; there is a security context though | ||
| + | ::::* maybe a Be profile on DocumentReference could be useful as a part of the Attachment in Communication | ||
| + | ::::* Abrumet has a usecase on Image for DocumentReference | ||
===== Action items ===== | ===== Action items ===== | ||
| − | * | + | * Continue discussion on attachments proposal & presentation of BE profile on Communication or DocumentReference |
| − | |||
| − | |||
===== Next meetings ===== | ===== Next meetings ===== | ||
| − | * Wednesday | + | * Wednesday 8 Nov at 9AM (in 3 weeks as 1 Nov and for some 15 Nov are holidays) |
Latest revision as of 08:26, 18 October 2023
Attendees
- Anthony Maton
- Bart Decuypere
- Benny Verhamme
- Brecht Van Vooren
- Brian Thieren
- Dominiek Leclerq
- Elien De Koker
- Félix De Tavernier
- Hanne Vuegen
- Jean-Michel Polfliet
- Karlien Erauw
- Maxime Caucheteur
- Philippe Baise
- Steven Van den Berghe
- Werner De Mulder
Excused/Not present
- Cyprien Janssens
- Didier Temans
- Erwin Bellon
- Filip Veldeman
- Filoretta Velica
- Isabelle Pollet
- Jan Lenie
- Jan Stinissen
- José Costa Teixeira
- Marco Busschots
- Nick Hermans
- Nico Vannieuwenhuyze
- Stef Hoofd
Agenda
- review feedback on pseudonymization of FHIR resources
- proposal on attachments
Minutes
- Pseudonymization technical document: there is an urge from some eHealth projects to move forward faster due to the deadlines on some projects (Vialink FHIR and UHMEP project)
- there have been discussions on a higher level outside the HL7 Belgium community and the decision was to publish asap
- the proposal fitted the projects so it will be published
- an IG in architecture & security will be published, following the slides discussed the previous weeks, the work on the technical artefacts is still ongoing but will be ready in the coming days
- this will not include an overview of the pseudonymization service, it is linked to the cookbook that is published
- the link to the publication will be shared with this group ; as always it will be open for comments
- all the pros and cons of the 3 options (binary, media, DocumentReference) have been listed in the document
- the storage solution is out of scope of this proposal
- the document proposes Binary asthe best option
- remark: DocumentReference can include a link to the resource and can be more flexible for some use cases
- what do we want to standardize as all of the options are already standardized: there is not a one size fits all/ there cannot be an advice that you should always use binary ; this was not the goal of the proposal. An attachment can have a reference/url
- it will result in a communication resource as a profile for Vitalink FHIR, there are some concerns on the performance ; alternative is to have a filesystem but then you need an access system
- the group is looking at the int'l profile, payload attribute: https://hl7.org/fhir/R4/communication.html
- BeCommunication will be included in the BeCore profile that will also include the recipient; attachment datatype will be in there, with DocumentReference you can have additional properties, but they might already be in the BeCommunication ; there is a security context though
- maybe a Be profile on DocumentReference could be useful as a part of the Attachment in Communication
- Abrumet has a usecase on Image for DocumentReference
Action items
- Continue discussion on attachments proposal & presentation of BE profile on Communication or DocumentReference
Next meetings
- Wednesday 8 Nov at 9AM (in 3 weeks as 1 Nov and for some 15 Nov are holidays)
