Difference between revisions of "Minutes - Referral WG 2021-12-14"

From Health Level 7 Belgium Wiki
(Created page with "draft ===== Attendees ===== * Dr Alain Derom * Bart Decuypere * Frederik De Kegel * Frederik Lenaerts * Hans De Keersmaecker * Jean-Michel Polfiet * Jos Bellen * José...")
 
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
draft
 
 
===== Attendees =====  
 
===== Attendees =====  
* Dr Alain Derom  
+
* Dr Alain Derom
 
* Bart Decuypere  
 
* Bart Decuypere  
* Frederik De Kegel
 
 
* Frederik Lenaerts  
 
* Frederik Lenaerts  
 
* Hans De Keersmaecker  
 
* Hans De Keersmaecker  
 
* Jean-Michel Polfiet  
 
* Jean-Michel Polfiet  
 
* Jos Bellen  
 
* Jos Bellen  
* José Costa Teixeira
 
 
* Karlien Erauw  
 
* Karlien Erauw  
 
* Kristof Jaubin  
 
* Kristof Jaubin  
* Peter Laridon (left early)
+
* Olivier Lothaire
* Robert Nicolas
+
* Philippe Cauchie (let at 4.30PM)
 
* Theo Schumacher  
 
* Theo Schumacher  
 
* Thibault Mahieu  
 
* Thibault Mahieu  
* Tom Fiers
 
 
* Tom Tollenaere  
 
* Tom Tollenaere  
 +
* Richard Francken
 
* Stefan Waegemans  
 
* Stefan Waegemans  
* Toon Schiemsky
 
 
* Werner De Mulder  
 
* Werner De Mulder  
  
Line 25: Line 21:
 
* Benny Verhamme  
 
* Benny Verhamme  
 
* Frédéric Istace  
 
* Frédéric Istace  
 +
* Frederik De Kegel
 
* Joost Van Averbeke  
 
* Joost Van Averbeke  
 +
* José Costa Teixeira
 
* Mieke Buckinx
 
* Mieke Buckinx
 
* Nico Vannieuwenhuyze
 
* Nico Vannieuwenhuyze
 
* Nick Hermans  
 
* Nick Hermans  
 
* Paul Neyens
 
* Paul Neyens
* Richard Francken
+
* Peter Laridon
 +
* Robert Nicolas
 +
* Tom Fiers
 +
* Toon Schiemsky
 +
 
  
 
===== Agenda =====
 
===== Agenda =====
* Rework on issues resulted from the pilot phase, issues #48 and #50 having priority
+
* Rework on issues resulted from the pilot phase
  
 
===== Minutes =====
 
===== Minutes =====
 
