# Is openEHR vrs/and FHIR a faulty conversation? **Category:** [open forum](https://openhealthhub.org/c/open-forum/9) **Created:** 2026-05-04 08:00 UTC **Views:** 34 **Replies:** 5 **URL:** https://openhealthhub.org/t/is-openehr-vrs-and-fhir-a-faulty-conversation/2982 --- ## Post #1 by @mayfield.g.kev ![22c71fe3-39c8-43ca-8932-a3ba15a28e6d|690x460](upload://crPjP3CUiXRmx5YZuOCAQXWpEtN.jpeg) I’ve been doing some work to better understand a genomics test result. (This is a bit of a brain dump - I am still trying to piece this together) The test in question is the *BCR::ABL major transcript* (likely used for monitoring leukaemia treatment). I’m working with a data structure that uses local codes in an HL7 v2 ORU_R01 format. My goal is to ingest this result into a Genomic Laboratory Information Management System (LIMS) and a genomic data repository, and make it available for sharing via a FHIR RESTful API. In my initial investigation, I came across this post: https://www.linkedin.com/feed/update/urn:li:activity:7455864766054608896/. Since the data will be shared, I’m inclined to incorporate standard clinical coding into the FHIR API. Local codes won’t mean much to external consumers, whereas SNOMED or LOINC codes would make the data more discoverable and interoperable. I haven’t yet been able to identify the appropriate SNOMED or LOINC codes (I’m not a clinical coder), but I’ve found several relevant LOINC codes and structures. These structures are quite similar to HL7 v2 ORU_R01, and I also started identifying potential SNOMED equivalents in the US edition. At this point, I’m a bit out of my depth, but I could see some patterns emerging, so I kept digging… which led me to this: openEHR – Laboratory analyte result https://ckm.openehr.org/ckm/archetypes/1013.1.2881 This archetype appears to align with both HL7 v2 and LOINC data structures (though not SNOMED, as that focuses on clinical terminology rather than structure). So I don’t yet have a definitive answer, but a direction is starting to take shape. What I’m seeing isn’t a straightforward “FHIR vs openEHR” situation. Instead, it’s a mix of related standards that aren’t directly linked. As a developer, I’m hesitant to create those mappings myself without clear guidance—but I do need them (as a minimum I could get away with LOINC/SNOMED codes). Right now, my understanding is: * openEHR provides a base archetype definition * LOINC "panels" offers more detailed implementation guidance * LOINC “panels” define coding and data mappings for HL7 v2 (and FHIR) * IHE LTW describes the clinical processes (work order and test management) - these use HL7 v2 (not FHIR) * IHE/HL7 EU describes API's for modern data sharing (this is FHIR based) * There doesn’t appear to be a UK-specific clinical coding approach here unless LOINC is adopted (while US SNOMED seems to include LOINC mappings). UK doesn't appear to produce clinical coding at this level * Ideally I'd like to clinical processes defined - without these engineered technical implementation tends to be on thin ice e.g. the HL7 v2 ORU_R01 will be sufficient as it is without any of the other standards and clinical coding would be a **'nice'** but uncessary addition. Given all this, I could potentially build a **local FHIR profile Laboratory Analyte Result** that maps between LOINC, HL7 v2, and openEHR—but I’m unsure whether that’s the right approach. It feels like a broader UK-level gap… but if so, who owns it? --- ## Post #2 by @JW148 [quote="mayfield.g.kev, post:1, topic:2982"] I’ve been doing some work to better understand a genomics test result. (This is a bit of a brain dump - I am still trying to piece this together) [/quote] You are not alone in trying to piece this together. From a GP clinical perspective I am trying to start by understanding at a very basic level what work flows would be involved. So, for example, for pharmacogenomics would the process start from the GP end as some kind of request for a lab test - for example to see if a patient was a poor / normal / rapid metaboliser for a given drug? What information would need to be assembled to support such a request and where and how would it go? Then what information would be sent back in the form of a result - and would the content of that depend on the role of the original requester? Would that content be coded and if so, how? --- ## Post #3 by @mayfield.g.kev My rough understanding is similar Genomic Orders A. A Genomic Test will be ordered B. The variants will be shared (by our data platform (not FDP) and/or via NHS England for GPs (also not FDP)) Decision Support C. GP System or app will call a Genomic Clinical Decision Support asking those drug questions (this either uses the data platforms above or is passed them). D. A list of therapeutic implications is returned (these structures may already be shared in the data platforms in B) --- ## Post #4 by @ian Hi John, Yes, PGX (Pharmcogenomics/genetics) is a little different from other clinical genomics disciplines, since there is no need to go into the depths of the original variants detected or detiled sequencing. Instead, one or more targetted tests are requested, either against a specific class of medications (common in the US), or against one or more genes implicated (seems more common in UK). Commercial ttin goften offers panel testingh gainst multiple genes and I suspect theis will become the norm. https://mantara.co/ This paper might be helpful ... https://informatics.bmj.com/content/bmjhci/32/1/e101163.full.pdf We worked with the team involved (also now at https://www.favahealth.com/) and GA4GH to develop a specific PGX archetype that would sit inside the \[openEHR Lab Analyte archetype\]( https://ckm.openehr.org/ckm/archetypes/1013.1.7066 ) to handle PGx-specific data, particularly, as you said the phenotype metaboliser status, which is the main (but not sole) criterion for decision support. Their proposed architecture envisages that this kind of genomic data is best held in a separate patient-centric datastore, instead of inside each EPR system, to allow the widest possible triggering of decision support. This is also the approach intended in a PGx project about to start in N. Ireland. What makes this all a little more complex is that any specific PGx test, may have only partial coverage, and so it wil be necessary to maintain a more encopassing, aggregating entity in the patient's record, a 'Genomic implication'. The openEHR JSON payload will look something like .. ```json { "minimal_pharmacogenetics_diagnostic_report": { "category": [ { "|value": "event", "|terminology": "openehr", "|code": "433" } ], "context": [ { "start_time": [ "2026-02-10T12:45:36.067Z" ], "setting": [ { "|terminology": "openehr", "|code": "238", "|value": "other care" } ] } ], "pharmacogenetic_laboratory_test": [ { "test_name": [ { "|value": "Gene product metabolic activity interpretation", "|code": "51971-0", "|terminology": "LOINC" } ], "clinical_information_provided": [ "Stroke - may need anticoagulation therapy" ], "laboratory_result": [ { "analyte_name": [ { "|code": "51971-0", "|terminology": "LOINC", "|value": "Gene product metabolic activity interpretation" } ], "pharmacogenetic_test_result": [ { "gene_symbol": [ { "|terminology": "http://www.genenames.org", "|value": "VKORC1", "|code": "HGNC:2623" } ], "diplotype": [ "VKORC1 rs9923231 C/T" ], "phenotype": [ { "|terminology": "SNOMED-CT", "|code": "3381000181101", "|value": "Increased function" } ], "overall_activity_score": [ { "|unit": "1", "|magnitude": 1.6 } ] }, { "gene_symbol": [ { "|code": "HGNC:2623", "|terminology": "http://www.genenames.org", "|value": "CYP2C19" } ], "diplotype": [ { "|code": "638797", "|value": "CYP2C19*1/*2", "|terminology": "ClinVar" } ] } ] } ], "time": [ "2026-02-10T12:45:36.069Z" ], "test_method": [ "ACME analyser - PGX panel" ], "language": [ { "|code": "en", "|terminology": "ISO_639-1" } ], "encoding": [ { "|code": "UTF-8", "|terminology": "IANA_character-sets" } ] } ], "language": [ { "|terminology": "ISO_639-1", "|code": "en" } ], "territory": [ { "|code": "GB", "|terminology": "ISO_3166-1" } ], "composer": [ { "|name": "DJ" } ], "_uid": [ "944cbba1-bf90-4c21-921a-056b8083c02a::com.freshehr.ehrbase::1" ] } } ``` but it is also well aligned with the FHIR Genomics Report IG. In the research project above, the CDSS rules were handled by by an NHS-owned PGx rules engine using the CPIC rules, then 'piped' into the GP system prescribing support by FDB, but just at an integration level, they did not handlle the CPIC rules. They have the capacity to do so, and this was a 'strategic decision' --- ## Post #5 by @mayfield.g.kev @ian In an ideal world, we should probably sit down together and simplify some of this language so we’re describing the same concepts more clearly. I do agree with what you’ve said. I’m starting to see a much clearer distinction at the data/platform level between: 1. What GPs and consultants need (traditional healthcare systems/EHR workflows) 2. What specialist genomic consultants and bioinformatics teams need (life science / genomic data platforms) I’m still not fully clear on the workflows themselves. As usual, I’m trying to reverse engineer what clinicians are actually doing in practice. So far, my understanding around Laboratory Analyte Results is something like: 1. A consultant (e.g. oncology) requests testing — for lung cancer this may start with radiology and then, where appropriate, a genomic test such as ctDNA. 2. Based on the [genomic report](https://nw-gmsa.github.io/Questionnaire-GenomicTestReport.html#domain-archetype) results, the consultant may decide on a therapeutic intervention. 3. The intervention is then monitored through a series of follow-up tests, with results captured as [Laboratory Analyte Results](https://nw-gmsa.github.io/StructureDefinition-LaboratoryAnalyteResult.html). Another workflow I’m becoming aware of is: 1. A GP or consultant orders whole genome sequencing because they suspect sensitivity or adverse response to certain drugs. 2. Results are returned in a [genomic report](https://nw-gmsa.github.io/Questionnaire-GenomicTestReport.html#domain-archetype), including variants and therapeutic implications. 3. The GP then records prescribing implications in the EHR (e.g. adverse drug interaction or pharmacogenomic guidance). Step 2 appears to include a form of Genomic Clinical Decision Support. Technically, this may involve AI/decision engines and could potentially be delivered as a service layer — e.g. variants + drug codes in, therapeutic implications out. Step 3 is an example of the two different views - specialist consultants are saying Therapeutic Implications and the GP/Consultant are recording [Allergy/Intolerance](https://build.fhir.org/ig/HL7/fhir-ips/en/Structure-of-the-International-Patient-Summary.html#allergies-and-intolerances) DISCLAIMER - I am not a clinician and so the workflows I've described could be wrong. --- ## Post #6 by @mayfield.g.kev FFS :) Just read the article/paper -> another workflow (elements of the two above) 1. A GP orders drug sensitivity test (e.g. ‘CYP2C19 poor metaboliser’) 2. Results **(and also shared via an API)** are returned in a [genomic report](https://nw-gmsa.github.io/Questionnaire-GenomicTestReport.html#domain-archetype), including variants, therapeutic implications **and laboratory analyte result**. **(Potentially this will also be shared via Greater Manchester Care Record - this only includes cancer test genomic results at present)** 3. The GP then records prescribing implications in the EHR (e.g. adverse drug interaction or pharmacogenomic guidance). Difference between this and the article/paper is the updating of the GP record is done by GP (GP EHR) as it's a clinical decision to do this (I'm not sure the therapeutic is an approved device - so it may be safer to not add these directly to a GP record). p.s. On the semantic comment in the article - our Laboratory Analyte Result is a HL7 v2 structure (not FHIR or openEHR), have noticed this appears to be defined only in LOINC (structure and coding). I probably need SNOMED concepts for the test result, test result detail is probably still LOINC. --- **Canonical:** https://openhealthhub.org/t/is-openehr-vrs-and-fhir-a-faulty-conversation/2982 **Original content:** https://openhealthhub.org/t/is-openehr-vrs-and-fhir-a-faulty-conversation/2982