Last Tuesday in clinic, I watched a patient ask a question that sounded simple and landed like a brick: “So if my cancer panel is already in the chart, why do I still have to bring the printout?” The answer sat somewhere between the EHR, the molecular pathology lab, and three different human workarounds. I knew the result was in the system. I also knew it was effectively invisible where decisions were made.
Precision medicine is exposing a gap in modern EHR design: omic data can be exchanged, but not always meaningfully used at the bedside. The failure is workflow, not transport, and hospitals that treat genomic integration as a data-format problem will keep pushing clinicians back to manual reconciliation, duplicated ordering, and delayed treatment decisions.
I used to think EHR interoperability was mostly a standards problem. If a system could speak FHIR, expose an API, and accept structured data, I assumed the rest would follow. Then I sat through enough genomics rollouts to see the real issue: the data can arrive cleanly and still fail at the point that matters, the moment a clinician needs to act on it.
That is where precision medicine is exposing the limits of today’s health IT stack. A somatic variant, a pharmacogenomic phenotype, a transcriptomics readout, or a multi-omic report is not just another lab value. It carries context, provenance, interpretation date, versioning, and sometimes uncertainty that changes with time. The API may be happy. The clinician is not.
For my own work, the most telling failure mode is not an outright outage. It is the quiet kind. I see a result imported into the EHR as a PDF attachment, a discrete field without context, or a genomic flag buried three clicks deep in a specialty tab. The oncologist has to hunt. The pharmacist has to reconcile. The primary care clinician may never see it. That is not interoperability in the clinical sense, even when the interface logs say success.
For readers who want my broader physician perspective and clinical background, I keep my role details here: Dr. Sina Bari, MD, physician perspective. For a related view on how I frame AI governance and clinical utility across care settings, see sinabarimd.com.
The real breakdown is workflow, not transport
Hospitals love to say they have “integrated genomics” once the feeds start flowing. But the workflow burden usually moves downstream to the human beings who must make sense of the feed. The result is familiar: extra inbox messages, duplicate chart review, repeated confirmations, and a growing dependence on local champions who know where the hidden tab lives.
This is why the FHIR Genomics conversation matters, but only up to a point. In the 2026 JAMIA Open assessment of the FHIR Genomics standard for somatic testing reports, the authors concluded that the standard still has gaps for representing real-world oncology reports, especially when the report structure and interpretive complexity exceed the model’s assumptions. That matters because the problem is not whether a report can be encoded. It is whether the encoded report can survive the mess of actual clinical practice.
I have seen a genomic test come back “integrated” while the clinically decisive interpretation lived in a scanned attachment. I have also seen a pharmacist catch a DPYD-related issue only because she opened the original report, not the structured EHR summary. In the 2026 JAPhA study on DPYD testing implementation in oncology clinics, patient and provider perspectives showed the operational friction was real, with implementation depending heavily on local workflow support and team coordination rather than the mere presence of a test result in the record. That is the part vendors tend to miss during the demo.
When I evaluate an AI or interoperability vendor, my first question is rarely about accuracy. It is: where does this land in the work? If it lands as another alert, another PDF, or another dashboard that nobody owns, it has not solved anything. It has redistributed friction.
Why omic data are different from ordinary lab data
Omic data are inherently more volatile than a potassium level or a creatinine. Some genomic findings are durable, but their clinical meaning changes with guidelines, tumor evolution, and therapy sequence. Other omic data are snapshot-dependent, noisy, and highly context-sensitive. That means a static API representation can become stale while still looking technically valid.
The literature is already pointing in this direction. In 2025, authors describing molecular tumor board visualization tools in BMC Medical Informatics and Decision Making emphasized that oncology teams need more than raw data exchange, they need interpretation layers that support collaborative decisions. In practice, that means timelines, variant curation history, matched therapies, prior lines of treatment, and the ability to understand what changed since last week.
I used to assume that once a structured result was in the EHR, clinicians would naturally adapt. Now I think the opposite is often true. If the workflow does not change with the data model, the clinicians adapt by ignoring the data model. That is the hidden failure, and it is very human.
The same pattern appears in pharmacogenomics. In the 2026 BMC Pharmacology & Toxicology usability study of Epic’s Genomic-Indicators, the authors found that usability, not just availability, determined whether pharmacogenomic CDS fit into clinical work. A system can be technically elegant and still fail because it asks too much of the user at the wrong moment. I have lived that reality in medication review sessions where the “actionable” recommendation arrives after the prescription workflow is already closed.
What I would not do
I would not call this an interoperability success simply because a FHIR endpoint exists. I would not approve a rollout that stores omic data as passive text blobs and claims victory. I would not place the burden of interpretation on the clinician without a clear ownership model, a versioning strategy, and a specific answer to who updates the interpretation when the underlying evidence changes.
I would also not buy the argument that “the API-first stack will sort it out later.” Later is where safety problems hide. In my experience, if the first release does not make the right action easy, the second release usually inherits the bad workflow and decorates it with better terminology.
The regulatory lens matters here. If an AI or CDS layer is making or shaping clinical recommendations, hospital leaders should ask whether it behaves more like a software feature, a clinical decision support tool, or a regulated medical device pathway. FDA 510(k), De Novo, and PMA are not academic labels. They define evidence expectations, change management, and liability posture. NIST’s AI Risk Management Framework and WHO guidance on AI in health are useful because they force the board-level question: what is the system allowed to do, and what must remain under human review?
That question matters even more when AI is layered onto omic data. A model that flags a variant-to-therapy relationship can be useful, but if it is not tethered to provenance and current guideline status, it can mislead with great confidence and perfect typography.
How to build for bedside reality
Hospitals need a different design principle. Do not start with “Can the system ingest omics?” Start with “Can the right person act on it in under 30 seconds, with enough context to trust the action?” That means role-specific views, provenance visible at the point of use, effective dates, and a clean path from result to recommendation to order set to documentation.
I would also insist on operational ownership. Who curates variant updates? Who retires outdated interpretations? Who reconciles a reclassified result? Who monitors false-positive alerts and workflow leakage? If nobody owns these questions, the EHR becomes a parking lot for expensive ambiguity.
The broader research base supports this operational framing. In the 2026 JAMIA article on cross-institutional priorities in data-driven biomedical research, the authors emphasized that infrastructure decisions have to serve real use cases, not abstract elegance. A similar message appears in the 2026 International Journal of Medical Informatics review on human-in-the-loop AI in healthcare, which highlighted implementation challenges, including the need for clinician oversight and workflow fit. The number that matters most is rarely model AUC. It is the time from result to correct decision.
That is the metric I care about in my own practice. Not “Did the interface work?” Did the patient get the right drug, the right referral, or the right follow-up without three people digging through the chart?
What changed in my thinking
I used to think genomics would expose the shortcomings of legacy EHRs. That is only partly true. What it has really exposed is how much modern health IT optimizes for data carriage and under-optimizes for clinical action. The record can be complete and still be unusable. The pipeline can be modern and still force clinicians into paper-era behavior.
That realization changed how I judge AI and interoperability claims. I no longer ask whether the data moved. I ask whether the workflow moved with it. I ask whether the patient’s care team can see the answer, trust the answer, and use the answer before the next decision closes.
Three weeks after that clinic visit, the same patient came back with the test results printed out, highlighted, and stapled to a referral packet. She looked tired and said, “I just brought it myself because nobody seemed able to find it.” That line stayed with me. It was a patient describing our workflow failure more accurately than any vendor slide ever could.
The future of precision medicine in the EHR will not be decided by how many APIs we expose. It will be decided by whether a patient like hers can stop serving as the courier for her own data.
FAQ
Why does genomic data break EHR interoperability when other lab results do not?
Genomic and omic data carry interpretation, versioning, and context that routine labs usually do not require. A result can be technically stored and still be clinically incomplete if the interpretation is buried, stale, or disconnected from the treatment workflow.
What happens if a hospital stores pharmacogenomic results as a PDF in the chart?
Clinicians usually lose speed, consistency, and visibility. The result may exist, but it becomes dependent on someone remembering where the file lives, which makes decision support weaker and medication review more manual.
How should hospitals handle updated variant interpretations over time?
They need an ownership model, not just an interface. Someone must be responsible for reclassification, version tracking, and notifying the right care team when a prior interpretation changes.
What is Dr. Sina Bari’s approach to AI and genomics integration in the EHR?
I start with workflow, not model output. If the result does not reach the right clinician in a usable form, with provenance and actionability visible at the point of care, I do not count it as a successful deployment.
Can FHIR Genomics solve the clinical problem by itself?
No. FHIR helps with transport and structure, but the clinical problem also includes usability, governance, update logic, and human adoption. The standard is necessary, but it is not sufficient.