Difference between revisions of "Minutes - Security WG 2023-10-18"

From Health Level 7 Belgium Wiki
(Created page with "===== Attendees ===== * Anthony Maton * Bart Decuypere * Benny Verhamme * Brian Thieren * Dominiek Leclerq * Elien De Koker * Félix De Tavernier * Filoretta Velica * Hanne...")
 
 
(2 intermediate revisions 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  
−
* Filoretta Velica
 
 
* Hanne Vuegen
 
* Hanne Vuegen
 
* Jean-Michel Polfliet
 
* Jean-Michel Polfliet
−
* José Costa Teixeira
 
 
* Karlien Erauw
 
* Karlien Erauw
 
* Maxime Caucheteur
 
* Maxime Caucheteur
Line 18: Line 17:
  
 
===== Excused/Not present =====
 
===== Excused/Not present =====
−
* Brecht Van Vooren
 
 
* 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
−
* proposal  
+
* [https://docs.google.com/document/d/10i3qI-2i3MHpCHP1fD5Umfc601GgSOLB/edit proposal on attachments]
  
 
===== Minutes =====
 
===== Minutes =====
−
* We review on how the feedback from the 20 Sept meeting on [https://docs.google.com/presentation/d/17ys63H19j-gMzf1SDfVzUZfqPvnZDY_WVxFlE07QXl8/edit#slide=id.g283b0eddda1_1_0 pseudonymization]
+
* 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)
−
::* is it possible to have a shorthand for f.e. SSIN
+
::* there have been discussions on a higher level outside the HL7 Belgium community and the decision was to publish asap
−
::::* this is possible but however there is no real use for it. The transit info should be used to transform the pseudonym to its eventual form, because the pseudonym is different for every transmission. This form is not suitable to be stored or processed otherwise.
+
::* the proposal fitted the projects so it will be published
−
::::* On top, this will impact the validation of pseudonymized and non-pseudonymized resources, because of the additional slice to be added to pseudonymizable resources.
+
::* 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
−
::::* extensions are not preferable, what if you don't store it ; but pseudonymized is not an unique identifier so it could not be used this way
+
::::* this will not include an overview of the pseudonymization service, it is linked to the cookbook that is published
−
::::* what about blinding/unblinding (see cookbook): not clear yet
+
::* the link to the publication will be shared with this group ; as always it will be open for comments
−
 
 
−
::* reuse info from header and omit it from the FHIR message
 
−
::::* Each pseudonym has its own transit info, even if you use the “multiple” functionality
 
−
 
 
−
::* how to solve the search problem for pseudonymized resources?
 
−
::::* size of getRequest is limited, however there is an alternative in the FHIR standard, using post syntax
 
−
::::* search can done using POST and POST url syntax because of the size of the search parameters
 
−
::::* how will we express the parameters ? There are 2 options:
 
−
::::::* treat parameter as composite parameter using a separate token, concatenation using a $ sin
 
−
::::::* encode pseudonym in a JWE string, this will have a double impact of Base64 encoding
 
−
::::* which option do we agree upon ?
 
−
::::::*  this is not a FHIR query, therefore the composite
 
−
::::* this is only for solutions that use pseudonymization
 
−
 
 
  
−
* Discuss search for contained resource
+
* [https://docs.google.com/document/d/10i3qI-2i3MHpCHP1fD5Umfc601GgSOLB/edit Presentation of proposal on how to handle attachments]
−
::* see [https://github.com/hl7-be/referral/issues/255 issues 255] and [https://github.com/hl7-be/referral/issues/257 257] in referral project
+
::* 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 =====
−
* Security controls: continue work on valuesets by Brecht
+
* Continue discussion on attachments proposal & presentation of BE profile on Communication or DocumentReference
−
* 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 meetings =====
 
===== Next meetings =====
−
* Wednesday 15 Nov at 9AM
+
* 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
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)
Retrieved from "https://wiki.hl7belgium.org/index.php?title=Minutes_-_Security_WG_2023-10-18&oldid=2565"