Proposal from ZIB LaboratoryResults in FHIR R4

[Ashwin-nictiz]

LaboratoryResult is FHIR Observation where each LaboratoryTest is linked to Observation.hasMember but is otherwise an independent FHIR Observation.

Every RelatedResult is linked to Observation.derivedFrom, even as a stand-alone Observation. Furthermore, both types [battery/panel/cluster vs single result] FHIR Observation have proprietary connections to Patient (FHIR Patient), Performer (FHIR PractitionerRole of Organization) and Sample (FHIR Specimen).

Bottlenecks in the zib:

InterpretationMethodCode - ZIB-1292 cannot be mapped in V3/CDA/FHIR, never been asked for from the supplier

Requester- ZIB-1269 - cannot be mapped without other information from the application (id, status, application code(s), date, ...). We skip this problem a bit in the zib layer but expect to make it (more) implementable via use cases on the nl-core - process for processing use cases on nl-core is not well thought out yet

Specimen/derived specimen for this we have 2 profiles in mind as we also had in STU3 where we imagine that a Laboratory Result could be on Blood and a Laboratory Test on Serum, where Serum has a relationship to Blood. However, the ZIB only knows Monster on Laboratory Results and not on Laboratory Test

We will not continue the FHIR DiagnosticReport that we still had in STU3 in R4 because the purpose we had with it then doesn't seem to be well covered by the ZIB. If needed, it can always be added

For reference, we have looked at, among other things, the scope description of FHIR R4 Observation and DiagnosticReport, the examples mentioned (Tab Example) and the HL7 IPS

[pieter-edelman-nictiz]

LaboratoryResult is FHIR Observation where each LaboratoryTest is linked to Observation.hasMember but is otherwise an independent FHIR Observation.

There are quite a few unresolved questions here:

• If there's just a single LaboratoryTest, does that mean there're still separate LaboratoryResult and LaboratoryTest instances? Or is it possible to fold them into a single resource in this case?
• If the former model is adopted, wouldn't it be wise to make two separate profiles for LaboratoryTestResult and LaboratoryTest?
• Observaton.code is required, but NL-CM:13.1.4 | PanelOrBattery is 0..1. What to do if this is absent?

[pieter-edelman-nictiz]

Every RelatedResult is linked to Observation.derivedFrom

A RelatedResult could be an observation that this observation is derived from, but Observation.derivedFrom seems to be too narrow. The Observation spec also mentions the core extension Observation-sequelTo which also partially seems to cover the description of RelatedResult. However, a general "related result" doesn't seem to exist.

Maybe the zib concept could be split over these two concepts plus a general fallback extension? The sending system would then be encouraged to register a more detailed relationship but can still handle the zib concept.

[pieter-edelman-nictiz]

Specimen/derived specimen for this we have 2 profiles in mind as we also had in STU3 where we imagine that a Laboratory Result could be on Blood and a Laboratory Test on Serum, where Serum has a relationship to Blood. However, the ZIB only knows Monster on Laboratory Results and not on Laboratory Test

This description is not really clear. There are three profiles in STU3, not two. Specifically for the Microorganism concept a Substance profile seems appropriate, but why are two Specimen profiles needed?

The distinction between blood and serum and the binding on different parts of the result sound like they stem from a specific use case. This seems best fitted for the nl-core layer, if this use case is clearly defined.

[pieter-edelman-nictiz]

During a meeting, the following solution has been proposed:

• A profile will be created for LaboratoryTestResult and it will include the LaboratoryTest.
• When there's just a single LaboratoryTest, this profile can be used as-is.
• When there are multiple LaboratoryTests, instances of this profile will be used for the grouping Observation and for each individual LaboratoryTest. The LaboratoryTest instances will duplicate the information from the LaboratoryTestResult root (note, request, etc.), except for PanelOrBattery, ResultStatus(?).
• It is unclear if a single LaboratoryTestResult with multiple LaboratoryTests always represents a panel or battery. If so, PanelOrBattery should probably always be present when there are multiple LaboratoryTests. A zib ticket is be created to answer this question.

This model is better in line with the IPS and provides relatively straightforward guidance to implements.

Regarding RelatedResult: .derivedFrom is probably too narrow, but the combination with .sequelTo probably covers all use cases, so we'll map to both. A zib ticket is created to ask if this concept can be described more specifically.

[pieter-edelman-nictiz]

Further meeting conclusions:

• The zib concept Specimen contains all details regarding the specimen on which the test was carried out. This could be a substance, but also a microorganism isolated from that substance. In FHIR the Specimen resource can have just one .type, so if there is a microorganism there need to be two instances, one for the substance and one for the microorganism. The latter needs to refer to the former using .parent. This will result in two profiles, with the proper ValueSet bound on .type. Information is probably duplicated in these two instances. Note: in theory it is possible to have a microorganism without a substance.
• The Specimen is referred from the zib root, not from each individual test. This seems to align with previous models. However, wouldn't be there an expectation to refer derived Specimens from individual tests? And when using a panel, do individual tests need to reference the Specimen as well?
  • For example in a antibiotics resistence test, each individual test is carried out on the isolate, not on the blood where it came from. Created a zib ticket to address this issue.
• When the test is carried out on material collected from a device (e.g. catheter tip), the Oberservation.subject would probably still be the patient. Observation.focus might be the device.
• The Substance resource that we had in STU3 is probably not needed.
• The SpecimenSource concept is modeled as a string, but in FHIR it expected to be a reference. We probably need to add guidance that this would normally be a contained Device resource carrying just the string. Created a zib ticket to verify that this is indeed a MedicalDevice.

[pieter-edelman-nictiz]

Quick drawing of how the profiles might relate to each other:

[pieter-edelman-nictiz]

Update: a LaboratoryTestResult with more than one LaboratoryTest is considered to be a panel/battery, and concept PanelOrBattery should be present in this case.

[pieter-edelman-nictiz]

Based on the answer from the zib centre, the situation might be better represented using this model:

The ...SpecimenAsMaterial and ...SpecimenAsMicroorgansims could be the same profile though, with a binding of both ValueSets on Specimen.type.

[pieter-edelman-nictiz]

One more open issue: https://bits.nictiz.nl/browse/ZIB-1701

[pieter-edelman-nictiz]

And one more: https://bits.nictiz.nl/browse/ZIB-1703

[pieter-edelman-nictiz]

And this one: https://bits.nictiz.nl/browse/ZIB-1706

[pieter-edelman-nictiz]

One more open issue: https://bits.nictiz.nl/browse/ZIB-1701

Discussion regarding this issue is still ongoing. The zib states that the TimeInterval could be defined as a duration combined with a start date or end date. Proposals to address this:

• Add guidance that this should be ignored and that this should be recalculated to Period.
• Combine Duration with .collection.collectedDateTime and add guidance that this should be interpreted as start + duration. This doesn't address end + duration.
• Redefine .collection.collectedPeriod that the absence of .end plus the presence of .collection.duration in this particular case means that the Period is not ongoing but that it should be interpreted as start + duration, and that the absence of .start plus the presence of .collection.duration in this particular case means that the start is not unknown.
• Use extensions.

[ogieling]

The laboratory profiles need to contain a requirement for the 'laboratory' code as a category to differentiate laboratory observations from other observations. This had already been added to #265.

[niekvangalen]

Please take notion of this BITS ticket for the development of this zib: https://bits.nictiz.nl/browse/MM-1103

[pieter-edelman-nictiz]

Er is nog een klein issue met de huidige implementatie: https://bits.nictiz.nl/browse/MM-3647