External Integrations Catalog

Documentation Index

Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt

Use this file to discover all available pages before exploring further.

​

Quick Reference

​

Status Legend

• ✅ Implemented - Integrated and operational
• 🟡 In Progress - Implementation underway
• ⚠️ Blocked - Requires external verification or is blocked by external requirements (e.g., OAuth app verification, vendor approval)
• 📝 Planned - Specified; not yet implemented

​

Catalog

​

Integration Engine Strategy

• Abstraction layer so EHR does not hard-depend on one engine
• Standards-first payloads (FHIR, X12, NCPDP, C-CDA) with contract tests
• Interface catalog (data contracts, endpoints, versioning, monitoring) as a first-class artifact

​

Decision Tree(s)

1. Is the integration external (clearinghouse, payer, PDMP, HIE, eRx, lab)? → Use this catalog and API Contracts / Event Contracts for in-platform contracts that wrap external APIs.
2. Is the payload standardized (X12, FHIR, NCPDP)? → Prefer standards-first contracts and abstraction; avoid vendor-specific formats in core.
3. Does the integration require audit or consent (e.g. PDMP, Part 2)? → Document in spec (CL-17, CL-11) and use platform consent/layers.
4. Is it real-time (eligibility, claim status) vs batch (837 submission, 835 posting)? → Define SLA, timeout, and retry in API contract.

​

Pattern Library

• Abstraction layer: All external calls go through an adapter or edge function; no direct vendor SDK in core. See Integration Engine Strategy.
• Standards-first contracts: Define request/response shapes using FHIR, X12, or NCPDP types; validate with contract tests before going live.
• Interface catalog: Each integration has a catalog entry (name, type, standard, status, spec), plus documented endpoints and payload samples (see code examples below).

​

Common Mistakes

​

Pre-Flight Checklist

• Standards: Payload and endpoint match the chosen standard (FHIR R4, X12, NCPDP) and version.
• Contracts: Request/response schemas and error codes documented in API Contracts or event payload in Event Contracts.
• Monitoring: Health check and latency/error metrics for the external endpoint; alerts on failure or SLA breach.
• Versioning: Contract version and external API version documented; upgrade path for breaking changes.
• Consent/Audit: If PDMP or Part 2–related, consent and audit requirements implemented per CL-17/CL-11.

​

Data Flow, Authentication & Monitoring (Per Integration)

​

Clearinghouse (PM-15)

• Data flow: App → Edge function or backend → Clearinghouse (SFTP or API). Outbound: 837P/I, 270, 276, 278. Inbound: 835, 271, 277, 999. Batch and/or real-time per contract.
• Authentication: TLS 1.2+; credentials (SFTP key or API key) in secrets; no credentials in code.
• Sandbox/testing: Use clearinghouse test environment; separate config for prod vs test.
• Error handling: Retry 5xx/network with backoff; rejections (999/277) logged and routed to correction workflow; DLQ for repeated failures.
• Monitoring: Health check (connectivity + test transaction); latency p95; error rate; alert on SLA breach or connection failure.

​

Payer ePA (PM-10)

• Data flow: App → FHIR Da Vinci CRD/DTR/PAS endpoint. Request/response per CMS-0057-F.
• Authentication: OAuth2 or API key per payer; store in secrets.
• Sandbox: Payer sandbox for development; document base URLs per environment.
• Error handling: Retry 429/5xx; return structured error to user; log request_id for support.
• Monitoring: Latency; success vs denial rate; alert on payer endpoint down.

​

Arizona CSPMP / PDMP (CL-17)

• Data flow: App → State PMP Gateway or HIE; query-in-workflow; response stored for audit only (no PII in logs).
• Authentication: State-issued credentials; certificate or API key per state requirements.
• Sandbox: State test environment if available.
• Error handling: Fail closed (do not prescribe without PDMP when required); log query_id only; audit per CL-17.
• Monitoring: Query success rate; latency; alerts on gateway errors.

​

Contexture (AZ HIE) (CL-12, CL-16)

• Data flow: DirectTrust or XDS/XCA; ADT and C-CDA document exchange. Outbound: C-CDA 2.1; Inbound: documents and ADT.
• Authentication: DirectTrust certificate; enrollment and onboarding per Contexture.
• Sandbox: HIE test environment.
• Error handling: Retry transient; log document_id and outcome; no PHI in logs.
• Monitoring: Submission success; document retrieval latency; certificate expiry alerts.

​

EPCS / Surescripts (CL-06)

• Data flow: NCPDP SCRIPT 2023011 to Surescripts; two-factor auth; prescription and status.
• Authentication: EPCS credentials (hardware or software token); FIPS 140-2 where required.
• Sandbox: Surescripts test environment.
• Error handling: Prescription failure returned to user; no retry of invalid sig; audit all attempts.
• Monitoring: Send success rate; response latency; token/credential expiry.

​

Lab / LIS (CL-09)

• Data flow: HL7v2 or FHIR DiagnosticReport; order outbound; results inbound.
• Authentication: Lab-specific (often VPN or HL7 MLLP with mutual TLS).
• Sandbox: Lab test environment or mock.
• Error handling: Retry HL7 NAK; map errors to user message; log order_id only.
• Monitoring: Order and result throughput; error rate; interface uptime.

​

Integration Adapter Pattern

• Map internal IDs to external identifiers.
• Transform request/response to/from standard shapes (FHIR, X12, NCPDP).
• Apply authentication and retry.
• Log metrics and errors (no PII/PHI).
• Support feature-flag or config to switch environments (sandbox vs prod).

​

Code Examples (Contract / Endpoint / Payload)

GET /fhir/r4/Patient/{id}
Accept: application/fhir+json

ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *260216*1200*^*00501*000000001*0*P*>
GS*HS*SENDER*RECEIVER*20260216*1200*1*X*005010X279A1
ST*270*0001*005010X279A1
BHT*0022*11*REF123*20260216*1200*CH
HL*1*0*20*1
NM1*1P*2*ORG*****PI*12345
...
SE*...
GE*1*1
IEA*1*000000001

Segment: Prescription (simplified)
- Patient ID, Drug, Sig, Quantity, Refills per NCPDP SCRIPT 2023011

​

Microsoft 365 Deep Integrations (PF-63)

​

Related Documentation

• Event Contracts - CL/PM planned events
• API Contracts - CL/PM planned APIs
• Platform Integration Layers - CL/PM planned platform layers
• CROSS_CORE_INTEGRATIONS - Cross-core matrix
• EHR_PM_PLANNING_BUNDLE - Planning source