What Should Healthcare Providers Inventory Before Licensing EHR Data?

Before exploring EHR data licensing, a healthcare provider should be able to describe what its archive actually contains: the care settings covered, the types of records retained, how those records connect and what changed over time. The most useful first deliverable is an inventory that your clinical, data and governance teams can explain together.

An electronic health record (EHR) is a system used to document care. An export from it is one representation of that history, not the history itself. For a licensing assessment, the question is which parts of the history a defined extract would preserve.

You can prepare an initial description without sending any patient records. This checklist is for that preparation. It does not establish permission to share data, and it does not promise a licensing opportunity. It is general information, not legal advice.

Define the archive before counting it

Choose a boundary that your organization can describe accurately. It could be one hospital’s outpatient records, a clinic group’s laboratory-result history, or the encounters recorded while a particular system was in use.

Write down the participating sites, care settings, broad historical period and source systems. Then note what falls outside that boundary.

For example, an EHR can hold radiology reports while the images themselves sit in a separate archive. Say whether you have confirmed the availability of each. A report and an image are different assets and should not be counted as one. Our healthcare datasets page lists the record families providers most often describe.

Avoid opening with “we have all our patients’ data.” That phrase leaves the practical scope unanswered.

Use this EHR inventory worksheet

Complete the worksheet inside your institution. Record field definitions and review status, not patient examples, in any version you share externally.

Inventory item	What to document internally	What an initial supplier enquiry can say
Organizational role	Which institution generated the records and who can authorize a discussion	Organization type and the role of the authorized contact
Scope	Sites, care settings and system boundaries	Broad settings and coverage
Record families	Encounters, notes, orders, results, procedures and other retained categories	Which categories exist and which still need confirmation
Counting unit	Whether a count means people, encounters, documents, results or versions	Approximate scale, the unit counted and how it was estimated
Linkage	How events connect internally and which links are uncertain	Whether records can be connected, without sharing any identifiers
Time fields	What event, entry, release, correction and extraction times mean	Whether timing and revision history are documented
Codes and measurements	Source coding systems, versions, units and local definitions	Available documentation and known mapping gaps
Origin and changes	Original system, imports, migrations and transformations	Major source-system changes and known limitations
Coverage and missingness	Gaps by site, period and record family	Broad gaps, without identifying rare patients or small groups
Corrections and duplicates	Status changes, amended documents and repeated deliveries	Whether versions and duplicate handling are understood
Review route	Institutional, privacy, contractual and local-law questions	Who must review the proposed scope and what is still unresolved

“Unknown” is a useful answer when it names a concrete question for the right team. An unsupported claim of completeness is harder to work with.

Keep people, encounters and rows separate

A row count tells you how many rows a query returned. On its own, it does not tell you how many distinct people, visits or usable cases an extract contains.

One encounter can have several notes, many individual laboratory observations and corrected versions of each. An imported document can also appear in more than one place.

Ask your data team to define every reported count and to record the rules used to produce it. Keep detailed counts within your approved internal process; a first enquiry usually needs only broad estimates.

For linked records, describe the relationships your systems support. The OMOP data-model conventions published by OHDSI are a useful technical example: identifier fields link entities such as people and visits, while source values and standardized concepts play different roles. OMOP is a reference model here, not a requirement to convert your archive before talking to DataNexx.

Document what the dates mean

A test being performed, a result being released and an amended result being entered are different events. Preserve the distinction wherever your source systems record it.

Ask which timestamp refers to the clinical event, which records a documentation or release step, and which belongs to the extract itself. Note any time-zone conventions, date shifting or other transformations, and any uncertainty.

The HL7 FHIR R4 Observation specification (version 4.0.1) shows these distinctions in practice. It has separate fields for the clinically relevant time, the time a version was made available and the result status, including codes such as preliminary, final and amended. It also offers a way to record why an expected value is missing.

FHIR is cited here as an example of how one standard separates these ideas. It is neither the newest FHIR release nor a required export format. Use the definitions in your actual systems, and do not assume that similarly named fields mean the same thing across sites or software versions.

Describe provenance in plain language

Provenance is the record of where information came from and how it was produced or changed. For an EHR inventory, useful questions include:

1. Which system or service originally produced the information?
2. Was it entered directly, imported or generated by a transformation?
3. Which process changed how it is represented?
4. Is the version or amendment history available?
5. Who can explain the remaining uncertainty?

The HL7 FHIR R4 Provenance resource describes how to track the activities, and the people or systems involved, that created or revised a record. Your institution does not need to claim FHIR conformance to document its own source history clearly.

Technical provenance also does not establish licensing authority. Knowing which system supplied a file and knowing whether your institution can authorize a proposed use are separate questions. Our data licensing principles explain how we treat provenance and rights before any dataset is licensed.

Make missingness and system changes visible

A blank field can have several explanations. The information was never collected, was left out of the extract, was held in another system, or has a documented reason for being absent. Do not turn every blank into a clinical conclusion.

Prepare a short timeline of changes that could affect interpretation. Include system migrations, added sites, revised forms and changes to source coding or extraction rules where you know them.

Hypothetical example. A clinic group introduces a new intake form at one site partway through its archive, and a field becomes much more often populated afterwards. The inventory should record the form change. It should not suggest that earlier patients lacked the characteristic. This example is illustrative and does not describe any real institution’s data.

Keep source meaning alongside standardization

If records have been mapped to a common terminology or data model, document the mapping version, the transformation process and the categories that remain unmapped. Say whether the original source values are still available for authorized internal checks.

OHDSI’s conventions keep source representations separate from standardized concepts. The practical lesson for an inventory is to state which representation a reviewer is looking at and how it was produced.

A format label does not make records complete, comparable or ready for every AI task. Clarify the proposed scope before commissioning extensive conversion work.

Keep the inventory separate from permission to share

Keep the first enquiry descriptive. Do not attach raw records, patient screenshots, real identifiers or distinctive clinical narratives.

An inventory describes data; it does not decide whether the data can be shared. Privacy rules depend on where the data was collected and where it would go. In the United States, HHS guidance describes the two HIPAA de-identification methods. In the EU, the European Commission explains that pseudonymised data that can still be used to re-identify a person remains personal data under the GDPR. Neither framework is a universal approval for an international project.

Your institution should establish the countries, purpose, recipients, review route and transfer arrangements for any proposed project. System access, a technical export capability or a confidentiality agreement does not settle those questions. For how de-identification, approvals and the wider licensing process fit together, see our guide to healthcare data monetization.

Bring a clear inventory to the first conversation

A useful summary names the institution type and country, describes the broad record families, and states the coverage and limitations your team has established. Leave unresolved questions visible rather than smoothing them over.

Describe your healthcare archive to DataNexx with a high-level summary only. Keep patient information out of the enquiry. An assessment does not guarantee a buyer match, permission to license or a transaction.