Empower Pharmacy

Your clinic never holds Empower credentials. Neolife holds them per-connection in a secret manager, enforces every compliance gate on each call, and proxies to Empower. Clinics integrate with neolife — via a neolife API key, the CLI, or MCP — and neolife talks to Empower. That single decision is what makes credential rotation, audit logging, and provider-enrollment enforcement possible.

How a clinic connects#

Four steps, in order. Steps 1–3 happen once per clinic; step 4 is live.

1 — Create the connection. In the clinic console: Settings → Pharmacies → connect Empower, with the clinic's Empower practice ID (Empower provisions one per clinic and exposes it through GET /Practices).

2 — Neolife holds the vendor credential. Empower's API key/secret pair goes into the secret manager under the connection's reference — never into a request body, never into a database column, never returned by any endpoint.

3 — Enroll the practice and providers. Empower verifies both manually before accepting anything:

• neolife empower readiness <tenantId> <connectionId> shows exactly what is outstanding.
• Send Empower the provider roster (neolife empower roster … produces it) and record their decisions with provider-set. Dispatch blocks for any prescriber that isn't approved — this is what protects rotating provider-network clinicians.
• Record the practice decision with practice-set.

4 — Sync the catalog. neolife empower catalog-sync … pulls Empower's product catalog (item designator IDs, strengths, forms, refrigerated/controlled flags, state-specific controlled data) into the clinic's product table. Orders can only reference SKUs from this sync.

Programmatic access — neolife API keys#

Clinics integrate against neolife's API, not Empower's:

# Ops mints a key for the clinic (plaintext shown once):
neolife api-keys ops-mint <tenantId> --name "boundless-prod"

# The clinic then calls neolife as themselves:
curl https://api.neolife.health/v1/products \
  -H "Authorization: Bearer nl_live_…"

Every call rides the same gates an interactive user would hit: enrollment checks before dispatch, sandbox-only submission until production certification, audit logging without PHI.

Operations — CLI and MCP (pass-through)#

All commands authenticate to neolife; nothing ever aims at empowerpharmacy.com directly:

Task	CLI	MCP tool
Live health check	empower health <tenant> <conn>	empower.health
Onboarding readiness	empower readiness …	empower.readiness
Provider roster export	empower roster …	empower.providers.roster
Record practice decision	empower practice-set …	empower.practice.set
Record provider decision	empower provider-set …	empower.provider.set
Pull discovery surfaces	empower discovery-sync …	empower.discovery.sync
Catalog pull	empower catalog-sync …	empower.catalog.sync
Webhook recovery	empower recover … --orders id1,id2	empower.webhook.recover

Order lifecycle over the wire#

An approved order becomes one EasyRx request: patient/prescriber/medication inside each newRxs[] entry, the clinic's practice ID, an exact shipping-service string, ICD-10 + last-office-visit date, SIG ≤175 characters, refills: 0 (Empower treats every order as a new prescription). Status returns via three webhooks — Received → Processing → Complete (tracking) — reconciled by our order ID, authenticated by a static secret header configured in Empower's webhook UI, deduplicated on stable vendor IDs.

Environment boundary#

Connections declare their Empower environment. Sandbox submissions run freely in UAT; production submission is refused at the adapter until an explicit certification flag is enabled after Empower accepts the production validation order. See connection health for monitoring posture.