Stream: implementers
Topic: pulmonary/lung function testing to FHIR
Jan Scheer (Sep 22 2020 at 08:10):
Hello everyone,
lufu_fhir_1.jpeg lufu_fhir_2.jpeg I am currently working on mapping pulmonary/lung function testing (PFT/LFT) data to FHIR ressurces for the MIRACUM project in Germany.
we have been discussing this mapping in a MIRACUM working group and I would like to reach out to you for some support getting it done in terms of best practice.
First of all, data for a lung function testing can contain values for the "sections" spirometry, bodyplethysmography (bodypl.), transfer-factor (diffusion) and more; these are the major sections. spirometry values can be
available from a single examination, or combined examination with a first (before bronchodilation) and
second (after bronchodilation) set of measured parameters.
We agreed to encapsulate a LFT in a DiagnosticReport, but we are not sure how to best divide the measured values among these sections. We came up with the following options:
1) Using Observations for each LFT parameter (directly linked to the DiagnosticReport). Link Observations with a Procedure (coded either in LOINC or SNOMED CT for the section, e.g. "Spirometry (procedure) | SCTID: 127783003").
2) Using Observations with components. Coding an observation directly in LOINC or SNOMED CT for the section, e.g. "Spirometry (procedure) | SCTID: 127783003", and have the measured values/parameters in the "components".
(We are aware of the detailed notes and recommendations at the FHIR-Observation website for when to use components or not. A single value may be interpreted without the others, but some values may also depend and interrelate to each other)
3) we also considered to use 2 levels of Observations using the hasMember-property, e.g. having Observations for the LFT sections (at 1. level) and use the hasMember property to create observations for the LFT parameters/values (at 2. level).
As additional information, there is a LOINC mapping for the PFT/LFT panels available (https://loinc.org/81458-2/).
We use many of the LOINC codes for the actual parameter coding (in observation / component).
We have found though that some codes do not reflect our understanding or are not complete for our purpose, so we only use them where applicable.
Any comments or support on which approach to choose over the other is highly appreciated. We had several discussions, decided for 2) a last,
and it would be great to have your feedback.
Thanks
Jan
Lloyd McKenzie (Sep 22 2020 at 13:05):
@Eric Haas @Rob Hausam
Rob Hausam (Sep 22 2020 at 17:22):
@Jan Scheer This looks like a great case to sort through and work out the details on to determine which option (or options) would be the best practice. Would it be possible for you to share some example reports (even if they are in German)?
Jan Scheer (Sep 23 2020 at 06:31):
Hi @Rob Hausam. On this page are some example reports as they are produced (menu on the left e.g. for "obstruction" shows the case with pre- and post-values): http://lungfunction.net/interpretation/normal-findings.htm. At some point I also wasn't sure if this sort of "mapping these sections" does make sense at all. And wether the very first (and simplest) approach could be just enough. Especially in terms of using the data later on for analytics.
Last updated: Apr 12 2022 at 19:14 UTC
