Minutes - Referral WG 2022-12-08
From Health Level 7 Belgium Wiki
Revision as of 17:20, 15 December 2022 by KarlienErauw (talk | contribs)
Attendees
- Anne Nerenhausen
- Anthony Maton
- Bart Decuypere
- Benjamien Schmitt
- Christophe Behaegel
- Cyprien Janssens
- Dorsan De Fabribeckers
- Geert Vandenhole
- Hans De Keersmaeker
- Jacques Yakoub
- Jean-Michel Polfliet
- José Costa Teixeira
- Julien Beard
- Maarten Cobbaert
- Marleen Van Eygen
- Maxime Daive
- Philippe Baise
Excused
- Bart Reekmans
- Ben Goosse
- Jean-Francois Coquelet
- Karlien Erauw
- Katleen Smedts
- Laurent Lamouline
- Pieter Devolder
- Richard Francken
Agenda
- resolution of issues
Meeting Minutes
- Issue 182 - Narrative: legal people are checking if it is allowed to ignore/not to take it into account in the narrative
- who is responsible for the narrative if one is generated, generally the FHIR server generates one
- Bart clarifies the definition and purpose of a FHIR narrative, f.E. for emergency purposes
- in this case the FHIR narrative will not be used by the software systems
- the identity of the patient cannot be available in the narrative, the message will be pseudonomised (at least part of it) before sending
- the narrative will be a reflection of the resource, so there is no issue as the narrative can be generated
- the narrative will be not "must support"
- there is a strong opposition against forbidding the narrative
- the generation of a narrative is a business decision, the result of this discussion will be brought to this WG next time
- there will have to be taken a decision on the acceptance of the narrative
- see presentation and scheme
- ServiceRequest :
- RequestGroup = a group of related request
- there would be a complexity that is added which might reduce interoperability - and it not aligned with FHIR recommendations
- there will only be requestgroup
- there is a need to easily check the request group based on the service request
- how will we retrieve the request group from the service request- use extension or API feature as reverseInclude
- therefore there is a recommendation to only have a requestgroup when needed
only use a requestgroup if there is a strong dependence of several servicerequests ; if servicerequests are only loosely linked then it would be preferable to only use the requisition ID
- this will also have an impact on the reconciliation of medication
- Hans will check if this is feasible and will come back on this next meeting
Agenda next meeting
- continuation of resolution of issues
Next meeting: next week Thursday 15 December at 4PM (which will replace the one from 22 December)
