Pair the eClinicalWorks FHIR API with the BloomText API to send patient messages from your own software.
Get started for freeSchedule a demo →Yes. eClinicalWorks publishes free FHIR APIs for reading patient data, and the BloomText API sends the messages. Your app matches each eClinicalWorks patient to a BloomText patient by MRN, and scheduling data comes through eClinicalWorks' separate healow portal.
Your app reads patients, plus appointments through healow through eClinicalWorks’s API.
It looks up each patient’s BloomText conversation in a simple mapping your app keeps.
It sends reminders and replies with the BloomText API, and reads new patient replies by time range.
eClinicalWorks stays your system of record. BloomText handles the conversations, and nothing syncs until your app connects the two.
Read the patient from eClinicalWorks, find the matching BloomText patient by MRN, then send the message to that patient. Store the eClinicalWorks patient ID as the BloomText patient’s MRN; nothing maps automatically.
GET https://staging-fhir.ecwcloud.com/fhir/r4/<approved-practice-id>/Patient/<approved-patient-id>Accept: application/json+fhirAuthorization: Bearer <approved-oauth2-token>Use the base URL, access token, and IDs from your approved vendor environment.
See eClinicalWorks Patient read PDF for the full request.
GET https://api.bloomtext.com/v1/patient-messages?patient_id={patientId}&q=from:patient&page[limit]=50Authorization: Bearer <api-key>POST https://api.bloomtext.com/v1/patient-messagesAuthorization: Bearer <api-key>Idempotency-Key: <unique-request-key>Content-Type: application/json{"to":{"patient_id":"{patientId}"},"body":"Reminder: you have an appointment tomorrow at 9:30 AM."}Send your organization’s BloomText API key in the Authorization header on every request. POST requests also need Idempotency-Key and Content-Type headers.
eClinicalWorks splits its developer access in two: provider-facing FHIR APIs on the Open Developer portal, and patient-facing and scheduling APIs on the healow Developer Portal. Read APIs are documented openly. Write APIs, such as adding a note to the chart, need a contract with eClinicalWorks.
The eClinicalWorks Patient search accepts last name, first name, and a 10-digit phone number together. When staff link a BloomText patient to a chart, your app runs that search and saves the eCW patient ID as the BloomText patient’s MRN only if exactly one patient comes back.
Uses eClinicalWorks FHIR Patient search
eClinicalWorks documents a Communication create API that adds a note to the patient’s App Data tab as a checklist item. After your app texts a patient, it can leave a one-line note like "Reminder texted 9/22" so the next person who opens the chart knows it was sent.
Uses eClinicalWorks Communication create API (contract required)
The FHIR Patient record carries the patient’s primary care provider. When a patient replies in BloomText, your app looks up that provider and posts a heads-up in the matching team conversation, so a busy multi-provider clinic doesn’t leave replies sitting in a shared queue.
Uses eClinicalWorks FHIR Patient (general practitioner field)
eClinicalWorks lists a create API for Telephone Encounters, the record staff already use to document calls. When a patient asks for a callback over text, your app can open a telephone encounter so the request lands in the usual eCW workflow.
Uses eClinicalWorks Encounter (Telephone Encounters) create API (contract required)
Many eCW practices already send automated reminders through eClinicalMessenger. Keep those, and use BloomText for the next step: if your healow-approved scheduling integration shows a visit still unconfirmed the day before, a staff member follows up personally in the patient’s conversation.
Uses healow scheduling APIs, if your app is approved for them
Patient requests use your organization’s BloomText API key. Posts to a staff team conversation use an org admin’s OAuth token instead, and only reach conversations that admin is part of.
A small admin screen where staff type a patient’s name and phone, confirm the eCW match, and save the eCW patient ID on the BloomText patient.
GET https://<approved-ecw-fhir-host>/fhir/r4/<approved-practice-code>/Patient?family=<last-name>&given=<first-name>&phone=<10-digit-phone>Accept: application/json+fhirAuthorization: Bearer <approved-oauth2-token>PATCH https://api.bloomtext.com/v1/patients/{patientId}Authorization: Bearer <api-key>Content-Type: application/json{"mrn":"<approved-patient-id>"}POST https://api.bloomtext.com/v1/patient-messagesAuthorization: Bearer <api-key>Idempotency-Key: <unique-request-key>Content-Type: application/json{"to":{"patient_id":"{patientId}"},"body":"You’re all set to text our office here. We’ll reply during clinic hours."}Send the reminder in BloomText, then add a checklist note to the patient’s App Data tab in eClinicalWorks.
POST https://api.bloomtext.com/v1/patient-messagesAuthorization: Bearer <api-key>Idempotency-Key: <unique-request-key>Content-Type: application/json{"to":{"patient_id":"{patientId}"},"body":"Reminder: your visit is tomorrow at 10:20 AM."}POST https://<approved-ecw-fhir-host>/fhir/r4/<approved-practice-code>Content-Type: application/fhir+jsonAuthorization: Bearer <approved-oauth2-token>{"resourceType":"Bundle","type":"transaction","entry":[{"resource":{"resourceType":"Communication","status":"preparation","payload":[{"contentString":"Appointment reminder texted 9/22."}],"subject":{"reference":"Patient/<approved-patient-id>"}},"request":{"method":"POST","url":"Communication"}}]}When a patient texts in, notify the team of the provider listed as their PCP in eClinicalWorks.
GET https://api.bloomtext.com/v1/patient-messages?after={lastChecked}&q=from:patientAuthorization: Bearer <api-key>GET https://<approved-ecw-fhir-host>/fhir/r4/<approved-practice-code>/Patient/<approved-patient-id>Accept: application/json+fhirAuthorization: Bearer <approved-oauth2-token>POST https://api.bloomtext.com/v1/me/conversations/{pcpTeamConversationId}/messagesAuthorization: Bearer <org-admin-oauth-token>Idempotency-Key: <unique-request-key>Content-Type: application/json{"body":"New patient reply waiting in BloomText for Dr. Example’s panel. Initials: R.M."}In a busy primary care or community health center, an agent connected to eClinicalWorks and BloomText can sort incoming patient texts, route them to the right provider’s team, and draft replies to routine questions like office hours or form links for staff to send.
An org admin creates an API key in BloomText. Your agent’s tools use it to message patients and read their replies, always naming the patient by ID, phone number, or MRN. The key can’t reach staff conversations; for those, the agent uses an org admin’s OAuth token, which reaches only the conversations that admin is part of.
GET https://api.bloomtext.com/v1/organizationAuthorization: Bearer <api-key>eClinicalWorks does not document an MCP server, so write your own tools that call its FHIR API with your approved OAuth2 credentials, such as "find patient by name and phone" and "get patient PCP". Put your own throttle in front of them, because eCW limits each base URL to 250 calls per minute.
q=is:unread.Check BloomText for patient messages from the last 15 minutes that nobody has answered. For each one, use the eCW tool to find the patient’s PCP and post "<initials> is waiting for a reply" in that PCP’s team conversation. If the question is about hours, directions, or forms, draft a reply there too. Don’t send anything to the patient yourself.Messages the agent sends with the key show the key’s name to staff, and patients see your clinic. An org admin can delete the key at any time. Read the AI agent docs.
Yes. eClinicalWorks publishes FHIR R4 APIs on its Open Developer portal, covering USCDI read APIs such as Patient, Encounter, and DocumentReference, plus create APIs for things like Communication notes and telephone encounters. Each practice has its own base URL under /fhir/r4/{practice_code}. Patient-facing apps use the separate healow Developer Portal.
Sign up on the Open Developer portal, register your app, test it, publish it to production, and then connect to eClinicalWorks customers who enable it. Server-to-server apps use Backend Services, and practices can enable bulk patient groups for them. Create APIs need a contract, which starts with interop@eclinicalworks.com.
Not from the provider FHIR read APIs. The Open Developer documentation sends developers who need scheduling to the healow Developer Portal, which has its own sign-up and review. Plan for that second approval if your project depends on appointment times.
Yes. eClinicalMessenger sends automated reminders by voice, secure text, the healow app or patient portal, and email, and appointment confirmations flow back into the eCW schedule. If a practice already runs those reminders, use BloomText for the conversations your own software drives and for staff chat, not a second reminder.
Yes, with tools you build. eClinicalWorks does not document an MCP server, so wrap the FHIR calls your app is approved for as agent tools and add BloomText API tools for messaging, using an organization API key. Keep the 250 calls per minute limit in mind when an agent loops over many patients.
It can be when each party that touches PHI is covered. BloomText turns on API access only for organizations with a signed BAA, and your access to eClinicalWorks data runs under the practice’s authorization and any eCW contract. Keep texts to logistics like times and links, and leave clinical detail in the chart.
eClinicalWorks' Open Developer FHIR documentation is free for certified APIs. Wider production use goes through its partner process, and scheduling APIs live on the healow Developer Portal.
API access is available to organizations with a signed BAA. Book a short call, tell us what you’re building, and we’ll turn on API access so an org admin can create your key. Don’t include PHI when you book.
Links last checked September 21, 2026.
