Difference between revisions of "Minutes - Security WG 2023-05-23"

From Health Level 7 Belgium Wiki
 
(6 intermediate revisions by the same user not shown)
Line 43: Line 43:
 
* evolution of FHIR: a kind of end of life template is needed
 
* 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
 
::* 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
 
::* intended data capabilities need to be written out
;;::* we discuss [https://drive.google.com/file/d/1bQg38faSQySh7NuXQrjG4WHJS-grbDbB/view?usp=share_link the presented document]
+
::::* we discuss [https://drive.google.com/file/d/1bQg38faSQySh7NuXQrjG4WHJS-grbDbB/view?usp=share_link 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
 
::* metadata meta.profile can be used but that should be done with caution ! a written guidance should be put together by HL7 Belgium
* the decision to migrate data to a new FHIR version has to be managed at project level by the project team
+
::* we should aim to have only 2 versions active - advise 6 months in advance that a version will go into end of life, info about versions needs to be documented, more in detail as to what is [https://www.ehealth.fgov.be/standards/fhir/vaccination/history.html available now]
 +
::* 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 [https://docs.google.com/document/d/1UUxCpMmkyr3z4_Au7x3SslKfwcb1ILLr/edit?usp=share_link&ouid=105469359652835948544&rtpof=true&sd=true a shared doc]
  
 
* 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 ; same for hospital/EPD systems
 +
::* we have to work with roles, resources and labels
 +
::::* labels have to be defined
 +
::* roles: check in access matrix
 +
::* a patient can override to make all visible
 +
::* do we have to talk about security labels or labels or content labels
 +
 
 +
 
  
 
===== Action items =====
 
===== 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)
 
* 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  
 
* 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
+
* Security controls & access controls: continue work on use cases for permission and consent, towars a more strategic level
  
 
===== Next meetings =====
 
===== Next meetings =====
 
* Wednesday 14 June at 9AM online
 
* Wednesday 14 June at 9AM online

Latest revision as of 10:42, 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
  • 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, info about versions needs to be documented, more in detail as to what is available now
  • 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
  • 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 ; same for hospital/EPD systems
  • we have to work with roles, resources and labels
  • labels have to be defined
  • roles: check in access matrix
  • a patient can override to make all visible
  • do we have to talk about security labels or labels or content labels


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, towars a more strategic level
Next meetings
  • Wednesday 14 June at 9AM online