EHRs, Registries and Other Real-World Data
Part of ICH E6(R3) Annex 2 for Site Staff: Pragmatic Elements and Real-World Data.
About 5 minutes. Free, in your language, no account needed.
Expert review pending. CRLN wrote this lesson against the ICH E6(R3) Annex 2 text adopted on 3 June 2026. It has not yet been reviewed by a subject matter expert. Always follow your protocol, your sponsor and your regulator.
Why this matters
A trial may take some of its data straight from your hospital's EHR, from a national registry or from insurance claims. Those systems were built for care or billing, not for a trial. Annex 2 explains what has to be true before such data can be trusted in a trial, and site staff are often the people who notice when it is not.
Primary collection and secondary use
The Annex 2 introduction separates two uses of data. Primary data collection gathers data for the trial itself, under the protocol, for example a study assessment or questionnaire. Secondary use reuses data first collected for another purpose. When such data describe patient health or care outside a trial, they are real-world data (RWD). They can be used, for example, as endpoint or outcome data, or as an external control. Either way, they must be fit for their intended purpose in the trial.
Fit for purpose: reliable and relevant
Section 3.5.1(a) says the sponsor should make sure RWD are fit for purpose, described by two properties:
- Reliability: accuracy, completeness, provenance and traceability.
- Relevance: whether the key data elements, such as exposure, outcomes and covariates, are available to answer the trial question.
Section 3.5.1(b) lists things that can make a source unfit, including:
- different formats, terminologies and standards across sources;
- no standard timing, because routine assessments happen when care needs them, not on the protocol schedule;
- missing data, for example when participants move to another healthcare system, and events that are hard to capture, such as stopping a treatment or starting another one that the EHR does not record;
- the overall quality of the source, its database structure and its coding;
- the methods used to protect privacy, such as pseudonymization;
- whether the systems used to collect the data, such as registries or DHTs, are fit for purpose.
The missing data point catches people out. A source can only show what it captured. No hospital record in one network does not prove no hospital stay. Treat "no record" as unknown unless the plan explains why it can mean "no event".
Linking sources and resolving conflicts
Section 3.5.1(c) says data sources may need to be linked, for example EHR with claims, or a registry with a death registry. Matching to the right person must be assured, privacy protected and the linkage pre-specified in the protocol or related documents, including how inconsistencies between sources will be resolved in a systematic and consistent way.
When an EHR export and a site entry disagree, do not choose one yourself, and never average them. Raise a query and follow the pre-specified rule. If there is no rule, say so, so one can be set.
Access to source records
Section 3.4.1 says sponsors are responsible for making sure RWD are fit for purpose and must be able to access individual-level data and, as needed, source records, in line with regulations. When another organization owns the data, such as a hospital, registry holder or insurer, the sponsor needs documented agreements covering access and protection, and regulators must be able to inspect.
The depth of access depends on how critical the data are. For higher criticality uses, such as key efficacy or safety endpoints, assessing the source at a system level may be insufficient; the sponsor may need source access to confirm, for example, that an event happened. Where the data owner will not allow that, the sponsor should consult the relevant regulatory authorities. For lower criticality uses, such as exploratory endpoints, system and process level assessments may be enough if the limitations and reasoning are documented.
Whoever extracts, links or transforms the data, the sponsor stays responsible for overseeing those steps.
Consent and permission
Section 3.4.2 says permission or approval from an authorized body, such as an IRB or ethics committee, or consent from the individuals, is needed for the use of their health data, in line with local rules. Consent should describe use of and access to the data and source records by regulators and, where applicable, sponsor representatives and IRBs. For secondary use, the approach can differ by region: some use broad consent, and in others an IRB or ethics committee permission may substitute for consent. Records of consents or permissions must be kept and available to regulators.
Security
Section 3.5.2 says extracting data from EHRs, like other remote collection, needs special attention to security, cybersecurity and privacy. Only use the approved extraction route.
Key takeaways
- RWD must be reliable and relevant for the specific trial question (Annex 2, section 3.5.1(a)).
- Missing records and uncaptured events are a known limit of RWD; no record is not proof of no event (section 3.5.1(b)(iv)).
- Linkage and the rules for resolving conflicts between sources are pre-specified (section 3.5.1(c)).
- For key endpoints, sponsors may need source access; if refused, they consult regulators (section 3.4.1).