* Up-to-date list of issues can be consulted [https://github.com/hl7-be/hl7-be-fhir-laboratory-report/issues here]
 
* Up-to-date list of issues can be consulted [https://github.com/hl7-be/hl7-be-fhir-laboratory-report/issues here]
* Issue 48 & 50 have priority: no structure is available, does extension need to be created ? Both are linked.
+
* Issue 33 : DiagnosticReport.code : coding same as composition type
* Issue 48 "At result level: accredited and / or performed by external laboratory: can we have extensions for both?"
+
::* Set both to "laboratory report"?
* Issue 50 "At Organization-level, could there be a note-field (or other) to indicate the BELAC accreditation of the laboratory?": there is no note/comment field at organisation level. Do we need this ? A lab is allowed to do it, it is not mandatory. Having a possibility for a note at test level and note on report level, gives every lab a solution. Comment field at diagnostic report level makes sense. In practice it is put on the footer of the report by labs. There is no comment field now at diagnostic report level. here is no comment field now at bundle level. Range of identifiers can be added (RIZIV number), unlimited number can be added, adding here one for lab accreditation can be added here. Do we need to add NamingSystem, f.e. https://economie.fgov.be/belac, but what if a lab has a Dutch accreditation ? Issue moves to resolved
+
::* In examples we find e.g. Hematology studies, but our reports are typically more extensive than only hematology
* Issue 50: it should be noted if test is under accreditation or not - it is not mandatory - if you are accreditated you have to mention if the test is not done under accreditation
+
::* subject of lab report will be in the subject f.e. hematology will appear as chapter in lab report
* Issue 50: "At result level: accredited and/or performed by external laboratory: can we have extensions for both?" : proposal to put it unstructured in a note at BeObservationLaboratory level - we could create 2 boolean extension fields will be created, not mandatory, one for accredited result, one to indicate an external result but this would only serve Belac
+
::* proposal: not to put the type at this level in the lab report, just call it laboratory studies
* Issue 51: Common LOINC codes can appear twice/multiple times in the same DiagnosticReport (all Specimen Processing comments). It can also happen upon a trombosite test using different agents - same LOINC code with different agents or with timestamps. So it is not an issue and can be closed.
+
::* Bart looked at LOINC codes (11502-2, not coded as RETAM yet at federal level)
* Priority of other issues will be determined in the pilot phase meeting on Wednesday, following on this, issue resolutions will be presented next week
+
::* Philippe proposes to test this first (later today), be careful that an hematology study comes from another service
 +
::* let's allow it for now and await the tests
 +
* Issue 23: How to encode comments
 +
::* We need to specify how to deal with different kinds of comments. Here an inventory and suggestion of process:
 +
::::* a. Comment on a result of analysis - may be done .note to the result? But there are different cases possible:
 +
::::::*  a.i. result field itself maybe comment or text (e.g. "Positive" or "No longer performed by lab; replaced by analyses XXX"
 +
::::::*  a.ii. Comment in commentfield may be combined with number (or comment0 in result field)
 +
::::* b. Comment regd. reference values (e.g. age-specifics) – in .text to the reference values?
 +
::::* c. We often created dummy test codes to contain comments. E.g. serum aspect. Is this allowed? There are no LOINC codes for these dummies - will we allow every lab to use their own. Can we use this system? If not, how do we encode such comment?
 +
::::* d. Comments regarding the laboratory (not the results). E.g. status of accreditation. We currently use dummy tests for that. Acceptable? If not, then how?
 +
::::* e. Comments regarding tests performed by 3rd parties. We currently do that by means of flags (codes) next to results, and use a dummy test to explain the legend. Allowed? If not then how?
 +
::::* f. Comments regarding administrative issue, e.g. missing information like gender, DOB. Today we use dummy test codes. Allowed? If not, then how?
 +
::::* g. There is also a .conclusionCode - to use instead of dummy analyses? Or a combination? Dummy analysis have the advantage they can be linked to a sample (useful e.g. for serum aspect) - .conclusionCodes cannot do this.
 +
::::* Do we want/need to agree on standards for the above? Or allwo every lab to do their own way?
 +
::* there are 3 LOINC codes availabel 55752-0, 94330-8 and 86468-6
 +
::* there is also a note field available for comments
 +
::* on analysis level there are also comments
 +
::* Issue can be moved to "for implementation" status
 +
* Issue 31 given name (patient & practitioner)
 +
::* when a person has more than one given namen
 +
::* do it in one field in the FHIR resource or do it in seperate fields ?
 +
::* proposal to put it in one field as in the EID
 +
* Issue 30: patient status during specimen collection
 +
::* Medina never fills this in so field should be optional
 +
::* on specimen resource there is a note field of type annotation where you can put any text
 +
* Issue 25: same issue as 33 but on different level (at diagnostic report level while issue 33 is on level)
 +
::* move to "done"  
 +
* Issue 47 : RequestCode
 +
::* where to put the RequestCode : don't put it in the lab result
 +
::* the protocol will not always match the request
 +
::* the analysis order codes cannot be mapped 1-to-1 to lab codes
 +
* Issue 46 How to flag a receiver patient inversion event?
 +
::* consensus: receiver should have a look at the identifier - if the patient is different then they need to remove the data connected to the original patient and have to link it to the data of the patient that is in the diagnostic report
 +
::* move to "to be implemented" , there is a test plan available for this
 +
* Issue 45 : narrative
 +
::* Medina will put narrative everywhere
 +
* Issue 19 unique identifier for non Belgian patients
 +
::* citizens that don't have a INSZ/SSIN or BIS number : how can they be identified ?
 +
::* possible solution: unique LAB RIZIV identifier + an identifier composed by the lab (the report id)
 +
::::* NamingSystem will be vendor specific
 +
* New issue: Create NamingSystem for BIS numbers
  
 
'''Next Meeting:''' on Tuesday Dec 21 4PM
 
'''Next Meeting:''' on Tuesday Dec 21 4PM

Latest revision as of 15:12, 17 January 2022

Attendees
  • Dr Alain Derom
  • Bart Decuypere
  • Frederik Lenaerts
  • Hans De Keersmaecker
  • Jean-Michel Polfiet
  • Jos Bellen
  • Karlien Erauw
  • Kristof Jaubin
  • Olivier Lothaire
  • Philippe Cauchie (let at 4.30PM)
  • Theo Schumacher
  • Thibault Mahieu
  • Tom Tollenaere
  • Richard Francken
  • Stefan Waegemans
  • Werner De Mulder
Excused/Not present
  • Alexis Van Zeveren
  • Benny Verhamme
  • Frédéric Istace
  • Frederik De Kegel
  • Joost Van Averbeke
  • José Costa Teixeira
  • Mieke Buckinx
  • Nico Vannieuwenhuyze
  • Nick Hermans
  • Paul Neyens
  • Peter Laridon
  • Robert Nicolas
  • Tom Fiers
  • Toon Schiemsky


Agenda
  • Rework on issues resulted from the pilot phase
Minutes
  • Up-to-date list of issues can be consulted here
  • Issue 33 : DiagnosticReport.code : coding same as composition type
  • Set both to "laboratory report"?
  • In examples we find e.g. Hematology studies, but our reports are typically more extensive than only hematology
  • subject of lab report will be in the subject f.e. hematology will appear as chapter in lab report
  • proposal: not to put the type at this level in the lab report, just call it laboratory studies
  • Bart looked at LOINC codes (11502-2, not coded as RETAM yet at federal level)
  • Philippe proposes to test this first (later today), be careful that an hematology study comes from another service
  • let's allow it for now and await the tests
  • Issue 23: How to encode comments
  • We need to specify how to deal with different kinds of comments. Here an inventory and suggestion of process:
  • a. Comment on a result of analysis - may be done .note to the result? But there are different cases possible:
  • a.i. result field itself maybe comment or text (e.g. "Positive" or "No longer performed by lab; replaced by analyses XXX"
  • a.ii. Comment in commentfield may be combined with number (or comment0 in result field)
  • b. Comment regd. reference values (e.g. age-specifics) – in .text to the reference values?
  • c. We often created dummy test codes to contain comments. E.g. serum aspect. Is this allowed? There are no LOINC codes for these dummies - will we allow every lab to use their own. Can we use this system? If not, how do we encode such comment?
  • d. Comments regarding the laboratory (not the results). E.g. status of accreditation. We currently use dummy tests for that. Acceptable? If not, then how?
  • e. Comments regarding tests performed by 3rd parties. We currently do that by means of flags (codes) next to results, and use a dummy test to explain the legend. Allowed? If not then how?
  • f. Comments regarding administrative issue, e.g. missing information like gender, DOB. Today we use dummy test codes. Allowed? If not, then how?
  • g. There is also a .conclusionCode - to use instead of dummy analyses? Or a combination? Dummy analysis have the advantage they can be linked to a sample (useful e.g. for serum aspect) - .conclusionCodes cannot do this.
  • Do we want/need to agree on standards for the above? Or allwo every lab to do their own way?
  • there are 3 LOINC codes availabel 55752-0, 94330-8 and 86468-6
  • there is also a note field available for comments
  • on analysis level there are also comments
  • Issue can be moved to "for implementation" status
  • Issue 31 given name (patient & practitioner)
  • when a person has more than one given namen
  • do it in one field in the FHIR resource or do it in seperate fields ?
  • proposal to put it in one field as in the EID
  • Issue 30: patient status during specimen collection
  • Medina never fills this in so field should be optional
  • on specimen resource there is a note field of type annotation where you can put any text
  • Issue 25: same issue as 33 but on different level (at diagnostic report level while issue 33 is on level)
  • move to "done"
  • Issue 47 : RequestCode
  • where to put the RequestCode : don't put it in the lab result
  • the protocol will not always match the request
  • the analysis order codes cannot be mapped 1-to-1 to lab codes
  • Issue 46 How to flag a receiver patient inversion event?
  • consensus: receiver should have a look at the identifier - if the patient is different then they need to remove the data connected to the original patient and have to link it to the data of the patient that is in the diagnostic report
  • move to "to be implemented" , there is a test plan available for this
  • Issue 45 : narrative
  • Medina will put narrative everywhere
  • Issue 19 unique identifier for non Belgian patients
  • citizens that don't have a INSZ/SSIN or BIS number : how can they be identified ?
  • possible solution: unique LAB RIZIV identifier + an identifier composed by the lab (the report id)
  • NamingSystem will be vendor specific
  • New issue: Create NamingSystem for BIS numbers

Next Meeting: on Tuesday Dec 21 4PM