How to find out which electronic health record your hospital uses

Why the answer changes what you can do

Almost nobody sets out to learn which electronic health record their hospital runs. People arrive at the question sideways, usually after trying to do something ordinary: connect an app, see two hospitals' records in one place, or work out why a portal login that works for one clinic does nothing for another.

The vendor behind the portal turns out to decide a surprising amount. It decides what the portal is called and which mobile app you are told to download. It decides which third-party apps can appear as connection options at all, because the health system enables them inside that vendor's framework. It shapes what proxy access for a family member looks like in practice. And it determines which public API your record travels over when you send a copy somewhere.

For readers of this site there is one more reason, and it is worth stating plainly rather than at the bottom of the page. Sahara connects through Epic MyChart today. It is not connected to Oracle Health, MEDITECH, or athenahealth. So if you are here to work out whether you can use Sahara, this question is the whole answer, and it is better to find out in two minutes than after creating an account.

None of this is a judgement about any vendor. A record system is not better because an app you happen to want can reach it. Identifying yours simply tells you which set of options is real for you.

Start with the portal you already log into

The fastest clue costs nothing. Open the patient portal your provider gave you and look at two things: what it calls itself, and what address it loads from.

The clearest case is MyChart. Its own patient site states at the foot of every page that MyChart is licensed from Epic Systems Corporation. A portal that presents itself as MyChart is Epic's portal, whatever your hospital has painted on top of it.

That last clause is where people go wrong, so treat the name as a clue rather than proof. Health systems rename the portal freely. A portal called MyHealth, MyRecord, or something built from the hospital's own brand may still be MyChart underneath, and the reverse happens too. The login address in your browser is often more honest than the logo, because the domain frequently keeps the vendor's naming even when the page does not.

So use this step to form a hypothesis in ten seconds, then confirm it with the next one.

• Look at the portal's own name on the login screen, and at the name of the app you were told to install.
• Read the full address in the browser bar, not just the part before the first slash.
• Check the small print at the bottom of the login page, which often names the software licensor.
• Remember that your hospital's branding sits on top of the vendor's product and can hide it completely.

Confirm it in the endpoint list the developer has to publish

This is the strongest route, and it is the one almost nobody knows exists. Certified health IT developers are required to publish, openly and without a login, a list of the organizations using their certified API, along with the technical address for each one.

The requirement sits in the federal certification programme. In the test procedure for the standardized patient and population services API, step API-DOC-3 states that to fulfil the API Maintenance of Certification requirement, the health IT developer demonstrates the public location of its certified API technology service base URLs and related organization details. The phrase that matters to you is the last one. Organization details means names, and names are searchable.

The practical consequence is that for each major certified API developer there is a public page listing customer organizations against their service addresses. Epic publishes its list on its open developer site, where each entry carries a managing organization name alongside the endpoint address, and the whole set can be downloaded in bulk. Searching your hospital's name there is a direct test.

Read the result carefully in both directions. A hit tells you that organization exposes an endpoint through that developer's product, which is a solid answer. A miss is weaker evidence than it looks. Your hospital may be listed under a parent health system's legal name rather than the name on the building, an entry may lag a recent go-live, and separate lists exist for different versions of the standard.

• Search for the parent health system's name as well as the local hospital or clinic name.
• Try the legal entity name, which often differs from the marketing name you know.
• Treat a match as confirmation and a miss as inconclusive, not as a negative answer.
• Note that these lists describe the API connection, not what your organization has enabled for patients.

Cross-check against the government's own lists

Two federal resources sit behind all of this, and both are public.

The Certified Health IT Product List, published by ASTP and ONC, is the authoritative record of which health IT products are certified, which developer makes them, and which criteria each product met. It is the right place to confirm that a developer and product you have identified are real and currently certified, and to see what the product was actually certified to do. Be clear about its limit: it catalogues products and developers, not which hospital purchased which one.

Lantern is the second. ONC describes it as a monitoring system for Fast Healthcare Interoperability Resources APIs that helps certified API developers maintain a list of the endpoints exposed by API information sources using their product. It is built for developers rather than patients, so treat it as corroboration rather than a starting point.

Using both together answers a question the vendor's own page cannot: whether the product you think your hospital runs is certified for patient API access at all.

Or simply ask, because nothing here is confidential

