Minutes - Referral WG 2023-06-16
From Health Level 7 Belgium Wiki
Revision as of 07:16, 16 June 2023 by KarlienErauw (talk | contribs)
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 expecdt this
- Update from Cyprien on usse "is performer the correct place":
- 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
- Continue resolution of issues
- issue 214 namespace for identifier: proposal to use header
- review has been finalised and WG agrees with this solution so issue can be closed
- 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
- field based on performer task
- a performer task must be linked to a prescription via basedOn
- field basedOn is not mustSupport, needs indeed to be changed to mustSupport
- needs indeed to be changed to mustSupport
- 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
- 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
- the INAMI number is not saved, you can consult it through Cobhra it it is there
- 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
- 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 nursing use cases here
- looking into "1.9 Education and self-care for diabetes patients without a care path", see example here
Agenda next meeting
- continue resolution of issues and presentation of use cases
Next meeting: next week Friday 30 June at 9AM
