Personal Health Record Apps: A Source-Aware Buying Guide

A personal health record app is a user-managed electronic collection of health information assembled from sources the person can access, import, or enter. It is different from a provider's electronic health record and from the portal used to view that record. A PHR can make copies easier to organize and share, but it is only as complete as the sources and fields that actually arrive.

The MedlinePlus overview describes a personal health record as a practical way to keep track of health information scattered across doctors' offices and hospitals. The FTC uses a more technical definition for its Health Breach Notification Rule: an electronic record with the capacity to draw identifiable health information from multiple sources and managed, shared, and controlled by or primarily for the individual. Those definitions explain the job. They do not make every app with a “health record” label equivalent.

A record is portable only when you can verify what went in, what came out, and what remains missing.

PHR, portal, EHR, and exchange are different layers

The terms overlap in ordinary conversation, so compare who maintains each layer, how information arrives, and what the layer is designed to do.

• Electronic health record (EHR): a healthcare organization's operational record system. It supports care, documentation, billing, and other workflows. An individual's access right can cover a broad designated record set, but the EHR interface is not necessarily the copy the individual keeps.
• Tethered patient portal: a user-facing access channel supplied by a provider, health plan, laboratory, or its technology partner. It may show records from one organization or connected organizations. What appears still depends on the source, connection, date range, category, and portal workflow.
• Personal health record: a user-managed collection that can combine copies received from organizations with information the person enters or imports. Its useful boundary is “complete as obtained,” not “the complete medical history,” unless that broader scope has actually been verified source by source.
• Exchange or API access service: a route that retrieves, transmits, or exposes supported electronic data after authorization. A successful connection proves a route worked; it does not prove every organization, document, attachment, historical date, or correction came through.
• Source archive: the original reports and exports kept outside the organizing layer. This is where a person can return when a structured fact, summary, or export needs to be checked.

The distinction is not an argument against portals. ONC reports that about 8 in 10 people who used an online patient portal found it helpful and easy to understand. ONC also reports that nearly 1 in 10 people who checked an online health record asked to have a mistake corrected. A useful view and a verification workflow can coexist; neither statistic establishes that a given portal or PHR is complete.

Why “all your records in one place” is usually the wrong test

“All” hides several separate questions:

1. Source coverage: Which organizations, devices, files, and manual inputs can contribute?
2. Record coverage: Are clinical notes, labs, images, claims, medications, attachments, and messages all supported, or only selected categories?
3. Time coverage: How far back does each source provide records?
4. Field coverage: Does the app preserve the report, comments, collection time, unit, flag, and source-specific reference range, or only a few values?
5. Verification status: Has anyone compared the organized copy with the source and marked known gaps?

If a portal does not show an expected item, use the organization's current request process. ONC's record-access guide says records may be delivered in forms such as PDFs, documents, images, direct EHR uploads, or a health app, depending on the holder's available process. The guide to getting your medical records turns that source-by-source work into a request and verification sequence.

Keep an explicit state for each expected item:

• Source verified: the item matches the named source and date.
• Complete as obtained: every item in a defined response or export was preserved, without implying the holder sent its entire record.
• Partial: some requested or expected material arrived and some did not.
• Unverified: the organized copy has not been checked against the source.
• Derived or user-entered: the item is a summary, annotation, or manual entry rather than a source record.

A missing-record log helps keep “not in this view” separate from “does not exist.” When only some files arrive, document the exact response with the partial-record workflow instead of silently promoting it to “complete.”

HIPAA is not a product feature checklist

Whether HIPAA applies depends on the parties and their relationship. HHS says that when an individual directs a covered entity to send electronic protected health information to an independently chosen app that is not a covered entity or business associate, the information in that app is no longer protected by the HIPAA Rules. An app provided by or on behalf of a covered entity may stand in a different relationship.

That is why “Does HIPAA apply to this app?” cannot do all the work. HHS's mobile-device privacy guidance also cautions that, in most cases, HIPAA does not protect health data a person downloads to or enters into a personal-use app unless the app is provided by a covered entity or business associate.

Non-HIPAA health apps are not necessarily outside every rule. The FTC explains that its Health Breach Notification Rule can apply to vendors of personal health records and related entities, and that the July 2024 amendments clarified coverage for health apps and similar technologies. State privacy, consumer-protection, breach-notification, and other laws may also matter. This guide is not a legal determination for a particular app.

What privacy and security questions should you ask?

Look for specific, current answers rather than a trust badge. The useful review has at least four parts.

Data use and sharing

Ask what the app collects, which features send data to processors or AI services, whether health data is used for advertising or model training, when information is shared, and what consent controls apply. Check whether the privacy notice covers the actual app or only a public website.

Account and technical safeguards

Ask how data is protected in transit and at rest, whether multi-factor authentication is available, how account recovery works, and whether sensitive exports are protected. A claim such as “encrypted” needs a defined scope: which data, in which state, under whose control?

Retention, deletion, and incidents

Read what happens after account closure, how long backups or logs may persist, how deletion requests are handled, and how users are notified about incidents. Do not assume cancelling a subscription deletes data—or preserves access—unless the current terms say so.

Sharing boundaries

Confirm whether a share action sends a file, grants ongoing access, creates a public link, or authorizes an API connection. Check expiration, revocation, recipient identity, and whether access is logged. Share the smallest useful set through a channel the recipient accepts.

Portability means testing the exit

An export button is a starting point. A usable exit test asks:

