EHR Data Ownership

Who owns EHR data?

EHR data ownership is shared in practice. The provider usually holds and is responsible for the record, the patient has a federal right to access and copy it under HIPAA, and the EHR vendor may use it only as its business associate agreement allows. State law and the vendor contract settle the details federal rules leave open.

For planning, the useful question is not who owns the data but who can access it, who must keep it, who can use it for what, and who can move it. Each of those has a clearer answer than ownership does.

What rights does a patient have over EHR data?

A patient has a right to inspect and get a copy of their protected health information in a designated record set, which includes most of the clinical and billing record. The provider cannot refuse simply because the data lives in a vendor's system.

HHS guidance on the right of access, 45 CFR 164.524, says a covered entity must provide access no later than 30 calendar days after receiving the request. It may extend that once by up to 30 more days, but only if it tells the individual in writing, within the first 30 days, the reason for the delay and the date it will respond. HHS adds that the clock keeps running while a business associate fetches the data.

• Form and format: Patients can ask for an electronic copy, and the provider should supply it in the form requested if it is readily producible.
• Third parties: Patients can direct a copy to someone else, such as another provider or an app they choose.
• Business associates: When a vendor holds the record, the provider still owns the deadline, so the contract must require the vendor to produce data fast enough.
• Limits: Some information, such as psychotherapy notes, has its own rules, and a provider may deny access only on the grounds the rule allows.

What does the provider hold, and for how long?

The provider holds the record as its custodian and is responsible for keeping it, protecting it and producing it. How long it must keep the record is mostly a question of state law, not HIPAA.

HHS states that the HIPAA Privacy Rule does not include medical record retention requirements and that state laws generally govern how long records are kept. It also says covered entities must apply appropriate safeguards for whatever period they keep the information, through to disposal. A multi-state practice therefore needs a retention schedule per state, and an EHR that can apply it.

• Retention schedule: List each record type and the longest period any applicable state or payer rule requires.
• Minors and special records: Many retention rules treat records of minors and certain specialties differently, so check them separately.
• Custody on closure: If a practice closes or is sold, decide in advance who becomes custodian and how patients will reach their records.
• Disposal: Deleting data at the end of retention is a deliberate, logged act, not something left to a vendor's default.

What can an EHR vendor do with the data?

An EHR vendor that hosts or processes the record is a business associate and may use the data only as its business associate agreement and the HIPAA rules permit. It does not gain the right to use the data for its own purposes by holding it.

The end of the relationship matters most. Under 45 CFR 164.504(e)(2)(ii)(J), the business associate contract must require the vendor, at termination and where feasible, to return or destroy all protected health information it still holds and keep no copies. Where that is not feasible, the protections of the contract must extend to the data and further use is limited to the reasons return or destruction is infeasible.

• De-identified data: Many vendor contracts allow the vendor to create and use de-identified data. Read that clause and decide whether you accept it.
• Aggregation: A business associate may provide data aggregation for your health care operations, but only if the contract permits it.
• Subcontractors: The vendor's hosting and support subcontractors must agree to the same restrictions.
• Return format: The rule says return or destroy; the contract must say in what format, how fast and at what cost.

How does information blocking change the picture?

Information blocking rules make it harder for any party to sit on EHR data. Under 45 CFR 171.103, a practice that is likely to interfere with access, exchange or use of electronic health information can be information blocking unless it is required by law or meets an exception.

ONC explains that the Cures Act set two knowledge standards. Health IT developers of certified health IT and health information networks are judged on whether they know, or should know, that a practice is likely to interfere. Health care providers are judged on whether they know the practice is unreasonable and likely to interfere.

• For providers: Slow-walking a patient's or another provider's request for data, without an exception, can raise information blocking questions as well as HIPAA ones.
• For certified developers: Contract terms, fees or technical limits that make it hard for customers to export or share data are exactly what the rules target.
• Exceptions: The rules include exceptions, such as privacy, security and infeasibility, each with conditions that must be documented.

The practical effect is that ownership arguments rarely justify holding data back. A provider or vendor that refuses or delays a lawful request needs a documented reason that fits an exception, and "it is our data" is not one of them. Build request handling so the reason for any delay or denial is recorded at the time.

What should an EHR contract say about data?

An EHR contract should state who controls the data, how you get all of it out, in what format, how quickly and at what cost, both during the term and at the end. Settle these terms at signing, while you still have bargaining power, rather than at exit.

• Control clause: The customer controls its data; the vendor processes it only to provide the service.
• Full export on demand: A complete export of all data, including documents, images and audit logs, at any time.
• Format and documentation: A documented, machine-readable format with a data dictionary, not a stack of PDFs.
• Termination assistance: A defined period after termination in which the vendor keeps the system readable and supports the migration.
• Return and destruction: Timing, method and written confirmation, in line with the business associate agreement.
• Secondary use: Clear limits on de-identified and aggregated data, or an explicit opt-out.
• Fees: Export and termination fees stated in advance, not set at the moment you need them.

How do you make data ownership real in the architecture?

Make ownership real by regularly taking your data out and checking that you can use it. A contract right you have never exercised is a promise, not a capability.

• Test the export yearly: Run a full export, load it into a scratch environment and confirm a sample of charts are complete.
• Keep your own copy: Feed a warehouse or data lake you control from the EHR's reporting database, FHIR Bulk Data or interface feeds.
• Document the model: Keep a current data dictionary that maps the vendor's structures to your own definitions.
• Own the keys: Where the platform allows customer-managed encryption keys, decide whether you should hold them.
• Track identifiers: Store the vendor's identifiers alongside your own, so records can be matched after a migration.

Your own copy carries its own duties. It holds protected health information, so it needs the same access controls, audit logging, retention schedule and risk analysis as the EHR itself, and anyone hosting it for you needs a business associate agreement.

Where EHR data ownership disputes start

• The exit surprise: The contract allows export, but only as images of documents, and a usable export costs extra.
• The missing history: Audit logs and old versions of notes are not included, and a legal hold needs them.
• The closed practice: A physician retires, the practice closes, and nobody arranged who keeps the records.
• The research request: A vendor proposes using de-identified data for a product, and nobody reviewed the contract clause.
• The slow request: A patient's access request waits on the vendor, and the 30-day clock runs out.

Almost every dispute in this list could have been settled with a clause written at signing and an export tested once a year.

How Agnotic can help

Agnotic Technologies builds the technical side of data ownership for clients: complete exports from EHR databases and APIs, data dictionaries that map vendor structures to your own, warehouses you control, and migrations when you change systems. Agnotic also helps your counsel and procurement team turn the contract checklist above into testable technical requirements.

For patient access, Agnotic builds the request workflows and API connections that let providers meet the HIPAA deadline even when the record sits with a vendor.

Sources

• 45 CFR 164.524: Access of individuals to protected health information
• HHS FAQ: HIPAA and medical record retention
• ONC: Information blocking
• 45 CFR 164.504: Business associate contracts