Difference between revisions of "Minutes - Referral WG 2022-12-08"
From Health Level 7 Belgium Wiki
KarlienErauw (talk | contribs) (Created page with "=== Attendees === * Anne Nerenhausen * Anthony Maton * Bart Decuypere * Benjamien Schmitt * Christophe Behaegel * Cyprien Janssens * Dorsan De Fabribeckers * Geert Vandenhol...") |
KarlienErauw (talk | contribs) |
||
Line 32: | Line 32: | ||
=== Meeting Minutes === | === Meeting Minutes === | ||
− | * [https://github.com/hl7-be/referral/issues/190 Issue 190 on Request Group]: see [https://drive.google.com/file/d/1hJz7_A4zXPnHIHr3_-9l6IwXcVoNGCqN/view?usp=share_link presentation and scheme of | + | * [https://github.com/hl7-be/referral/issues/182 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 [https://www.hl7.org/fhir/narrative.html 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 | ||
+ | |||
+ | * [https://github.com/hl7-be/referral/issues/190 Issue 190 on Request Group]: | ||
+ | ::* see [https://drive.google.com/file/d/1hJz7_A4zXPnHIHr3_-9l6IwXcVoNGCqN/view?usp=share_link 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 will only be requestgroup | ||
::* there is a need to easily check the request group based on the service request | ::* 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 | ::* 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 === | === Agenda next meeting === | ||
* continuation of resolution of issues | * continuation of resolution of issues | ||
− | '''Next meeting: next week Thursday | + | '''Next meeting: next week Thursday 15 December at 4PM (which will replace the one from 22 December)''' |
Revision as of 17:20, 15 December 2022
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)