If none of the above appeals, the shortest path is a phone call. Ask for health information management, sometimes called the medical records department. This is the same team that handles requests for copies of records, and the question is routine for them.

Ask two things rather than one. Which electronic health record system does the organization use, and which patient portal should a patient of this clinic or hospital be using. The second question is often the more useful, because a large system can hold your record in one place and give you a portal that belongs somewhere else.

There is no reason for anyone to withhold this. The software a hospital runs is not a clinical secret, it appears in press releases and job adverts, and staff answer the question every day.

• Ask for health information management or the medical records department.
• Ask which record system the organization uses, and separately which portal you should use.
• Ask whether the clinic you attend is on the same system as the main hospital.
• Write down the answer with the date, because systems change and your notes will not.

One health system, more than one record system

The question people ask is which system does my hospital use. The question that usually matters is which system holds this particular record, and the two have different answers more often than you would expect.

A hospital, an affiliated clinic that kept its own software after being acquired, an independent laboratory, and an imaging centre can each run something different. Health systems that merged years ago can still be running two record systems in parallel, sometimes with two portals, because consolidating them is a multi-year programme rather than a switch.

This is the plain reason a single login rarely shows you everything, and it is not a fault in the app you are using. If your results appear from the hospital but not from the laboratory that ran the test, you are probably looking at two organizations, two systems, and two separate answers to this page's question.

The useful habit is to hold the answer per organization rather than per person. Keep a short list: who holds which record, on which system, through which portal.

What to do once you know

If the answer is Epic, Sahara may be able to connect, subject to your healthcare organization enabling third-party app access and to what that organization returns. You can look at a demonstration record first, without connecting anything or creating an account, and decide afterwards.

If the answer is Oracle Health, MEDITECH, athenahealth, or any other system, Sahara cannot connect to it and there is no workaround worth your time. Use the portal your organization provides. Nothing about your legal position changes: your right to obtain a copy of your own record runs against the organization that holds it, not against whichever software it happens to run, and that route is set out separately in our guide to your rights over your own record.

Whatever the vendor turns out to be, the mechanics of connecting an app are broadly the same across certified products. You authenticate on your organization's own login page rather than in the app, read-only access means the app writes nothing back into the record, and revoking access stops future data flowing without deleting what an app already holds. Those points are covered in the rights guide rather than repeated here.

Limits to keep visible

• This page is general information about how to identify software. It is not legal advice and it is not medical advice.
• Every source linked below was checked on September 10, 2026. Vendor product names, ownership, and published lists all change, so recheck before relying on a detail.
• An entry in a published endpoint list describes an API connection. It does not tell you what your organization has enabled for patients, which records are available, or whether a particular app will appear as an option.
• Absence from a list is not proof of absence. Organizations are frequently listed under a parent entity's legal name.
• The certified product list catalogues products and developers. It does not record which organization bought which product.
• Sahara connects through Epic MyChart today and is not connected to Oracle Health, MEDITECH, or athenahealth. Availability and returned data vary by healthcare organization.
• Synodha holds no security certification and no regulatory clearance, and Sahara is not endorsed by Epic, by any other health IT developer, or by any health system.

How this guide was prepared

Synodha's editorial team prepared this guide from the official sources listed below, checked the product statements against Sahara's current documented scope, and separated general education from patient-specific interpretation. No clinician review is claimed. This guide is educational and does not replace the source record, discharge instructions, a professional interpreter, or the care team.

Last reviewed September 10, 2026. Recheck the linked sources and the healthcare organization's current instructions before acting on health information.

Primary sources and scope

These official sources establish the current proxy-access, app-access, and patient-education context used in this guide. They do not endorse Synodha or Sahara.

• ASTP/ONC: test procedure for the standardized API for patient and population services, including the public service base URL requirement
• ASTP/ONC: Certified Health IT Product List
• ONC: Lantern, the FHIR API monitoring system
• Epic: public list of FHIR endpoints and the organizations that expose them
• MyChart: the patient site, which states that MyChart is licensed from Epic Systems Corporation

Related Synodha resources

• Your rights to your own health record, and how to use them
• Look up what your health system requires for proxy access
• How authorized caregiver access to MyChart works
• See a demo record before connecting anything
• Explore Sahara
• What Synodha does and does not hold
• Browse all US healthcare guides