ChartlineGHL ↔ EMR bridge

Connect GoHighLevel

Point the AI receptionist at this bridge. Every tool below is a custom action: same URL pattern, same auth header, same JSON body.

1. Bridge address and key
Each custom action in GoHighLevel sends a POST with a JSON body and an Authorization header.
Base URLhttp://localhost:43117
HeaderAuthorization: Bearer ${BRIDGE_API_KEY}

Set BRIDGE_API_KEYS in the environment to a comma-separated list of keys — one per clinic, so a key can be rotated for one customer without disturbing the others. While it is unset, the bridge runs unauthenticated against the simulated clinic for local development and refuses to start unauthenticated in production.

2. Custom actions
Create one action per tool. Always pass callId — it is how the bridge links the caller's identity check to the rest of the conversation — and pass callerPhone so caller ID can be used as a verification factor.
3. Agent instructions
Paste this into the GoHighLevel agent's prompt. It is served from the bridge so the rules and the enforcement cannot drift apart — but note that the prompt is the polite version of the rules. Verification is enforced in code, not by asking the model nicely.
4. What to get from the EMR vendor
The code is done; this list is what the project is actually waiting on.
  1. 1

    Developer account on the vendor's API portal

    Self-service for Epic and athenahealth. eClinicalWorks routes through their interoperability team, so it starts as an email rather than a signup form.

  2. 2

    A sandbox tenant with synthetic patients

    Lets the integration be built and demonstrated without touching a real practice or a single real patient record.

  3. 3

    Registered client credentials

    A client id, and either a client secret or a public key you register for signed JWT assertions. The bridge already supports both.

  4. 4

    The granted scope list, in writing

    This is the thing that decides what the product can do. Read scopes are the regulated floor; scheduling writes are a commercial negotiation.

  5. 5

    The practice's own FHIR base URL

    Every practice has a different endpoint. The vendor publishes a directory, and the practice has to authorise your app against their instance.

  6. 6

    A signed business associate agreement

    Required before any production patient data moves. Needed with the EMR vendor, the telephony provider, and whoever hosts the language model.

Vendor outreach emails

Ready-to-send messages for eClinicalWorks, athenahealth, Epic and the pilot practice.

docs/vendor-outreach.md

EMR access playbook

What each vendor's programme grants, what it takes to get it, and the order to approach them in.

docs/emr-access-playbook.md

Compliance checklist

BAAs, verification policy, audit retention and the decisions a clinic has to sign off on.

docs/compliance-checklist.md

Delivery plan

Phases, what gates each one, and the status update to send partners.

docs/delivery-plan.md