Difference between revisions of "Minutes - Security WG 2022-12-14"

From Health Level 7 Belgium Wiki
Line 16: Line 16:
 
===== Excused/Not present =====
 
===== Excused/Not present =====
 
* Bruno Casneuf
 
* Bruno Casneuf
* Didier Temans
 
 
* Erwin Bellon
 
* Erwin Bellon
 
* Hannes De Clercq  
 
* Hannes De Clercq  
 +
* Isabelle Pollet
 
* Jan Lenie  
 
* Jan Lenie  
 
* Nick Hermans  
 
* Nick Hermans  

Revision as of 09:31, 14 December 2022

Attendees
  • Anthony Maton
  • Bart Decuypere
  • Bart Rondou
  • Brecht Van Vooren
  • Cyprien Janssens
  • Félix De Tavernier
  • Jan Stinissen
  • Jean-Michel Polfliet
  • José Costa Teixeira
  • Karlien Erauw
  • Philippe Baise
  • Steven Van den Berghe
  • Werner De Mulder
Excused/Not present
  • Bruno Casneuf
  • Erwin Bellon
  • Hannes De Clercq
  • Isabelle Pollet
  • Jan Lenie
  • Nick Hermans
  • Pablo d'Alcantara
Agenda
  • Context / needs
  • Identification of other stakeholders
  • Position of HL7 Belgium on the FHIR R5 release (to cover the already upcoming questions from players and stakeholders in Belgium)
  • Security controls
  • Literal references in FHIR resources: need for guidelines ?
  • FHIR readiness of Belgian metahub-hub system: see preparation work
Minutes
  • all hubs need to be present 5Cozo, VNZ, RSW)- Karlien will reach out to them
  • first agenda point : security controls - linked to access matrix, see background
  • access matrix from eHealth platform need to be mapped to FHIR
  • possible solution in security labels if we make it a required field as an extension
  • we would need to define a default behavior
  • would be at if the label is there, only some attributes would be exposed/shared
  • José proposes to start with an implementation guide (not a slide deck) at Belgian level
  • the topic relates to work start at HL7 int'l - put scty labels at resource level
  • an extension is planned to include an new resource permission (htis person can use these specific data elements)
  • starting with scty labels would be a good starting point
  • there will be need for guidance for each FHIR release
  • Denmark solution: those concepts were modelled independently of the resources
  • Steven has implemented solutions that identify the resource (type of info) and not the user
  • the application level also defines some rules and behavior of the server
  • the access matrix might turn in an unimplementable thing
  • the access matrix can change overnight which needs to be taken into account - discussions are still ongoing (paradigm shift)
  • attribute base filtering: servers are assumed to filter attributes is concern
  • do we have to look at some languages
  • These requirements have been identified:
  • whatever solution it should be evolutive
  • decouple the type of data from the access permissions. So label things as "contains psi information" instead of "can only be accessed by psi people"
  • coexistence of consent and permission ruled access controls
  • action items: start specification in order to move to implementation guide
Action items
Next meeting
  • Wednesday at 9AM biweekly starting from Jan 11 ?