Hospitals need four checks before AI can use electronic records

The US Office of the National Coordinator for Health Information Technology (ONC) updated its electronic health record (EHR) explainer on December 10, 2025 and describes an EHR as a longitudinal record available to authorized health professionals. The page says such a record can be created, managed and consulted by authorized staff across more than one health care organization.

That scope makes an EHR broader than one database export. An artificial intelligence (AI) system receives only the records selected and transformed by its data pipeline, so a working connection does not by itself establish that it received the correct person, code, unit, time range or source context.

Hospitals can separate that problem into four checks: data mapping, access and audit, clinical workflow, and responsibility and release. The sequence is an APPI News editorial synthesis, not an HL7 conformance test, certification program or legal test in any country. A separate APPI News analysis expands the review into intended use, evidence, interoperability, human control and monitoring.

Electronic records are longitudinal systems, not model-ready files

ONC says EHR and electronic medical record (EMR) are often used interchangeably, while its explainer usually limits an EMR to one provider or practice and gives an EHR a broader, cross-setting scope. This is a US agency's explanation, not a universal naming rule, and hospital or supplier documents may use the labels differently.

An operational EHR can draw from hospital information systems, laboratory systems, imaging services, medication records and clinical notes. The input to an AI component may instead be a selected query result, a time-limited extract, an image or a block of text. If that input loses its status, date, unit, source or version, the resulting output cannot be treated as an interpretation of the complete longitudinal record.

The path from an EHR to an AI result can be divided into four layers. Each layer preserves different facts and can fail even when the next system returns a technically valid response.

Layer	Evidence to preserve	Failure the check can expose
Retrieve the record	Patient and encounter identifiers, source system, time window and retrieval authority	A record linked to the wrong person, encounter or period
Normalize meaning	Field definition, code system and version, unit, status and missing-value rule	Two fields that look alike but encode different events or units
Assemble model context	Relationships among records, chronology, provenance, preprocessing and input version	An input that drops the source or sequence needed to interpret a value
Return the output	Intended user, destination record, model version, review action, fallback and audit event	An output that reaches the wrong workflow or leaves no review trail

This sequence is an editorial model, not a standard issued by HL7 or another authority. A later display cannot repair the wrong record, code or unit selected upstream, so the evidence has to remain connected across all four layers.

FHIR standardizes exchange, not every local meaning

Health Level Seven International (HL7) defines Fast Healthcare Interoperability Resources (FHIR) as a standard for electronic health-information exchange, and its current published Release 5 specification uses Resources as the basic exchangeable building blocks. Resources share a representation and metadata and can be combined to support a defined use.

The base specification also includes an extension mechanism for information outside its core resource definitions. That flexibility lets implementations represent local needs, but matching Resource names do not prove that two local fields use the same code, unit or definition.

An interface acceptance record can list each field that enters the model, its source table or resource path, terminology, unit, timestamp, missing-value behavior and transformation. Test cases can then challenge stale values, conflicting codes, absent fields and version changes instead of stopping at a successful application programming interface (API) response.

SMART adds app authorization but not a common legal basis

HL7's SMART App Launch 2.2.0 guide, active since March 1, 2023, defines OAuth 2.0-based patterns for authorizing and authenticating user-facing applications and automated backend services, with scopes that limit delegated access. The guide can also pass launch context, such as the patient selected in an EHR session, to an authorized application.

HL7 states that FHIR is not a security protocol and places authentication, authorization, access-control decisions and audit logging within a wider security system, while FHIR supplies structures that can support provenance and audit events. A successful request therefore does not show by itself that access was permitted for the stated purpose, limited to the needed records or reviewed after use.

An access matrix can identify the person or service requesting data, the application, purpose, permitted resource types and operations, expiration rule, processing environment and audit owner. SMART scopes can express technical permissions, but they do not determine the lawful basis, consent conditions, retention limits or secondary-use rights in every country.

World Health Organization (WHO) guidance published on October 19, 2023 says health AI may process sensitive personal information and calls for safeguards covering privacy, security and integrity, with attention to the scope of each jurisdiction and its consent requirements. The guidance does not create one data-use rule for all markets, so a global implementation still needs a legal review in every country where it operates.

Clinical validation follows the intended workflow

The International Medical Device Regulators Forum (IMDRF) issued 10 final good machine learning practice principles on January 27, 2025, including representative clinical data, independent test sets and assessment of the human-AI team in the intended workflow. The document also calls for monitoring deployed models and controlling risks when they are retrained.

An EHR connection establishes none of those performance claims. Evaluation still has to cover the intended population, setting, inputs, model version and workflow, including how trained users see the output and what happens when the system produces no result.

The workflow record can identify who receives an output, which source evidence appears with it, whether the user can accept, modify or reject it, and which process remains available during an outage. The responsibility record can connect the intended use, supplier, data pipeline, deployed version, review role, incident route and authority to suspend the system.

Software that only stores or retrieves records and software that influences a medical decision can enter different regulatory paths. A separate APPI News report explains how intended purpose and potential harm, rather than the presence of an AI algorithm, shape medical-software classification and why the result varies by market.

Four records make acceptance testable

The four checks can be kept as separate but linked records in a procurement and deployment file. This is an APPI News synthesis of the cited documents, not an international certification program or a substitute for requirements in any country.

Record	Minimum contents	Decision it supports
Data map	Source, field or resource path, terminology, unit, time, missing-data rule, provenance and transformation	Whether the model input preserves the intended clinical meaning
Access and audit matrix	Actor, application, purpose, scope, environment, retention, revocation and audit owner	Whether data access matches the recorded authority and can be reviewed
Workflow test	Intended user, screen, timing, source evidence, review action, fallback and error-reporting route	Whether the output reaches the right user with an effective human response
Responsibility and release record	Intended use, model and interface versions, validation owner, supplier duties, incident route, stop authority and rollback	Whether the deployed system still matches its evidence and has a named response to failure

The patient record, data extract, model, interface and release need identifiers that can be matched across the four records. If a supplier changes an input mapping, model version, API or user interface, the linked file can show which earlier tests no longer describe the deployed system.

The decisions can also fail independently. A valid permission does not correct a wrong unit, a conformant FHIR response does not establish clinical performance, and a strong model score does not assign review authority or create an incident process.

The sources do not establish a worldwide deployment verdict

ONC's EHR and EMR distinction comes from the US health-information technology context, while FHIR and SMART App Launch are technical specifications. They do not show that a local record is complete, that two hospitals assign the same meaning to a field or that a particular use is lawful.

WHO and IMDRF provide governance and lifecycle principles, but they do not replace national law, assign legal responsibility after an error or authorize a named product. The IMDRF document covers AI-enabled medical devices and does not extend automatically to every administrative or research application connected to an EHR.

APPI News could not find comparable international data showing how many hospitals complete all four checks before connecting AI to electronic records at the time of writing. The available documents describe standards and control processes, not a cross-country measure of completed hospital deployments.

For a named deployment, the evidence can end with four linked records: the data map, access and audit matrix, workflow test, and responsibility and release record. An EHR connection is one fact in that file; it is not evidence that the remaining checks have passed.