Difference between revisions of "Minutes - Security WG 2022-12-14"
From Health Level 7 Belgium Wiki
KarlienErauw (talk | contribs) (Created page with "===== Attendees ===== * Bart Decuypere * Félix De Tavernier * Jean-Michel Polfliet * José Costa Teixeira * Karlien Erauw ===== Excused/Not present ===== * Bart Rondou...") |
KarlienErauw (talk | contribs) |
||
(9 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
===== Attendees ===== | ===== Attendees ===== | ||
+ | * Anthony Maton | ||
* Bart Decuypere | * Bart Decuypere | ||
+ | * Bart Rondou | ||
+ | * Brecht Van Vooren | ||
+ | * Cyprien Janssens | ||
* Félix De Tavernier | * Félix De Tavernier | ||
+ | * Jan Stinissen | ||
* Jean-Michel Polfliet | * Jean-Michel Polfliet | ||
* José Costa Teixeira | * José Costa Teixeira | ||
− | * Karlien Erauw | + | * Karlien Erauw |
− | + | * Philippe Baise | |
+ | * Steven Van den Berghe | ||
+ | * Werner De Mulder | ||
===== Excused/Not present ===== | ===== Excused/Not present ===== | ||
− | |||
* Bruno Casneuf | * Bruno Casneuf | ||
− | |||
* Erwin Bellon | * Erwin Bellon | ||
* Hannes De Clercq | * Hannes De Clercq | ||
+ | * Isabelle Pollet | ||
* Jan Lenie | * Jan Lenie | ||
* Nick Hermans | * Nick Hermans | ||
Line 25: | Line 31: | ||
* FHIR readiness of Belgian metahub-hub system: see preparation work | * FHIR readiness of Belgian metahub-hub system: see preparation work | ||
+ | ===== Minutes ===== | ||
+ | * all hubs need to be present: Cozo, 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 item: start specification in order to move to implementation guide | ||
+ | * all hubs need to be present: Cozo, VNZ, RSW)- Karlien will reach out to them | ||
+ | * [https://build.fhir.org/references.html second agenda point: references] | ||
+ | ::* literal references (resources are identified and addressed by their URL) <> logical references (a logical reference to the entity that the target resource would describe without it begin pointing to something that actually exist as a FHIR instance) | ||
+ | ::* at Vitalink they have built in a logic to determine which kind of reference it is | ||
+ | ::* do we need a guideline here as HL7 FHIR gives the liberty | ||
− | + | * the meeting is adjourned at 10AM as the majority of the people has to leave for another meeting | |
===== Action items ===== | ===== Action items ===== | ||
===== Next meeting ===== | ===== Next meeting ===== | ||
+ | * Wednesday 25 Jan at 9AM - biweekly schedule is still in need of confirmation due to some stakeholders being absent |
Latest revision as of 08:38, 25 January 2023
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: Cozo, 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 item: start specification in order to move to implementation guide
- all hubs need to be present: Cozo, VNZ, RSW)- Karlien will reach out to them
- second agenda point: references
- literal references (resources are identified and addressed by their URL) <> logical references (a logical reference to the entity that the target resource would describe without it begin pointing to something that actually exist as a FHIR instance)
- at Vitalink they have built in a logic to determine which kind of reference it is
- do we need a guideline here as HL7 FHIR gives the liberty
- the meeting is adjourned at 10AM as the majority of the people has to leave for another meeting
Action items
Next meeting
- Wednesday 25 Jan at 9AM - biweekly schedule is still in need of confirmation due to some stakeholders being absent