CharmHealth integration · United States
We build CharmHealth integrations for digital health products and practices on CharmHealth EHR. CharmHealth documents a certified FHIR R4 API for reading patient records and runs an API program for broader access by request. We handle the license and access steps with you, build the SMART or backend app, and set up each practice's authorization.
Submit CharmHealth's API access request, sign the API License Agreement and receive a client ID and secret.
The developer license includes a sandbox. We build the patient, provider or backend app against it.
A practice administrator authorizes the app with an API key before it can read that practice's data.
The problem
Teams building on CharmHealth for small practices run into these four problems first.
The code is ready, but the access request and license agreement are still being worked out.
Each practice administrator has to authorize your app, and some never get to it.
Your roadmap assumed you could write care plans or appointments, and the FHIR API is for reading.
Population reports depend on someone exporting data by hand every month.
Use cases
Four use cases, each shown as the screen your team works in. The people and organizations are fictional; the behavior follows the vendor's published documentation.
Nobody knows which practices have authorized the app and which are waiting.
Each practice shows whether its administrator has authorized the app, when data was last read, and what to do when access is revoked.
Patients type their medications and allergies into your app from memory.
Patients connect with SMART App Launch and their CharmHealth PHR sign-in, and your app reads their medications, allergies, problems, results and visits.
Staff export spreadsheets every month for population reports.
Backend services run FHIR bulk export and C-CDA jobs for each authorized practice, and files land in your secure store on a schedule.
The team discovers in week six that a feature needs a write the API does not offer.
Each product need is mapped to FHIR reads, bulk export or the API program before the build, so writes go into the access request from day one.
First call
The answers decide the route, the timeline and where these projects usually go wrong. You do not need them all before we talk.
FHIR covers reads; writes need the API program.
Each uses a different authorization flow.
Practice authorization is the step most likely to slow rollout.
The license and sandbox follow from it.
Bulk export and C-CDA add storage and retention design.
CharmHealth's development license excludes support unless you add an agreement.
Webhooks are not in CharmHealth's own docs, so we confirm before designing around them.
Your product should pause cleanly and tell someone.
The short answer
Yes. CharmHealth documents a FHIR R4 API built to version 4.0.1 and US Core 6.1.0 under the 2015 Edition Cures Update criteria, with SMART App Launch for patient and provider apps and SMART Backend Services for system access. Its FHIR resources are documented as list, get and search operations, plus C-CDA and bulk export, so the FHIR route is for reading data. CharmHealth also runs an API program described as a comprehensive set of REST APIs, reached through an access request. Access needs a signed API License Agreement with MedicalMine, CharmHealth's company, and each practice administrator must authorize the app.
CharmHealth APIs
From CharmHealth's FHIR API documentation, API program page and API terms of service, read in October 2026.
| Route | What it covers | Access | What to plan for |
|---|---|---|---|
| FHIR R4 patient-facing apps | A patient's own record through SMART App Launch | The patient signs in with CharmHealth PHR credentials | Read and search operations on US Core resources |
| FHIR R4 provider-facing apps | Clinician apps launched inside or outside the EHR | The provider signs in with CharmHealth EHR credentials | Read and search; launch context and scopes |
| FHIR backend services | System-to-system access, including bulk export | SMART Backend Services with a signed JWT client assertion | Practice administrator authorization with an API key |
| C-CDA and bulk export | Documents and data for a group of patients | Through the FHIR program | Export jobs and file handling on your side |
| CharmHealth API program | A broader set of REST APIs for medical applications and devices | API access request form, reviewed by CharmHealth | Scope, fees and terms agreed in your license |
A consultancy guide describes CharmHealth webhooks, but CharmHealth's own documentation does not describe them, so we confirm event support with CharmHealth before designing around it.
What we build
Pick the workstreams you need. Each one ships with a specification, sandbox tests and an owner.
A patient-facing app that reads the patient's own CharmHealth record after the patient signs in.
SMART App Launch · OAuth 2.0 · US Core
SMART on FHIR app development →A clinician-facing app launched from or alongside CharmHealth EHR with the right patient in context.
EHR launch · scopes · patient context
SMART on FHIR app development →A backend service that reads practice data on a schedule after the practice administrator authorizes it.
SMART Backend Services · JWT client assertion
FHIR integration services →Bulk export jobs and C-CDA handling for analytics, population health or migration, with files stored and processed securely.
Bulk Data · C-CDA · job status
Where your workflow needs more than FHIR reads, we prepare the API access request and build against the APIs CharmHealth grants.
API access request · license scope
Token and authorization checks per practice, alerts on failures and redacted operational logs.
Token health · alerts · runbook
Integration monitoring and support →Buyer decisions
Most products start with FHIR reads and add the API program only where they need it.
| Option | Best fit | Strengths | What to plan for |
|---|---|---|---|
| FHIR R4 API | Patient apps, clinician read apps, analytics | Certified, standard US Core resources | Read and search only; license and practice authorization |
| CharmHealth API program | Workflows that need more than FHIR reads | Broader REST APIs by agreement | Access request, scope and fees set by CharmHealth |
| Exports | One-time migrations | No build on CharmHealth's side | Manual steps and no ongoing sync |
| Login-based automation | A gap no API covers | Works where APIs stop | CharmHealth's terms, the practice's written authorization and strict controls |
Integration boundaries
We write the split down before the build starts.
Authorizes your app with an API key and approves what data it reads.
Owns the APIs, the license terms, access decisions and fees. The developer license includes a sandbox but not technical support unless you add a support agreement.
Owns what your product does with CharmHealth data and how it appears to users.
Apps, connectors, token handling, export pipelines and alerts. Defects in this layer are ours to fix.
A BAA is available for agreed work involving PHI. We work inside our ISO 27001:2022 certified management system, encrypt data in transit and at rest, keep credentials in a vault and keep raw payloads out of operational logs.
Deliverables
Everything lands in your repository and your runbook.
The completed access request, the use case description and the license questions to settle with CharmHealth.
SMART or backend clients, export handling and data mapping.
How a practice administrator authorizes your app.
Sandbox test runs, alerts and support steps.
Delivery phases
Initial planning estimate: 5 to 9 weeks to a first live practice, subject to CharmHealth's access review and license, and practice authorization. We confirm a release plan after discovery.
Weeks 1 to 2
Route chosen, access request and license questions sent
Weeks 2 to 6
App or backend service built and tested in the sandbox
Weeks 4 to 8
First practice authorizes the app, data checked with the practice
Weeks 6 to 9
First practice live, monitoring on, checklist handed over
Cost drivers
Use the scoping call to pin down the workflow, the access you need and what goes into a scoped proposal. These are the factors that move cost.
FHIR reads are the simplest; the API program adds scope and license work.
Patient, provider and backend apps each have their own authorization flow.
Export pipelines add storage, processing and retention design.
A repeatable authorization checklist matters most at scale.
Monitoring and on-call support are priced per connection.
Proof
Client names are withheld. These published guides show how we approach FHIR and SMART work; they do not prove CharmHealth approval or a live CharmHealth integration.
How certified EHR APIs differ in scopes, launch and write support, and what that means for a product serving several EHRs.
Read the guide →What to do when a certified API is read only and your workflow needs more.
Read the guide →How documents move between systems when an API does not cover them.
Read the guide →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
Yes. CharmHealth documents a FHIR R4 API to US Core 6.1.0 with SMART App Launch and backend services, and runs an API program with a broader set of REST APIs available by access request.
The FHIR resources are documented as list, get and search operations, plus C-CDA and bulk export, so plan on FHIR for reading. For writes, ask CharmHealth what its API program grants for your use case.
Submit CharmHealth's API access request with your contact details and planned application, sign the API License Agreement, and receive a client ID and, for confidential clients, a client secret.
Yes. CharmHealth's documentation says the practice administrator must authorize third-party applications to access their data through an API key.
Yes. CharmHealth's API terms say a sandbox environment is provided for development under the developer license.
A consultancy guide describes them, but CharmHealth's own documentation does not describe webhooks. We confirm event support with CharmHealth before relying on it and poll where needed.
CharmHealth's API terms say the development license does not include technical support or bug fixes. Support needs a separate agreement, and license pricing is set in your terms.
Yes. Patient-facing apps use SMART App Launch, and the patient signs in with CharmHealth PHR credentials to share their own record.
Yes, through the FHIR bulk export and C-CDA options, once the practice has authorized your backend app.
Our initial planning estimate is 5 to 9 weeks to a first live practice, mostly set by CharmHealth's access review and the first practice's authorization.
Cost depends on the route, the app type, bulk data needs, how many practices you add and the support level. CharmHealth's own license fees are separate. After a scoping call we send a scoped proposal with the access dependencies listed.
Next step
Tell us what your product needs from CharmHealth. An engineer replies with the route, the access steps and the open license questions.
Start with your workflow
Share the use case, the number of practices and your target date. Use de-identified examples only. Read by an engineer, answered within one business day.
