Models & integrations
Implementation reference · Sources checked September 13, 2026
What the API connects
The notes describe a coordination team re-entering requests into pharmacy portals. My interpretation: the first useful integration replaces that handoff and brings pharmacy responses back.
- Provider systemEMR, intake, or storefront sends patient and order context.
- SultanRxA coordinator sources, quotes, and routes the request.
- Pharmacy systemReceives the order and returns review, fill, cancellation, and shipment updates.
A separate prescribing service or network may carry the authorized prescription. A storefront purchase is a commercial order, not prescription authorization. “Coordinator” describes the middle team’s work; sales is its account acquisition function.
Concrete integration targets
Foundation Health · documented network API
U.S. sandbox: https://sandbox-us.foundationhealth.com. Production: https://api-us.foundationhealth.com. Credentials require onboarding.
POST /orders- Create a fulfillment order.
GET /orders/{orderId}- Retrieve its state.
POST /orders/{orderId}/cancel- Request cancellation; approval may be pending.
POST /webhooks- Register a receiving URL for callbacks.
This is a candidate vendor integration, not an existing SultanRx connection or a universal pharmacy API. Official API documentation.
LifeFile · the selected pharmacy’s instance
CarePortals documents an adapter configured with a pharmacy-supplied URL, credentials, and routing IDs. Its example base URL is https://pharmacy-partner.LifeFile.net/lfapi/v1—a placeholder, not a verified live endpoint. The guide does not establish the exact create-order HTTP path or a complete LifeFile contract. CarePortals integration guide.
Surescripts · electronic prescribing
A separate integration path for prescription exchange, with onboarding and certification tooling. Select it with the prescribing partner; it does not replace the fulfillment workflow. Surescripts developer portal.
Healthcare entities
FHIR R4 is the reference model here. The demo uses a custom schema and custom pharmacy packets; it does not implement FHIR resources, profiles, or conformance validation.
| Concept and reference | In this demo | Still needed |
|---|---|---|
| People and organizations | Patient, practice, pharmacy, and saved clinician profiles separate from login accounts. Requests retain a prescriber snapshot. | Delegated practice staff, verified external identifiers, and locations. |
| Medication and prescription | Independent, immutable prescription versions linked to orders and fulfillment snapshots. | Coded medication, compound ingredients, route, and units; agreed profile validation. |
| Dispensing and work | Separate fulfillment requests and dispense records; distinct receipt, review, shipment, and delivery steps. | Refills and partial fills are not implemented. This simulator records one complete fill per request. |
| Clinical context and questions | Free-text allergy and medication context; provider–pharmacy clarification. | Structured context with source and date. A clarification message does not authorize a prescription change. |
| Documents and evidence | Restricted attachments, actor timestamps, and exchange history. | Document provenance and access auditing. An order timeline is not a complete security audit log. |
Quotes, charges, supplier invoices, and shipments remain distinct business records. A prescription describes authorized treatment; a dispense records a fill; a shipment records transport.
Formats, terminology, and identifiers
- FHIR and NCPDP SCRIPT
- Agree the FHIR version and profiles with the partner. U.S. electronic prescription exchange also uses NCPDP SCRIPT; FHIR-shaped JSON alone is not an e-prescription connection. HealthIT.gov reference.
- Medication codes
- RxNorm for normalized drug concepts; NDC for listed drug products and packages where applicable. Preserve pharmacy SKUs and compounded ingredients explicitly; do not invent a code match.
- Quantities and units
- UCUM for coded units where appropriate. Keep dose, concentration, prescribed quantity, dispensed quantity, and package count distinct.
- Identity
- Keep internal IDs separate from partner IDs and provider identifiers. Each external identifier needs its assigning system; a synthetic demo identifier is not a verified NPI.
Try the local integration
The pharmacy simulator receives requests over a signed local HTTP API. A durable queue records attempts and supports held deliveries, temporary failures, lost acknowledgments, and exact message replay. The coordinator’s Simulator exchange page shows the results.
Prescription versions, fulfillment requests, and dispenses are linked records. No real pharmacy or prescribing network is connected. The pharmacy workspace emulates the receiving system; one pending message per request keeps the local simulation sequential.
Return to demo accounts