Note: All ideas presented below are at the research and conceptual development stage. This is not an HL7 standard, is not part of the HL7 FHIR specification, and is not an official proposal from any organization. The article merely presents a perspective on system architecture, built on top of existing standards such as HL7 FHIR, Clinical Quality Language (CQL), and FHIR Clinical Practice Guidelines (CPG), and is not intended to replace those standards.
Over the weekend, I spent time re-reading materials on healthcare digital transformation, HL7 FHIR, Clinical Quality Language (CQL), FHIR Clinical Practice Guidelines (CPG), and the field of Computable Clinical Knowledge.
What occupied my thoughts the most was how we view electronic medical records.
Today, Electronic Medical Record (EMR) systems have evolved far beyond being mere data repositories. Many platforms have integrated functions such as Clinical Decision Support (CDS), quality measurement, process automation, and data interoperability. However, in many systems, clinical data and clinical knowledge are still managed as relatively separate components: data is stored in the medical record, while knowledge typically resides in rule engines, guideline engines, or separate applications.
From my perspective, the next major step in healthcare digital transformation is not just digitizing medical records or adding AI, but building systems in which clinical data can be understood by computers, directly combined with medical knowledge, and executed consistently.
This is also the direction the biomedical informatics community is pursuing through the transformation of clinical guidelines and medical knowledge from static documents into computable knowledge artifacts that can serve clinical decision support, quality measurement, process automation, and many other applications.
From Electronic Medical Record to Computable Medical Record
From that perspective, I am researching a concept that I temporarily call the Computable Medical Record (CMR).
This name is purely conceptual.
Based on my research, the Computable Medical Record is not currently a standardized term and is not an HL7 standard. It is simply my way of describing a potential direction for the evolution of electronic medical records.
If the EMR is primarily a place to manage and store clinical information, then the Computable Medical Record aims to organize data in a way that computers can directly understand, compute, and combine with computable knowledge artifacts.
In other words, clinical data and clinical knowledge no longer exist as two independent components but become a unified system.
Clinical Computation Model
To realize that idea, I am researching an architecture that I temporarily call the Clinical Computation Model (CCM).
In this view:
- The Computable Medical Record (CMR) is the system.
- The Clinical Computation Model (CCM) is the architecture behind that system.
CCM does not replace HL7 FHIR, Clinical Quality Language (CQL), FHIR Clinical Practice Guidelines (CPG), or existing standards.
On the contrary, the goal of CCM is to create a unified architecture in which medical data, professional knowledge, and care processes can work together.
CCM does not create a new standard. Instead, it leverages existing standards to connect data with medical knowledge, helping the entire system operate in a unified and consistent manner. In this view, CCM is an architectural layer that helps existing components coordinate more effectively, rather than replacing or competing with current standards.
Three Core Principles
1. Local-First Clinical Computing
Clinical data should be created, standardized, and processed at the point of origin.
Rather than viewing interoperability as the starting point, this architecture views interoperability as a natural result when systems all use structured data that adheres to common standards.
The goal is not just data exchange, but the sharing of computable data.
2. Deterministic Clinical Computation
In this architecture, the medical record is not just a place to store information but also an environment for executing clinical knowledge.
Business rules, CQL expressions, clinical guidelines, quality measures, and other clinical logic are all evaluated on the same standardized data model.
With the same input data and the same set of knowledge artifacts, the system always produces the same result.
This provides a foundation for many functions, including:
- Clinical Decision Support (CDS)
- Quality measurement
- Safety alerts
- Clinical data analysis
- Medical research
- Clinical guideline execution
All of these functions operate on the same data model, rather than each system having to interpret data in its own way.
This is also the direction of HL7 CPG in building FHIR Knowledge Artifacts that can be reused for many purposes such as decision support, quality measurement, reporting, and process automation.
3. Knowledge-Grounded Edge AI
In this architecture, AI does not replace doctors and does not replace medical knowledge.
AI operates on a foundation of standardized data along with computable knowledge artifacts to support:
- Reading and summarizing medical records
- Synthesizing treatment progress
- Searching for relevant information
- Supporting the application of clinical guidelines
- Supporting clinical documentation
- Detecting notable information in medical records
Deploying AI at the edge (Edge AI) reduces the need to transmit data outside the healthcare facility, while directly leveraging the already-standardized data source.
In this model, determinism does not come from the AI model itself but from standardized data and executable clinical rules. AI plays a supporting role on that foundation, while the final professional decision always remains with the physician.
A Perspective on the Future
From my point of view, the next development of electronic medical records is not just adding features or integrating AI.
It is building medical records in which data is not only stored but can also be understood by computers, combined with medical knowledge, and executed consistently.
I temporarily call this model the Computable Medical Record.
In such a system, Clinical Decision Support, quality measurement, data analysis, clinical research, and AI are no longer independently operating components, but all draw from a common platform of standardized data and computable knowledge.
Whether this is the future direction of electronic medical records still needs to be verified through research, real-world implementation, and clinical evaluation.
At this point, this is just an architectural idea that I am researching.
In that view:
- The Clinical Computation Model (CCM) is the architecture.
- The Computable Medical Record (CMR) is the system built on that architecture.
Meanwhile, HL7 FHIR, Clinical Quality Language (CQL), FHIR Clinical Practice Guidelines (CPG), and the Computable Clinical Knowledge ecosystem continue to play their roles as the data and knowledge foundation for realizing this vision, rather than being components that are replaced.
Sources
| # | Source | Relevance |
|---|---|---|
| 1 | CQL Specification - Clinical Quality Language | Defines CQL as a high-level, domain-specific language for clinical quality, decision support, and computable guidelines |
| 2 | FHIR Clinical Guidelines Implementation Guide (CPG IG) | Describes creating computable representations of narrative clinical guidelines using FHIR |
| 3 | Computable Records: The Next Generation of the EMR Conversation | Discusses computable medical records as machine-readable records that declare data fidelity |
| 4 | HL7 Knowledge Artifact Representation | Defines Knowledge Artifacts as structured, computable, shareable representations of clinical knowledge |
| 5 | Computable Clinical Guidelines - Clinical Decision Support | Describes infrastructure for translating guidelines into FHIR artifacts and CQL libraries |
| 6 | mCARD - Standardized Computable Data Elements | Vision for the standard health record to be computable and clinically applicable |
| 7 | AIDx: Locally Deployable AI for Clinical Decision Support | Demonstrates locally deployable AI systems for clinical decision support |
Top comments (0)