Hi,
I’ve read the Genomics IG and looked at a number of examples provided by FHIR website.
According to the IG you can represent Panels as Observation [Grouper profile] with Panel memebers as part of hasMember in Grouper profile.
But if you look at FHIR Genomic Reporting guides you can express Variants using Observation Variant profile which also contains “components” (the components that are listed under the LOINC panel, image below).
I came across this LOINC panel as I was looking for appropriate code to use but I’m not too confident in whether my thinking is correct?
From what I picked up from IG and different examples…
So the build up of LOINC DNA Panel → FHIR structure would be as follows…
DNA Marker Result Panel code as Observation Grouper code (this would be the code of Result Panel)…
Have Observation Variant Profile and use DNA marker identified panel code as its code…
Use Components listed in Variant Profile (like dna change, amino acid change, etc → this are also listed in LOINC DNA Marker Identified Panel)
Have separate observation for each of the direct child of DNA marker results panel (51960-3)
ex. 53034-5 Allelic State, 48002-0 Genomic Source class, and so on
would the above method be correct?
Can I have step number 4 be included in the observation created in step 2 as a component (since allelic state, genomic source class are part of obx component)?
Most LOINC panels originated in the HL7 v2 world where there was no differentiation between the notions of “has member” and “has component”. Everything was transmitted as a message and so the notion of “these properties must stay together to be meaningful” vs. “these properties can be interpreted separately” wasn’t relevant.
With FHIR, where you can pass around individual resources by themselves, the difference matters. In a blood panel, it’s completely reasonable to have the red blood cell count in one Observation instance and the white blood cell count in a different one. Someone might well want to query one and not the other.
On the other hand, knowing the change type for a variation but not the change location or vice versa isn’t terribly helpful. You need a whole set of information together to understand what’s actually going on.
The genomics reporting IG represents best practice guidance about how to represent genomics information in FHIR. The organization of the data there supersedes the more generic information defined in the LOINC panel and provides explicit guidance about what components need to be present together to meaningfully share information.
If you have further questions about how to use the IG, I’d encourage you to raise them here: FHIR Community
So just to confirm my understanding (quoting below),
LOINC is the more general version and in HL7 v2 because everything was sent as a message they panels were required to group certain results to make sense.
With FHIR though, because resources can be displayed separately (“individual”) differentiation of
matters?
The reason for my questioning was because although FHIR Genomics IG gives guides and use case samples it made it hard to grasp information when laboratories have their own reporting styles.
Then I came across LOINC Panels (they were presented as a group of tests) and it just helped me understand better (of course with prior knowledge about FHIR and its resources).
But it got confusing when I tried to replicate LOINC Panel structure to FHIR (“you clearly explained the difference! thanks!”)
From the explanation above:
If FHIR Genomics structure changes depending on the use case or tests, it feels like FHIR is strongly coupled to a business flow (business flow here I mean lab tests) than v2?
It’s not so much that FHIR is coupled to a particular business flow as that it’s actually less coupled. Data can be passed around in a whole variety of contexts and you can’t count on information being passed together unless it’s managed as a single resource. Thus with FHIR, you need to package things correctly so that data is meaningful on its own. With v2, the packaging was driven by message type and you were always passing large swaths of data, so the package wasn’t as important.
The structure shouldn’t change based on the test - the same information should always go in the same slot. However, the information returned might vary based on the test (and on the lab), so not all the same information will necessarily always be present - even if talking about what’s essentially the same thing.
