Minutes - Referral WG 2022-12-08

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 and 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

Next meeting: next week Thursday 15 December at 4PM (which will replace the one from 22 December)

Anonymous