Source-linked, operation-specific evidence
Compare public APIs, FHIR and HL7 capabilities, partner requirements, sandbox access, documented write operations, and workflows that still end at the UI.
Evidence explorer
Statuses describe the reviewed public evidence—not every contract, version, or local configuration.
Start with the official interface catalog. Treat write-back as operation-specific, not as a platform-wide yes or no.
Access path
Public developer docs and sandbox; production access depends on the organization and interface
There is a credible direct API path for documented operations. Validate the exact method and authorization context before designing around it.
Access path
Public API catalog with SMART authorization; production use requires an authorized deployment context
Use the direct API first when the target operation appears in the catalog. Confirm customer authorization and workflow-specific requirements.
Access path
Public documentation; OAuth and customer authorization apply
Do not interpret public patient-access documentation as proof of operational writes. Escalate the exact workflow for vendor and customer review.
Access path
Public patient-access FHIR documentation; operational integration details require vendor or site review
Register in the developer program and verify the target operation before assuming either read or write behavior.
Access path
Developer portal account and review; customer authorization may apply
Use the public overview to identify the product family, then confirm the exact operation inside the portal.
Access path
Public overview plus authenticated developer portal and onboarding
The public path is unusually legible. Verify the target resource method and deployment tier before implementation.
Access path
Public FHIR docs and sandbox credentials; EHR launch and production setup depend on tier and client configuration
A documented integration path exists, but production viability depends on app type, resource method, product, and client permission.
Access path
Public docs and app registration; backend service access requires client permission
The proprietary API is the primary path and appears broad, but access is gated. Verify the exact method after licensing.
Access path
Developer license request with a documented testing sandbox
Treat the partner program as the primary route. No broad public claim about write operations is justified from the reviewed pages.
Access path
Marketplace or Amplify partner program access
There is a documented API route, but it is agreement-gated and application-specific.
Access path
Commercial agreement and application review required
The supported route is a vendor partnership, not an anonymous public API. Product version and operation determine availability.
Access path
Authorized vendor program or product-specific API program
A documented API path exists, but operation availability and commercial access should be verified for the exact account.
Access path
Customer key and security permissions; partner terms may apply
Workflow index
Each guide separates the system-of-record write, authorization path, verification step, and UI fallback.
Create, reschedule, cancel, or reconcile appointments.
02Create or update identity, contact, and coverage-adjacent fields.
03Attach documents, route notes, and verify chart placement.
04Enter or reconcile charges, codes, and claim state.
05Convert inbound referrals into structured records and work items.
06Update queues, tasks, dispositions, and follow-up state.
A public research artifact
Every profile links to its evidence and carries a review date. Absence of evidence is never labeled proof of non-support.