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

From Health Level 7 Belgium Wiki
(Created page with "===== Attendees ===== * Dr Alain Derom * Bart Decuypere * Frederik Lenaerts * Hans De Keersmaecker * Jean-Michel Polfiet * Jos Bellen * Karlien Erauw * Kristof Jaubin...")
 
 
(3 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
* Dr Alain Derom   
 
* Dr Alain Derom   
 
* Bart Decuypere  
 
* Bart Decuypere  
−
* Frederik Lenaerts
+
* Frederik De Kegel
 +
* Filip Migom
 
* Hans De Keersmaecker  
 
* Hans De Keersmaecker  
 
* Jean-Michel Polfiet  
 
* Jean-Michel Polfiet  
−
* Jos Bellen
+
* Joost Van Averbeke
 +
* José Costa Teixeira
 
* Karlien Erauw  
 
* Karlien Erauw  
 
* Kristof Jaubin  
 
* Kristof Jaubin  
 +
* Lotte Adriaensen
 +
* Nico Vannieuwenhuyze
 
* Olivier Lothaire
 
* Olivier Lothaire
−
* Philippe Cauchie (let at 4.30PM)
+
* Philippe Cauchie  
−
* Theo Schumacher  
+
* Theo Schumacher (arrived late)
−
* Thibault Mahieu
+
* Tom Fiers
 
* Tom Tollenaere  
 
* Tom Tollenaere  
−
* Richard Francken
 
−
* Stefan Waegemans
 
−
* Werner De Mulder
 
  
 
===== Excused/Not present =====  
 
===== Excused/Not present =====  
Line 21: Line 22:
 
* Benny Verhamme  
 
* Benny Verhamme  
 
* Frédéric Istace  
 
* Frédéric Istace  
−
* Frederik De Kegel
+
* Frederik Lenaerts
−
* Joost Van Averbeke
+
* Jos Bellen
−
* José Costa Teixeira
 
 
* Mieke Buckinx
 
* Mieke Buckinx
−
* Nico Vannieuwenhuyze
 
 
* Nick Hermans  
 
* Nick Hermans  
 
* Paul Neyens
 
* Paul Neyens
 
* Peter Laridon  
 
* Peter Laridon  
 
* Robert Nicolas
 
* Robert Nicolas
−
* Tom Fiers
+
* Thibault Mahieu
 
* Toon Schiemsky
 
* Toon Schiemsky
−
 
+
* Richard Francken
 +
* Stefan Waegemans
 +
* Werner De Mulder
  
 
===== Agenda =====
 
===== Agenda =====
Line 39: Line 40:
 
===== 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 33 : DiagnosticReport.code : coding same as composition type
+
* CHU Charleroi did a succesfull import of a FHIR message, decoding will start
−
::* Set both to "laboratory report"?
+
* Visualisation tool is public and [https://vizapp.icure.dev/ URL is available:] drag and drop of FHIR file is possible - uncheck validation of file button as there is a bug
−
::* In examples we find e.g. Hematology studies, but our reports are typically more extensive than only hematology
+
* New issue from last week #issue 59: Create NamingSystem for BIS numbers
−
::* subject of lab report will be in the subject f.e. hematology will appear as chapter in lab report
+
::* patient identification: checked with eHealth platform
−
::* proposal: not to put the type at this level in the lab report, just call it laboratory studies
+
::* art 8 from eHealth platform law and mapped with the BCSS law: all info passing the eHealth platform must use the NISS info from patient, the NISS is identifier at the nat'l security, can be RN number if this exists ; if not existing in RN then BIS number is created. [https://www.ehealth.fgov.be/nl/egezondheid/beroepsbeoefenaars-in-de-gezondheidszorg/ehealthcreabis See more here]
−
::* Bart looked at LOINC codes (11502-2, not coded as RETAM yet at federal level)
+
::* no need to create a new Naming System as NISS can be RN or BIS number
−
::* Philippe proposes to test this first (later today), be careful that an hematology study comes from another service
+
::* BIS can be created by Fedasil or nat'l scty or GP
−
::* let's allow it for now and await the tests
+
::* will there be FHIR messages without a NIS number ? There are now data in labs without NIS number. If there is no NIS then data are not shared
−
* Issue 23: How to encode comments
+
::::* patient data are sent not by eHealth infrastructure if there is not a NIS number
−
::* We need to specify how to deal with different kinds of comments. Here an inventory and suggestion of process:
+
::::* Can we send a FHIR message without NISS number ? It is possible if sent the eHealthBox to the GP. Lab will use own identification from his system.  
−
::::* a. Comment on a result of analysis - may be done .note to the result? But there are different cases possible:
+
::* issue 59 can be closed as not necessary: the foreseen namingsystem https://www.ehealth.fgov.be/standards/fhir/NamingSystem/ssin can be used as well
−
::::::* 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)
+
* New issue : how to deal with comments - new issue encountered, not in github yet
−
::::* b. Comment regd. reference values (e.g. age-specifics) – in .text to the reference values?
+
::* protocol 49: series of tests that are not accredited, some of them having comments. the only way to encode this is
−
::::* 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?
+
::* text "analyse gedekt door accreditatie" comes with every analysis
−
::::* 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?
+
::* some tests have biological relevance, some have not, they are mixed. Visualisation tool only shows 1st comment currently.  
−
::::* 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?
+
::* does it make sense to mix info like this ?
−
::::* f. Comments regarding administrative issue, e.g. missing information like gender, DOB. Today we use dummy test codes. Allowed? If not, then how?
+
::* Belac requires to put info somewhere in a readable way. Currently there is no other way to put the comments but report becomes unreadable
−
::::* 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.
+
::* make distinction b/w technically/clinically relevant & administrative/non-clinical comment
−
::::* Do we want/need to agree on standards for the above? Or allwo every lab to do their own way?
+
::::* if we make extension it is at observation level not at observation interpretation level - seems that we need an extension, José will check with int'l FHIR lab group and will come up with a solution
−
::* there are 3 LOINC codes availabel 55752-0, 94330-8 and 86468-6
+
::* issue 64 is newly created in github
−
::* there is also a note field available for comments
+
 
−
::* on analysis level there are also comments  
+
* Additional new issue with comments: comments having referenced values/referenced range/interval and alpha numeric values
−
::* Issue can be moved to "for implementation" status
+
::* see protocol 52
−
* Issue 31 given name (patient & practitioner)
+
::* visualisation tool does not show these comments yet
−
::* when a person has more than one given namen
+
::* comment that goes with referenced range f.e. normal values for diabetics/normal values for non-diabetics
−
::* do it in one field in the FHIR resource or do it in seperate fields ?
+
::::* this comment could be added to observation level referring to referenced range
−
::* proposal to put it in one field as in the EID
+
::* issue 65 is newly created in github
−
* Issue 30: patient status during specimen collection
+
::* see complex [https://drive.google.com/file/d/1JjxowJW_5TTw0RF3QJdoKtSvS_mOEuIm/view?usp=sharing example here]
−
::* Medina never fills this in so field should be optional
+
::* clinical biologists feel that several tests are necessary to see how it will look like
−
::* on specimen resource there is a note field of type annotation where you can put any text
+
::* José to come up with a proposal to put this info, we might need an extension
−
* Issue 25: same issue as 33 but on different level (at diagnostic report level while issue 33 is on level)
+
::* check with Netherlands: https://zibs.nl/wiki/LaboratoryTestResult-v5.0(2021EN)  
−
::* move to "done"
+
 
−
* Issue 47 : RequestCode
+
* Issue 21: copy physicians
−
::* where to put the RequestCode : don't put it in the lab result
+
::* reports not only indicate physician who ordered the lab tests, but may list other physicians in cc of lab results. We cannot find who to encode those in the FHIR message (i.e. we do not know where to put those). Do we not indicate this? Or if we do, where and how?
−
::* the protocol will not always match the request
+
::* POC group proposes to put comment on service request/order level (plain text: copy result to GP...)
−
::* the analysis order codes cannot be mapped 1-to-1 to lab codes
+
::* order is not digitised yet so is more for the future, there is no BeServiceRequest yet, note field at FHIR R4 service request profile
−
* 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
+
* Issue 24: results in different units
−
::* move to "to be implemented" , there is a test plan available for this
+
::* it is a non-issue: labs will results in the units in which they have pinned the result
−
* Issue 45 : narrative
+
::* it can be closed
−
::* Medina will put narrative everywhere
+
::* receiver can receive different loinc codes
−
* Issue 19 unique identifier for non Belgian patients
+
 
−
::* citizens that don't have a INSZ/SSIN or BIS number : how can they be identified ?
+
* Progress in POC is good, no major issues are coming
−
::* 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 Jan 4 4PM
+
'''Next Meeting:''' on Tuesday Jan 11 4PM

Latest revision as of 16:12, 21 December 2021

Attendees
  • Dr Alain Derom
  • Bart Decuypere
  • Frederik De Kegel
  • Filip Migom
  • Hans De Keersmaecker
  • Jean-Michel Polfiet
  • Joost Van Averbeke
  • José Costa Teixeira
  • Karlien Erauw
  • Kristof Jaubin
  • Lotte Adriaensen
  • Nico Vannieuwenhuyze
  • Olivier Lothaire
  • Philippe Cauchie
  • Theo Schumacher (arrived late)
  • Tom Fiers
  • Tom Tollenaere
Excused/Not present
  • Alexis Van Zeveren
  • Benny Verhamme
  • Frédéric Istace
  • Frederik Lenaerts
  • Jos Bellen
  • Mieke Buckinx
  • Nick Hermans
  • Paul Neyens
  • Peter Laridon
  • Robert Nicolas
  • Thibault Mahieu
  • Toon Schiemsky
  • Richard Francken
  • Stefan Waegemans
  • Werner De Mulder
Agenda
  • Rework on issues resulted from the pilot phase, issues #48 and #50 having priority
Minutes
  • Up-to-date list of issues can be consulted here
  • CHU Charleroi did a succesfull import of a FHIR message, decoding will start
  • Visualisation tool is public and URL is available: drag and drop of FHIR file is possible - uncheck validation of file button as there is a bug
  • New issue from last week #issue 59: Create NamingSystem for BIS numbers
  • patient identification: checked with eHealth platform
  • art 8 from eHealth platform law and mapped with the BCSS law: all info passing the eHealth platform must use the NISS info from patient, the NISS is identifier at the nat'l security, can be RN number if this exists ; if not existing in RN then BIS number is created. See more here
  • no need to create a new Naming System as NISS can be RN or BIS number
  • BIS can be created by Fedasil or nat'l scty or GP
  • will there be FHIR messages without a NIS number ? There are now data in labs without NIS number. If there is no NIS then data are not shared
  • patient data are sent not by eHealth infrastructure if there is not a NIS number
  • Can we send a FHIR message without NISS number ? It is possible if sent the eHealthBox to the GP. Lab will use own identification from his system.
  • New issue : how to deal with comments - new issue encountered, not in github yet
  • protocol 49: series of tests that are not accredited, some of them having comments. the only way to encode this is
  • text "analyse gedekt door accreditatie" comes with every analysis
  • some tests have biological relevance, some have not, they are mixed. Visualisation tool only shows 1st comment currently.
  • does it make sense to mix info like this ?
  • Belac requires to put info somewhere in a readable way. Currently there is no other way to put the comments but report becomes unreadable
  • make distinction b/w technically/clinically relevant & administrative/non-clinical comment
  • if we make extension it is at observation level not at observation interpretation level - seems that we need an extension, José will check with int'l FHIR lab group and will come up with a solution
  • issue 64 is newly created in github
  • Additional new issue with comments: comments having referenced values/referenced range/interval and alpha numeric values
  • see protocol 52
  • visualisation tool does not show these comments yet
  • comment that goes with referenced range f.e. normal values for diabetics/normal values for non-diabetics
  • this comment could be added to observation level referring to referenced range
  • Issue 21: copy physicians
  • reports not only indicate physician who ordered the lab tests, but may list other physicians in cc of lab results. We cannot find who to encode those in the FHIR message (i.e. we do not know where to put those). Do we not indicate this? Or if we do, where and how?
  • POC group proposes to put comment on service request/order level (plain text: copy result to GP...)
  • order is not digitised yet so is more for the future, there is no BeServiceRequest yet, note field at FHIR R4 service request profile
  • Issue 24: results in different units
  • it is a non-issue: labs will results in the units in which they have pinned the result
  • it can be closed
  • receiver can receive different loinc codes
  • Progress in POC is good, no major issues are coming

Next Meeting: on Tuesday Jan 11 4PM

Retrieved from "https://wiki.hl7belgium.org/index.php?title=Minutes_-_Referral_WG_2021-12-21&oldid=1348"