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.

How this plays out outside Taiwan

The four checks look different when the record sits inside a national exchange or a country-specific certification system. A hospital buying an AI product in the United States cannot treat a FHIR endpoint as the whole approval file. The US Office of the National Coordinator for Health Information Technology's Decision Support Interventions criterion requires certified health IT to support source-attribute information for predictive decision-support interventions. ONC's page describes fields covering the intervention's intended use, the data used to develop it, performance and fairness information, and ongoing maintenance. That creates a practical procurement question: can the supplier provide those attributes in the certified health IT product, and can the hospital keep the information current when the model or data pipeline changes? It does not mean that ONC has approved every clinical model connected to an EHR.

US buyers also need to separate the status of the health IT module from the status of the AI function. The ONC criterion is about what a certified module must support and disclose; it is not a clinical-performance verdict for every intervention a hospital may connect. A request for proposal can therefore ask for the certified module's listing, the model's intended use, local validation plan, user group, source data description and change-management record as separate items. If the product is supplied by another company, the contract should identify who maintains the source attributes, who investigates a failed output and who can disable the integration. Those are responsibility checks, not fields that FHIR or OAuth can fill in.

In England, the integration route is narrower and more operational. NHS England describes GP Connect as a national service that securely connects approved clinical and care systems to general-practice records for direct patient care outside the GP practice. The service has prerequisites, assurance and onboarding guidance for suppliers. Its technical documentation covers structured and document access through specified APIs, while NHS England's foundation guidance requires accredited Spine connectivity and a verified NHS number for API use. An AI supplier seeking access cannot infer permission from the existence of a patient's record or from generic FHIR capability. It needs the approved use case, the consuming organization's assurance route and a workflow showing what a clinician sees and does with the result.

Australia's My Health Record illustrates a different boundary: a national record system can set explicit rules for secondary use without turning research access into a general commercial data feed. The Australian Digital Health Agency says people can change whether their My Health Record data is shared for public health and research purposes. The same page says the framework does not permit use solely for commercial and non-health purposes, bars insurance agencies from access, requires ethics approval for identified data and does not allow released data to be sold. An AI project in Australia therefore has to document whether it is providing care, conducting research or supporting public health, then check the applicable My Health Records Act 2012 framework and approvals. A model-training clause in a supplier contract is not enough to establish that the proposed use fits the selected purpose.

Singapore's national approach puts contribution and security into a statutory project. Singapore's Ministry of Health says the Health Information Act mandates licensed health-care providers to contribute data to the National Electronic Health Record and includes cybersecurity and data-security requirements. The ministry describes the NEHR as a centralized repository launched in November 2011 to support information flow between providers. For an AI deployment, that does not remove the need to identify the source organization, permitted purpose, user role, retention period and audit trail. It does mean a Singapore project should check the Health Information Act material and the NEHR operator's technical requirements rather than borrowing a US or UK access assumption.

These examples change the acceptance file, not the four-part logic. In the United States, record the ONC certification and predictive-intervention attributes. In England, record GP Connect onboarding, approved access and the clinical safety workflow. In Australia, record the My Health Record purpose and secondary-use settings or approvals. In Singapore, record the provider's contribution and security obligations under the Health Information Act. The exact forms and authorities differ, and this article does not establish that a particular AI product is available or lawful in any of these markets. A hospital should ask the named national authority or system operator for the current route, then preserve the answer with its data map, access matrix, workflow test and release record.

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.