It’s an ONC Cures Rule maintenance of certification requirement for certification criterion Standardized API for Patient and Population Services 170.315(g)(10) for certified API developers to publish service base URLs for all customers in a machine-readable format.

Regulatory Text: 45 CFR 170.404(b)(2) Certified API Developers must publish service base URLs for all Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI.
Certified API Developers must publicly publish service base URLs for all customers in a machine-readable format at no charge.

As discussed in section VIII.C.6.c of the ONC Cures Act Final Rule, API Information Sources who locally manage their FHIR servers without Certified API Developer assistance cannot refuse to provide to Certified API Developers the FHIR service base URL(s) that is/are necessary for patients to use to access their EHI. Equally, pursuant to this Maintenance of Certification requirement, they would be required to publish the FHIR service base URLs they centrally manage on behalf of API Information Sources.

https://www.healthit.gov/sites/default/files/2021-12/Lantern-webinar_508.pdf

EMR Vendors & Market Share

FHIR Sandboxes

EPIC SOURCES

FHIR Endpoint Discovery

patient app registration-who’s misinformed at the ONC Forum?

Here is our general experience for open developer environments. The problem is essentially endpoint discovery and whitelisting. Please note that not all vendors are included below. However, OneRecord is patiently waiting for ALL endpoints to be published by ALL vendors with no whitelisting :)

Epic: You get a single set of creds (client ID and secret) to connect to all Epic sites. All endpoints published. ( This is the easiest method for patient-facing apps.)

Cerner: You get a single set of creds (client ID and secret) to connect to all Cerner sites (like Epic) BUT whitelisting is required.

eCW: You get a single set of creds (client ID and secret) to connect to all eCW sites (Like Cerner) BUT whitelisting is required.

Allscripts: You get different creds (client ID and secret) for each client to connect to Allscripts sites AND whitelisting is required.

Meditech: You get different creds (client ID and secret) for each client to connect to Meditech sites (like Allscripts) AND whitelisting is required.

NextGen: You get different creds (client ID and secret) for each client to connect to NextGen sites AND whitelisting is required.

Athena: To date does not support 3 Legged OAUTH

Ultimately you are going to see some sort of configuration that follows the patterns above and as @Debi Willis said “it’s an Olympic exercise” to find the right stakeholder to get whitelisted…even at the patient request.

https://chat.fhir.org/#narrow/stream/179262-patient-empowerment/topic/patient.20app.20registration-who’s.20misinformed.20at.20the.20ONC.20Forum.3F

FHIR Source Directories

Example Datasets / Synthetic Data

Personal Health Record Standard

https://launch.smarthealthit.org/?auth_error=&fhir_version_2=r4&iss=&launch_pt=1&launch_url=&patient=&prov_skip_auth=1&provider=&pt_skip_auth=1&public_key=&sde=&token_lifetime=15&user_pt=