• Which formats are available: original files, PDF, CSV, JSON, XML, or another structured format?
• Does the export include source names, dates, units, flags, comments, attachments, and available ranges?
• Are original documents included, or only facts derived from them?
• Can the files be opened without the app and matched back to the source?
• Does export cover the whole account, one record, one date range, or selected categories?
• What remains accessible after cancellation or account closure?
• Is there a documented deletion process separate from export?

For a real handoff, the recipient's requirements matter more than the app's preferred format. The specialist export guide shows how to build a manifest, verify files, use an accepted channel, and keep receipt separate from clinical review.

A five-step PHR app evaluation

Step 1: define the job and source scope

Write down the records you need to organize, the organizations and dates they come from, and the intake routes you actually possess. Separate portal connections, exchange access, downloaded files, device data, and manual notes. An app does not fail because it has a narrow scope; it fails the test when that scope is unclear or mismatched to your job.

Step 2: review privacy, security, and control terms

Before uploading a record or authorizing a connection, read the current app-specific privacy notice and terms. Record concrete answers for data collection, sharing, advertising, AI or model use, processors, retention, deletion, account security, incident notification, and ongoing share links. Recheck these terms periodically because products and policies change.

Step 3: run a controlled input test

Use synthetic data only in a vendor-provided sandbox or test account that is isolated from live records and cannot feed clinical or AI-sharing workflows. If no isolated environment exists, complete step 2 first, then use the smallest appropriately redacted, non-urgent real sample that can exercise an awkward case, such as an attachment, correction, or missing range. Explicitly label any test entry, keep it out of clinical and AI sharing, note what the app accepts, rejects, transforms, or leaves out, and preserve the source outside the app.

Step 4: verify provenance and completeness states

Open each organized item beside its source. Check identity, source, date, value, unit, flag, comments, and available range when relevant. Look for a way to mark partial, missing, duplicate, corrected, derived, and unverified information without pretending uncertainty has disappeared.

Step 5: verify export, removal, and exit

Export the labeled test entry. Open it on another device, compare it with the source, and confirm which categories and fields came out. Remove the test entry, create a fresh export, and verify that the entry is absent before putting the account into real use. Then find the documented steps for cancelling, closing the account, revoking connections, and requesting deletion. A successful export-and-removal test is stronger evidence than a “no lock-in” slogan.

Where Libby fits—and where it does not

Libby's current documented job is narrower than a complete personal medical record. It organizes facts from uploaded lab reports—such as recorded values, dates, units, flags, and available lab reference ranges—into a timeline. The current public product page also describes PDF and CSV export.

Check extracted details against the source report. Libby does not retrieve a chart from a patient portal or health-information exchange, replace the provider's official record, prove that a lab history is complete, establish that results from different methods are clinically comparable, or interpret a trend as a diagnosis or treatment recommendation.

Before uploading, review the current Libby app privacy policy and the controls of any destination used for sharing. The public marketing-site privacy notice is separate from the app's health-record data practices. The Libby and Apple Health comparison provides a source-by-source map when device data, supported provider connections, and saved lab reports all appear in the same workflow.

FAQ

What is a personal health record app? A personal health record app is a user-managed electronic collection of health information assembled from sources the person can access, import, or enter. The app may organize copies, but its label does not prove complete source coverage.

How is a personal health record different from a patient portal? A portal is an access channel provided by a healthcare organization, health plan, laboratory, or technology partner. A PHR is a collection managed primarily for the individual and may combine copies from several sources. A portal can be useful and can aggregate records, but it is not automatically the person's complete history.

Is a PHR the same as an EHR? No. An EHR is maintained for a healthcare organization's operational record workflows. A PHR is managed primarily for the individual. Information can move between them, but the systems have different maintainers, purposes, access paths, and completeness limits.

Will a PHR app automatically contain my complete medical history? Not unless every relevant source, record category, date range, attachment, correction, and field has been received and verified. Use scoped terms such as “complete as obtained from this source for these dates,” and keep known gaps visible.

Is every personal health record app covered by HIPAA? No. HIPAA coverage depends on the app's role and relationship to a covered entity or business associate. HHS says information sent at an individual's direction to an independent app may no longer be protected by HIPAA, though other federal or state rules may apply.

What privacy and security questions should I ask? Ask about collection, sharing, advertising, AI use, processors, encryption scope, multi-factor authentication, account recovery, retention, deletion, incident notices, and share-link controls. Read the current notice for the app itself, not only the marketing website.

What should a portable health-record export include? The right answer depends on the next use, but test for usable files, source names, dates, units, flags, comments, attachments, available ranges, and original documents where promised. Open the export outside the app and compare it with the source.

Where does Libby fit in a personal-record workflow? Libby organizes facts extracted from uploaded lab reports into a source-aware timeline and documents PDF/CSV export. It does not retrieve a complete provider chart, replace the original report, make every extraction correct, or provide clinical interpretation.

References

• MedlinePlus: Personal Health Records
• ONC: The Guide to Getting & Using Your Health Records
• ONC: Get It
• ONC: Check It
• HHS: Individuals' Right under HIPAA to Access their Health Information
• HHS: The access right, health apps, and APIs
• HHS: Protecting health information on a personal cell phone or tablet
• FTC: Complying with the Health Breach Notification Rule
• eCFR: 45 CFR 164.524, Access of individuals to protected health information
• Libby: Current public product surface
• Libby Health app privacy policy

---

Educational information, not medical, legal, privacy, or security advice. Requirements and product behavior vary by organization, jurisdiction, account, and version. Verify source records and current terms, and seek qualified help for clinical decisions or a specific legal, privacy, or security question.