Minutes - Security WG 2023-06-14

From Health Level 7 Belgium Wiki
Attendees
  • Bart Decuypere
  • Benny Verhamme
  • Brian Thieren
  • Dominiek Leclerq
  • Elien De Koker
  • Félix De Tavernier
  • Jan Stinissen
  • José Costa Teixeira
  • Karlien Erauw
  • Philippe Baise
  • Pieterjan Uytterhoeven
  • Steven Van den Berghe
Excused/Not present
  • Anthony Maton
  • Brecht Van Vooren
  • Cyprien Janssens
  • Didier Temans
  • Erwin Bellon
  • Filip Veldeman
  • Isabelle Pollet
  • Jan Lenie
  • Jean-Michel Polfliet
  • Marco Busschots
  • Nick Hermans
  • Nico Vannieuwenhuyze
  • Stef Hoofd
  • Werner De Mulder
Agenda
  • work on defined action items
Minutes
  • Conclusion from the F2F meeting:
  • we need to publish guidelines on a more strategic level
  • Update from HL7 FHIR devdays at Amsterdam
  • permission & consent resource
  • google has been working on data structure to know the rules on data exchange
  • consent: purpose specific
  • there might other rules based on permission : regardless of consent this HCP may have access based on the access matrix a permission
  • this needs to be standardised, HL7 Int'l will start capturing the needs for data access upon a need for data exchange with another party (for the other party to understand the consent & permission), an IG will be developed, might not be on a short term
  • we want to start the work in Belgium, starting with the access matrix, and start putting some first rules in place and adding others upon demand
  • the access matrix is an Excel file that might be open for interpretation
  • start with information in a token (to know who comes in), that needs to be checked against the rules (some look-up will be needed)
  • we will need some functional vocabulary to express this (related to an access token), that is beyond the FHIR scope, resulting in a kind of logical model
  • there are elements already available in the eHealth Platform IAM tokens that will need to be included in this logical model
  • HL7 Belgium will initialise this
  • document with use case: keep it aside, start small with the current access matrix
  • evolution of FHIR: need for :
  • end of life template
  • guideline for transition from R4 to R5
  • guideline for versioning : eHealth PF standards teamhave started to actively collect the versioning issues
  • no update on security labels (see doc here), use of meta profile : in the longer time we cannot rely on it, which does not mean we cannot use it
  • upon publishing an IG, it will show the validity period with start date and end date, determined by the publisher (when putting an end date or updating it, you need to republish again, but the notification is informative)
  • FHIR readiness on hub/metahub system
  • there is a proposal from the hubs (Cozo + VZNK) how to integrate to FHIR, which has been handed over to eHealth platform ; the proposal has not yet been approved by Abrumet and RSW
  • there is a phase 1 that is proposed
  • when can we expect a solution to share FHIR resources ?
  • a rule based approach have to be developed
  • if rules can change, the approach continues to work
  • a repository will be started for access & security (for the moment


  • 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 guides 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
  • decide to invite Stephane Houpresse to enlighten us on the access matrix, its history & evolution
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 28 June 9AM on access matrix
  • Wednesday 12 July 9AM on contained resources and search options
Retrieved from "https://wiki.hl7belgium.org/index.php?title=Minutes_-_Security_WG_2023-06-14&oldid=2465"