Difference between revisions of "Minutes - Security WG 2023-05-23"
From Health Level 7 Belgium Wiki
KarlienErauw (talk | contribs) |
KarlienErauw (talk | contribs) |
||
Line 53: | Line 53: | ||
::::* the decision to migrate data to a new FHIR version has to be managed at project level by the project team, taking these rules into account and manage/document the end of life if he wants to move to a new version | ::::* the decision to migrate data to a new FHIR version has to be managed at project level by the project team, taking these rules into account and manage/document the end of life if he wants to move to a new version | ||
::::::* publication page of FHIR profiles has to have an intermediary page to show the different versions | ::::::* publication page of FHIR profiles has to have an intermediary page to show the different versions | ||
+ | ::::* work on doc has to be continued in a shared doc (KE to setup- | ||
* access controls and security labels: [https://docs.google.com/document/d/1sX3-K1EIvLo6cr2GGp_aS8s9k9lmXzUeT-6cjY0Htp0/edit see document here] | * access controls and security labels: [https://docs.google.com/document/d/1sX3-K1EIvLo6cr2GGp_aS8s9k9lmXzUeT-6cjY0Htp0/edit see document here] | ||
− | ::* | + | ::* layering of access (KB78 or non KB 78) |
+ | ::::* it is up to the access control to decide what to do with it | ||
+ | ::::* rules on access need to be implementable | ||
+ | ::* guideline: these are the security labels that are available that can be used for a project | ||
+ | ::::* a specific project can use the security labels for a permission (a scty label is an attribute f.e. psychiatric info) | ||
+ | ::::* a GP soft can automatically label info where the label has a clear meaning | ||
+ | |||
+ | |||
===== Action items ===== | ===== Action items ===== |
Revision as of 10:13, 23 May 2023
Attendees
- Bart Decuypere
- Benny Verhamme
- Brecht Van Vooren (partially online)
- Brian Thieren
- Elien De Koker
- Jean-Michel Polfliet
- José Costa Teixeira
- Karlien Erauw
- Nick Hermans (partially online)
- Steven Van den Berghe
- Werner De Mulder
Excused/Not present
- Anthony Maton
- Cyprien Janssens
- Didier Temans
- Dominiek Leclerq
- Erwin Bellon
- Félix De Tavernier
- Jan Stinissen
- Filip Veldeman
- Isabelle Pollet
- Jan Lenie
- Marco Busschots
- Nico Vannieuwenhuyze
- Philippe Baise
- Stef Hoofd
Agenda
- future work topics and way of working
Minutes
- Determine scope and future action items of this working group
- we need to look at the bigger picture and publish guidelines on a more strategic level
- of course we need to continu to support projects to move towards mature FHIR implementations
- on top of implementation guids we also need transition guides
- what are the important topics that need our attention and for which guidelines are necessary:
- hub/metahub system and FHIR readiness & functionalities
- versioning and FHIR R5 release
- access controls & security labels
- evolution of FHIR: a kind of end of life template is needed
- work on FHIR capability server: have runtime information at one specific moment in time
- one endpoint for all versions, or one endpoint for every version: TBC
- different endpoints will need to be maintained
- can we distinguish major (needing new endpoints so implementers will have to change their endpoint implementation) and minor releases (one endpoint for different versions)
- intended data capabilities need to be written out
- we discuss the presented document
- metadata meta.profile can be used but that should be done with caution ! a written guidance should be put together by HL7 Belgium
- we should aim to have only 2 versions active - advise 6 months in advance that a version will go into end of life
- aim for stability of FHIR R4 for at least 2 years
- the decision to migrate data to a new FHIR version has to be managed at project level by the project team, taking these rules into account and manage/document the end of life if he wants to move to a new version
- publication page of FHIR profiles has to have an intermediary page to show the different versions
- work on doc has to be continued in a shared doc (KE to setup-
- access controls and security labels: see document here
- layering of access (KB78 or non KB 78)
- it is up to the access control to decide what to do with it
- rules on access need to be implementable
- guideline: these are the security labels that are available that can be used for a project
- a specific project can use the security labels for a permission (a scty label is an attribute f.e. psychiatric info)
- a GP soft can automatically label info where the label has a clear meaning
Action items
- Position of HL7 Belgium on FHIR R5 release and versioniong needs to be written out (to cover the already upcoming questions from players and stakeholders in Belgium)
- FHIR readiness of Belgian metahub-hub system: a guidance document needs to be started
- Security controls & access controls: continue work on use cases for permission and consent
Next meetings
- Wednesday 14 June at 9AM online