.png)
Redox Integration Guide
Connect Redox’s normalized healthcare data models with enterprise applications through authenticated REST APIs, configured webhooks, and Martini workflows.
Redox integration options at a glance
Redox provides an HTTP-based REST API for exchanging normalized healthcare data through named models such as PatientAdmin, ClinicalSummary, Scheduling, DiagnosticReport, Medications, and Financial. Configured webhook-style delivery supports asynchronous messages and responses, although coverage depends on the integration and data model. Redox uses application credentials to obtain bearer tokens, with separate environment and permission considerations. Martini can consume the REST API, securely manage credentials, transform source data into Redox payloads, expose endpoints for callbacks, correlate transmission identifiers, and route validation or processing failures for retry and review. HL7 v2 and FHIR may be involved behind Redox’s interoperability connections, but the application-facing integration is typically REST-based.
| Integration point | Supported by Redox? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Send and receive normalized healthcare data through Redox data models and retrieve API responses or status information. | Martini can consume the Redox HTTP API from workflows, construct requests, manage bearer authentication, transform payloads, and route responses or errors. |
| Webhooks / outbound callbacks | Limited | Deliver configured messages, responses, or processing notifications to an HTTPS endpoint. Coverage depends on the integration and data model. | Martini can expose an API endpoint or run a webhook-consuming workflow, validate callbacks, correlate transmissions, and invoke downstream processing. |
| Asynchronous processing | Yes | Support healthcare transactions where the initial request acknowledges receipt and a later response, status update, or callback contains the business result. | Martini workflows preserve transmission identifiers and application correlation IDs, then resume or complete processing when a callback arrives. |
| Healthcare data models | Yes | Exchange named models including PatientAdmin, ClinicalSummary, DiagnosticOrder, DiagnosticReport, Scheduling, Medications, AllergyIntolerance, and Financial. | Martini maps source data into Redox model payloads, validates required fields, preserves appropriate fields, and transforms responses for target systems. |
| Authentication | Yes | Use Redox application credentials to obtain an access token and send it in the HTTP Authorization Bearer header, subject to environment and permission configuration. | Martini stores credentials and environment configuration securely, obtains or uses tokens in REST workflows, and avoids exposing secrets in logs. |
| Bulk / batch APIs | Limited | Message-oriented asynchronous and batch handling may be available for particular use cases, but a universal bulk API was not confirmed. | Martini can implement controlled batching, scheduling, throttling, and checkpointing when the specific Redox integration supports those behaviors. |
| HL7 v2 and FHIR interoperability | Yes | Redox may translate connected healthcare-system messages and standards such as HL7 v2 or FHIR into normalized Redox data models. | Martini typically consumes the Redox REST representation and can transform it to or from enterprise formats without assuming direct access to every underlying standard interface. |
| SDKs | Not applicable | No Redox-specific SDK requirement was identified; the documented application-facing approach is an HTTP API. | Martini can integrate through REST and webhook endpoints without requiring a vendor SDK. |
How Redox exposes data and business events
Redox REST APIs
Redox provides an HTTP API for sending and receiving normalized healthcare data through named data models. Application credentials are used to obtain bearer access tokens, and the precise enabled models and permissions depend on the Redox environment and connected organization.
Martini implementation pattern
Martini implementation pattern: A workflow obtains configuration and credentials securely, calls the Redox REST API, transforms the request or response, records transmission and correlation identifiers, and routes validation or transport errors according to their severity.
Implementation sequence
Redox Webhooks
Redox supports webhook-style delivery for configured messages and responses. Delivery is configuration- and data-model-dependent and should not be assumed for every healthcare event.
Martini implementation pattern
Martini implementation pattern: Martini exposes a controlled API endpoint or webhook-consuming workflow, validates the incoming callback, correlates it with the originating transmission, maps the Redox model, and invokes downstream processing or review.
Implementation sequence
Asynchronous Redox Processing
Healthcare transactions commonly complete asynchronously. The initial Redox response may acknowledge receipt while a later response, status update, or callback contains the business result.
Martini implementation pattern
Martini implementation pattern: Martini separates submission from completion, persists correlation state, and uses a later callback or message to complete the workflow. This prevents an acknowledgement from being treated as final business success.
Implementation sequence
Common Redox integration patterns
Pattern 1: Synchronize patient administration with Redox
When to use this pattern
Use this pattern when registration, demographic, admission, discharge, or transfer information must move from an upstream application into a Redox-connected healthcare organization. It is appropriate for scheduled or upstream-triggered synchronization with validation and replay controls.
Integration direction
Example Mapping
| Redox Field | Canonical Field | Target Field |
|---|---|---|
| patient identifier | patientId | PatientAdmin.patient.identifier |
| date of birth | birthDate | PatientAdmin.patient.birthDate |
| admission event | encounterEvent | PatientAdmin.admission |
Martini implementation pattern
A scheduler or source API starts a Martini workflow. Martini retrieves the source data, maps it to PatientAdmin, validates patient and encounter identifiers, applies duplicate and ownership rules, submits the authenticated REST request, and stores the Redox response and transmission identifier. Transient failures use bounded retry; validation failures are routed for correction.
Martini capabilities used
- workflows
- scheduler triggers
- API consumption
- data mapping
- validation
- business rules
- secure configuration
- error handling
Pattern 2: Deliver diagnostic reports to downstream systems
When to use this pattern
Use this event-driven pattern when a configured Redox message indicates that a DiagnosticReport is available for an EHR, care-management application, data warehouse, or operational consumer.
Integration direction
Example Mapping
| Redox Field | Canonical Field | Target Field |
|---|---|---|
| report identifier | reportId | result.externalId |
| patient identifier | patientId | result.patientReference |
| report status | status | result.status |
Martini implementation pattern
Martini receives the configured Redox callback, validates its source and payload, checks transmission and report identifiers for duplicates, transforms the diagnostic result into the downstream model, and writes it through the target API. Failed deliveries are retried only when transient and are otherwise placed into operational review.
Martini capabilities used
- API exposure
- webhook consumption
- data mapping
- idempotency rules
- API consumption
- error handling
- monitoring
Pattern 3: Synchronize scheduling updates
When to use this pattern
Use this pattern when appointment creation, rescheduling, cancellation, or other Scheduling changes must be coordinated between Redox-connected healthcare systems and applications such as Salesforce or patient-facing platforms.
Integration direction
Example Mapping
| Redox Field | Canonical Field | Target Field |
|---|---|---|
| appointment identifier | appointmentId | Scheduling.appointment.identifier |
| appointment start | startDateTime | Scheduling.appointment.start |
| appointment status | status | Scheduling.appointment.status |
Martini implementation pattern
Martini receives a source event or runs on a schedule, compares source and known Redox identifiers, rejects stale updates, maps the appointment into the Scheduling model, and submits it to Redox. Callback processing updates the downstream application, while duplicate messages and temporary failures are handled with state checks and bounded retries.
Martini capabilities used
- event-driven workflows
- scheduled workflows
- data mapping
- business rules
- correlation
- retry handling
- workflow monitoring
Pattern 4: Distribute medications and allergies
When to use this pattern
Use this pattern when approved Medications or AllergyIntolerance messages need to be distributed to care-management, clinical, or analytics applications while controlling PHI exposure and preserving source identifiers.
Integration direction
Example Mapping
| Redox Field | Canonical Field | Target Field |
|---|---|---|
| patient identifier | patientId | patient.externalId |
| medication name | medication | medication.name |
| allergy substance | allergen | allergy.substance |
Martini implementation pattern
Martini receives or retrieves the configured Redox message, validates patient and clinical identifiers, maps the payload to the target schema, applies field-level filtering and routing rules, and writes the approved result. Audit metadata and transmission identifiers are retained without exposing sensitive payloads in routine logs.
Martini capabilities used
- webhook consumption
- REST API consumption
- data mapping
- conditional routing
- security controls
- audit-aware logging
- error handling
Applications commonly integrated with Redox
Redox commonly sits between healthcare applications, provider organizations, and enterprise platforms that need normalized clinical, administrative, scheduling, or financial data. Martini can coordinate these flows without requiring a dedicated Redox connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Epic | Exchange patient administration, clinical summaries, orders, diagnostic results, and scheduling information with Epic-connected healthcare organizations. | Epic → Redox → Martini | Martini consumes configured Redox messages or callbacks, validates the relevant healthcare model, maps identifiers and clinical fields, and routes the result to approved downstream workflows. Asynchronous transmission identifiers are retained for correlation. |
| Oracle Health Millennium | Synchronize encounters, demographics, clinical information, orders, and results with Oracle Health environments. | Oracle Health Millennium → Redox → Martini | A Martini workflow receives or submits Redox-normalized payloads, applies source-specific mapping rules, and sends selected data to enterprise applications while recording processing status and correlation identifiers. |
| MEDITECH Expanse | Connect patient administration and clinical workflows in MEDITECH environments with other healthcare applications. | MEDITECH Expanse → Redox → Martini | Martini orchestrates REST requests and configured callbacks, maps PatientAdmin or ClinicalSummary content into the target model, validates required fields, and separates transient failures from permanent validation errors. |
| Veradigm | Exchange clinical and administrative information with Veradigm-connected provider organizations. | Veradigm → Redox → Martini | Martini uses Redox as the interoperability boundary, transforms normalized messages for downstream consumers, and applies idempotency checks using Redox transmission and source-system identifiers. |
| Salesforce | Align provider, patient-engagement, referral, or care-management processes with clinical and scheduling data. | Salesforce → Martini → Redox | A Martini workflow retrieves or receives Salesforce data, maps it to Redox models such as Scheduling or PatientAdmin, submits authenticated REST requests, and correlates later Redox callbacks with the originating Salesforce transaction. |
| ServiceNow | Create or update service-management and operational workflows based on healthcare events or integration exceptions. | Redox → Martini → ServiceNow | Martini receives configured Redox callbacks, applies routing and severity rules, and creates or updates ServiceNow records through its APIs. Failed healthcare transactions can be routed to operational queues or review workflows. |
| Snowflake | Centralize normalized clinical, administrative, and operational data for reporting, analytics, and data science. | Redox → Martini → Snowflake | Martini consumes Redox messages, performs controlled PHI-aware transformations, and writes approved datasets to Snowflake through the selected ingestion interface while preserving lineage and transmission identifiers. |
| Workday | Reconcile workforce, provider, organization, or operational information with healthcare processes where those datasets intersect. | Workday → Martini → Redox | Martini coordinates selected Workday and Redox API exchanges, applies ownership and validation rules, and sends only approved provider or organizational information to the relevant Redox-enabled workflow. |
How to build a Redox integration in Martini
Objective
Establish Redox test and production configuration using application credentials, bearer-token authentication, endpoint permissions, and secure environment settings.
Instructions in Martini
- Configure Redox environment-specific endpoints and credentials
- Store secrets outside workflow definitions
- Confirm enabled Redox data models and endpoint permissions
- Prevent authorization headers and PHI from appearing in logs
Objective
Select the trigger that matches the integration: a source API request, a scheduled workflow, or a configured Redox webhook callback.
Instructions in Martini
- Use an API-triggered workflow for synchronous intake
- Use a scheduler for controlled retrieval or outbound synchronization
- Expose a protected endpoint for configured Redox callbacks
- Define the correlation identifiers required by the flow
Objective
Obtain the Redox model payload and distinguish an acknowledgement from a completed healthcare transaction.
Instructions in Martini
- Call the Redox REST API with the bearer token
- Validate callback structure and configured source
- Persist transmission and source-system identifiers
- Mark asynchronous transactions as awaiting completion when appropriate
Objective
Coordinate validation, transformation, routing, downstream calls, and asynchronous completion in a maintainable Martini workflow.
Instructions in Martini
- Separate submission, callback, and completion logic where needed
- Apply conditional routing by Redox data model and status
- Reuse correlation and idempotency logic
- Route permanent and transient failures differently
Objective
Convert source formats into Redox normalized models or transform Redox messages for downstream applications without losing required identifiers.
Instructions in Martini
- Map fields to PatientAdmin, ClinicalSummary, Scheduling, or other selected models
- Handle optional and source-specific fields conservatively
- Preserve transmission and source identifiers
- Validate required fields before sending
Objective
Enforce healthcare-specific ownership, freshness, duplicate, routing, and PHI-handling rules before external side effects occur.
Instructions in Martini
- Reject stale scheduling updates when appropriate
- Check idempotency before non-idempotent writes
- Filter data for the receiving application
- Apply model and patient-context validation
Common Redox data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| PatientAdmin | Patient registration, demographics, admission, discharge, transfer, and related administrative events. | EHRs, patient-engagement applications, care-management platforms, and operational systems | Martini validates identifiers and required fields, maps administrative data, submits or receives the model through Redox, and applies idempotency checks. |
| ClinicalSummary | Patient-level clinical summaries and related clinical information. | EHRs, care-management applications, clinical repositories, and analytics platforms | Martini transforms source-specific clinical structures, minimizes sensitive logging, and routes validated payloads to approved targets. |
| DiagnosticOrder | Orders for diagnostic procedures or services. | EHRs, laboratory systems, diagnostic services, and care workflows | Martini maps order identifiers and patient context, submits authenticated requests, and records Redox transmission identifiers for later correlation. |
| DiagnosticReport | Diagnostic results and reports delivered through configured Redox messages or callbacks. | EHRs, care-management platforms, data warehouses, and operational applications | Martini receives callbacks, validates the message, transforms report content, applies duplicate protection, and delivers the result downstream. |
| Scheduling | Appointments, scheduling events, and appointment updates. | Scheduling applications, Salesforce, patient-facing applications, and EHRs | Martini synchronizes appointment changes, applies stale-update and duplicate rules, and routes transient failures for bounded retry. |
| Medications | Medication-related clinical data exchanged between connected healthcare systems. | EHRs, care-management platforms, clinical repositories, and analytics stores | Martini validates medication payloads, applies PHI-aware transformations, and distributes approved data through controlled workflows. |
Authentication and security considerations
Application credentials and bearer tokens
Redox uses application credentials to obtain an access token, which is supplied in the HTTP Authorization Bearer header. Environment, endpoint, account, and data-model permissions should be confirmed for each deployment.
Secrets and PHI
Keep Redox credentials and tokens in secure environment configuration rather than workflow definitions. Treat PatientAdmin, ClinicalSummary, DiagnosticReport, Medications, AllergyIntolerance, and Financial payloads as sensitive healthcare data.
- Use separate test and production configuration.
- Do not log authorization headers or full PHI-containing payloads.
- Restrict callback endpoints and downstream access.
- Define retention, audit, and operational access policies.
Operational considerations for Redox integrations
Asynchronous correlation
A successful initial HTTP response may acknowledge receipt rather than completion. Preserve Redox transmission identifiers and source-system correlation IDs for later callbacks.
Reliability and data quality
- Confirm pagination, request-volume behavior, and quotas for the specific Redox operation.
- Use bounded retries for transient failures and avoid retrying permanent validation errors.
- Implement idempotency before non-idempotent downstream writes.
- Validate required fields and account for optional or source-specific data-model variations.
- Test mappings across the relevant normalized, HL7 v2, and FHIR-derived representations.
- Monitor schema and data-model changes, workflow outcomes, and callback failures.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of point-to-point code
Martini separates Redox communication, healthcare data mapping, business rules, asynchronous correlation, and downstream delivery into maintainable workflows. This reduces duplicated integration logic when multiple applications consume or produce Redox models.
Operational control
Reusable workflows provide structured validation, secure configuration, error routing, retry handling, monitoring, and controlled API exposure. Developers can extend transformations when the normalized Redox representation requires custom logic without abandoning the overall integration design.
- Centralize mappings and correlation rules.
- Support scheduled, API-driven, and callback-driven processing.
- Keep credentials and environment settings separate from implementation logic.
- Handle healthcare payload failures consistently across integrations.
Frequently asked questions
Redox can be integrated through its HTTP-based REST API, application-credential bearer authentication, configured webhook-style callbacks, and normalized healthcare data models. Redox may translate underlying standards such as HL7 v2 or FHIR for connected healthcare systems, while enterprise applications typically exchange data with Redox through the REST interface.
Yes. Martini can consume the Redox REST API, securely manage credentials, transform Redox data models, expose an endpoint for configured Redox callbacks, correlate asynchronous transmissions, and route data to downstream APIs or other enterprise systems.
No. A dedicated Redox connector is not required. Martini can use Redox’s confirmed native integration mechanisms, including its REST API, bearer-token authentication, configured webhook callbacks, and normalized healthcare data models.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Redox. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Redox, connected healthcare systems, cloud infrastructure, or other third-party services depending on subscriptions, usage, and deployment.
The primary method is Redox’s REST API with application credentials and bearer tokens. Configured webhooks are appropriate for selected asynchronous messages or responses. Bulk handling is use-case-specific, and no general Redox GraphQL, SOAP, direct database, or universal file API was confirmed in the supplied research.
Redox supports webhook-style delivery for configured messages and responses, but coverage depends on the integration and data model. Martini can receive these callbacks through a protected API endpoint or webhook-consuming workflow and correlate them with the originating transmission.
Synchronization can be scheduled, API-triggered, or callback-driven. Martini retrieves or receives a Redox model, maps and validates it, applies business and idempotency rules, writes to the target system, and stores transmission identifiers so asynchronous responses and retries can be correlated.
Martini can distinguish authentication, validation, connectivity, rate-limit, and downstream processing failures. Transient failures can use bounded backoff, while permanent validation errors require correction. Transmission and source-system identifiers support idempotency so repeated callbacks or retries do not create duplicate downstream actions.
Related Martini documentation
API Workflows
Mapping
Connect Redox with Martini
Use Martini to build secure, maintainable Redox integrations for healthcare data exchange, asynchronous processing, transformation, and enterprise workflow orchestration.