Difference between revisions of "Minutes - Referral WG 2023-06-16"

From Health Level 7 Belgium Wiki
 
(One intermediate revision by the same user not shown)
Line 41: Line 41:
 
=== Meeting Minutes ===
 
=== Meeting Minutes ===
 
* Project Update
 
* Project Update
::* coobkbook pseudonmisation is missing details, a new update will be released by eHealth Platform, no update on when we might expecdt this
+
::* coobkbook pseudonmisation is missing details, a new update will be released by eHealth Platform, no update on when we might expect this
  
* Update from Cyprien on [https://github.com/hl7-be/referral/issues/250 usse "is performer the correct place"]:  
+
* Update from Cyprien on an enhanced offer/comodity for integrators using $graph:  
 
::* mainly ons SR is used for the phase 1 templates
 
::* mainly ons SR is used for the phase 1 templates
 
::* bePerformerTask is used  
 
::* bePerformerTask is used  
 
::* working towards needing to do only one call
 
::* working towards needing to do only one call
::* $graph resource will be used, which can return a bundle, a set of resources
+
::* [https://hl7.org/fhir/R4/graphdefinition.html#fetch $graph resource will be used], which can return a bundle, a set of resources
 
::::* the graph operation will be on the service request  
 
::::* the graph operation will be on the service request  
 
::::* there is an example of this bundle, starting with the SR, then practioner role resource
 
::::* there is an example of this bundle, starting with the SR, then practioner role resource
 +
::* it is part of the October release and does not have any impact on the June release
 +
::::* it will be demonstrated in an example
  
 
* Continue resolution of issues
 
* Continue resolution of issues
* [https://github.com/hl7-be/referral/issues/214 issue 214 namespace for identifier]: proposal to use header
+
* [https://github.com/hl7-be/referral/issues/250 issue 250]: no update from Maarten from the business
::* review has been finalised and WG agrees with this solution so issue can be closed
 
  
* [https://github.com/hl7-be/referral/issues/250 is performer the correct place]
+
* [https://github.com/hl7-be/referral/issues/257 issue 257]: Anthony will clarify, let's look at [https://hl7.org/fhir/search.html#contained the search definitions for contained resources]: you will not be able to search for it as a separate resource, which is why UHMEP does not use it as it creates a lifecycle issue
::* practioner role is in a contained resource and cannot be searched
+
::*  
::* several stakeholders prefer option 1 instead of an extension
 
::* Julien thinks that performerType is the correct place but the cardinality at int'l level is 0 to 1 and we need O to * not correct so we would need an extension and this is not narrowing down
 
::* could it work with a practioner role ? we need multiple performer types as sometimes the request can be performed by different types of performers to fulfill one service request (f.e. diabetes education by nurse & physiotherapist)
 
::* option is to force the prescriber to choose the type of the performer
 
::::* the prescribers (HCP) need to be consulted to proceed in this way
 
::::* to check if this needs a change in the logical model
 
  
* looking into the new issues
+
* [https://github.com/hl7-be/referral/issues/256 issue 256]: searching on the content is possible but no searching for the resource itself
* [https://github.com/hl7-be/referral/issues/251 field based on performer task]
+
::* the issue remains open as it has to be looked into detail
::* a performer task must be linked to a prescription via basedOn
 
::* field basedOn is not mustSupport, needs indeed to be changed to mustSupport
 
 
 
* [https://github.com/hl7-be/referral/issues/253 field basedOn on referral task]
 
::* needs indeed to be changed to mustSupport
 
 
 
* [https://github.com/hl7-be/referral/issues/254 id for ressource practitionerRole and practitionner]
 
::* INAMI reasoning: there is no way/a lack in Belgium to identify a HCP so the proposed way is the only way to identify the HCP that is meaningful
 
::* does a HCP that performs a referral not always have a INAMI number? it indeed exists that a nurse does not have an INAMI number, f.e. a nurse that works in a hospital; an example needs to be provided
 
  
 
* [https://github.com/hl7-be/referral/issues/255 Consultation of a list of BeReferralPrescriptions - also with nihii number]
 
* [https://github.com/hl7-be/referral/issues/255 Consultation of a list of BeReferralPrescriptions - also with nihii number]
::* When consulting prescriptions, it is important to be able to search by nihii number and not just by niss. This is important for both the performer and the requester
+
::* needed internal discussions
::* the INAMI number is not saved, you can consult it through Cobhra it it is there
+
::* a date will be settled to discuss more
::::* a HCP can perform care tasks using the INAMI number of a hospitaln (often foreigners)
 
::::* a visa is the right to practice
 
::::* students receive a temporary INAMI number, after their specialisation it can change
 
 
 
* [https://github.com/hl7-be/referral/issues/256 contained ressource & search]
 
::* the "contained resource" concept will not used in the UHMEP project
 
::::* it is stated that searches in contained resources are feasible
 
::::* in a contained resource you can put your own reference
 
 
 
* issue 242 is still open outside of the June release but important
 
 
 
 
 
  
* as information see description of [[file:///C:/Users/ERAUWKarlien(KERA)/Downloads/ReferralPrescription.Use.Cases.Nursing.V0.3.pdf|nursing use cases here]]
+
* [https://github.com/hl7-be/referral/issues/254 issue 254]
::* looking into "1.9 Education and self-care for diabetes patients without a care path", [https://build.fhir.org/ig/hl7-be/referral/branches/issue-241/ServiceRequest-ucgh241p19-1.html see example here]
+
::* why not allow resource logical "identifier" to be used instead of technical "id" to reference a resource?
 +
::* DPO needs to be consulted here
  
  
Line 99: Line 74:
 
* continue resolution of issues and presentation of use cases
 
* continue resolution of issues and presentation of use cases
  
'''Next meeting: next week Friday 30 June at 9AM '''
+
'''Next meeting: next week Friday 7 July at 9AM '''

Latest revision as of 08:02, 16 June 2023

Attendees

  • Anthony Maton
  • Bart Decuypere
  • Bart Reekmans
  • Ben Goosse
  • Cyprien Janssens
  • Emily Sevrin
  • Geert Vandenhole
  • Hans De Keersmaecker
  • Jean-Michel Polfliet
  • Julien Beard
  • Karlien Erauw
  • Maarten Cobbaert
  • Maxime Daive
  • Philippe Baise
  • Philippe Lejoly
  • Robin Merckx

Excused

  • Alexis Van Zeveren
  • Anne Nerenhausen
  • Christophe Behaegel
  • Dorsan de Fabricheckers
  • Jacques Yakoub
  • Jean-Francois Coquelet
  • José Costa Teixeira
  • Katleen Smedts
  • Katrien Dickx
  • Katrien Thorré
  • Lionel Cremer
  • Marleen Van Eygen
  • Nathan Peeters
  • Laurent Lamouline
  • Pablo Christiaens
  • Pieter Devolder
  • Richard Francken

Agenda

  • continue resolution of issues (214, 250 and new issues)

Meeting Minutes

  • Project Update
  • coobkbook pseudonmisation is missing details, a new update will be released by eHealth Platform, no update on when we might expect this
  • Update from Cyprien on an enhanced offer/comodity for integrators using $graph:
  • mainly ons SR is used for the phase 1 templates
  • bePerformerTask is used
  • working towards needing to do only one call
  • $graph resource will be used, which can return a bundle, a set of resources
  • the graph operation will be on the service request
  • there is an example of this bundle, starting with the SR, then practioner role resource
  • it is part of the October release and does not have any impact on the June release
  • it will be demonstrated in an example
  • Continue resolution of issues
  • issue 250: no update from Maarten from the business
  • issue 256: searching on the content is possible but no searching for the resource itself
  • the issue remains open as it has to be looked into detail
  • needed internal discussions
  • a date will be settled to discuss more
  • why not allow resource logical "identifier" to be used instead of technical "id" to reference a resource?
  • DPO needs to be consulted here


Agenda next meeting

  • continue resolution of issues and presentation of use cases

Next meeting: next week Friday 7 July at 9AM