Difference between revisions of "Minutes - Referral WG 2022-12-08"

From Health Level 7 Belgium Wiki
(Created page with "=== Attendees === * Anne Nerenhausen * Anthony Maton * Bart Decuypere * Benjamien Schmitt * Christophe Behaegel * Cyprien Janssens * Dorsan De Fabribeckers * Geert Vandenhol...")
 
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 last week]
+
* [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
* [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
+
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
::* WG decides that narrative is not "must support" for this API
+
::* this will also have an impact on the reconciliation of medication
::* issue can be closed
+
::* Hans will check if this is feasible and will come back on this next meeting
 
 
* New issue - more than 1 medication in case of wound care:
 
::* for wound care we need to prescriptions in one (add at least 2 medications f.e. isobetadine first, flamazine afterwards) but this is not feasible in FHIR (BeMedication)
 
::* a request group can be used here that refers to the 2 prescriptions
 
 
 
* [https://github.com/hl7-be/referral/issues/191 Issue 191 - Versioning]
 
::* [https://drive.google.com/file/d/1z34MJz3thAz8-_X4--DmYroM0M_WNhlT/view?usp=share_link see scheme here]
 
::* await info
 
::* we think that both the structure and the businessrules can change because of evolutions in the legislation
 
 
 
* [https://github.com/hl7-be/referral/issues/183 Issue 193 - Requisition]
 
::* is part of the solution described 190 so this issue can be closed
 
 
 
* [https://github.com/hl7-be/referral/issues/177 Issue 177 - Timing datatype]
 
::* our input to HL7 Int'l has been accepted but the feature is not available in the current R4 release
 
::* RIZIV will check if the solution of start time + duration is sufficient to replace the start time + end time need
 
::* issue will remain open meanwhile
 
 
 
* [https://github.com/hl7-be/referral/issues/176 Issue 176 - date format & references]
 
::* date format: solution for formatting of the dates is accepted
 
::* 2nd part on references : remains open as still not found a mature solution
 
::* 3rd part on status reason: has been resolved some time ago
 
 
 
* [https://github.com/hl7-be/referral/issues/168 Issue 168 - add example scenarios]
 
::* [https://docs.google.com/spreadsheets/d/1WJlP1WmTRc_qbGpQJsSaffWZykqchv-x/edit?usp=sharing&ouid=100968134423355597040&rtpof=true&sd=true See document]
 
  
 
=== Agenda next meeting ===
 
=== Agenda next meeting ===
 
* continuation of resolution of issues
 
* continuation of resolution of issues
  
'''Next meeting: next week Thursday 5 Jan at 4PM (due to Christmas holidays)'''
+
'''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)