.png)
Medidata Rave Integration Guide
Medidata Rave integrates with enterprise systems primarily through Rave Web Services and Medidata REST APIs for controlled clinical data and metadata exchange.
Medidata Rave integration options at a glance
Medidata Rave integrations are primarily built around Rave Web Services and related Medidata REST APIs, with access determined by study configuration, enabled modules, environment, and account permissions. These APIs can exchange clinical data and metadata using XML and, on some API surfaces, other supported representations. Large exchanges may use configured extraction or batch processes, although a universal bulk API is not confirmed. General-purpose webhooks are not confirmed, so scheduled polling with checkpoints is often appropriate. Martini can authenticate securely, call Rave endpoints, transform XML or JSON, apply study-specific rules, and write approved data to warehouses, operational systems, or controlled APIs.
| Integration point | Supported by Medidata Rave? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs and Rave Web Services | Yes | Retrieve or submit selected study, site, subject, event, form, DataPage, and item data or metadata. Exact resources, representations, and permissions depend on the enabled Rave API and study configuration. | Martini can consume the documented HTTP endpoints from workflows, authenticate with secure configuration, transform XML or JSON, apply business rules, and invoke downstream APIs. |
| Authentication | Yes | Rave Web Services commonly uses HTTPS and Medidata-provided credentials, including Basic Authentication. Supported Medidata API platform products may use OAuth 2.0 with product-specific registration and scopes. | Martini stores credentials, client details, and tokens in secrets or secure environment configuration and applies the required authentication to outbound API calls. |
| Bulk, asynchronous, or batch exchange | Limited | Large clinical data exchanges and extraction workflows may be available through configured Rave services or approved exports. A single universal bulk API for every Rave resource is not confirmed. | Martini can orchestrate pages or batches, persist checkpoints, control concurrency, and distinguish transient failures from data or authorization errors. |
| Webhooks and outbound callbacks | Limited | Notification or callback capabilities may exist for selected Medidata products or customer-specific use cases, but a general webhook feed for every Rave clinical data change is not confirmed. | Where a documented callback exists, Martini can expose an API or webhook-oriented workflow; otherwise it can use scheduled polling and incremental checkpoints. |
| XML representations | Yes | Rave Web Services commonly exchanges structured clinical data and metadata using XML, including study-specific structures, namespaces, repeating forms, and items. | Martini can parse XML, preserve namespaces and repeating structures, map values to a canonical model, and validate required fields before downstream writes. |
| JSON representations | Limited | Some Medidata API surfaces may support representations other than XML, but the applicable format depends on the API product, endpoint, and tenant configuration. | Martini can process JSON when the selected Rave endpoint provides it, while keeping mappings aligned to the confirmed response contract. |
| Scheduled synchronization | Yes | Polling is an appropriate fallback when notifications are unavailable. Scheduled extraction can use modification filters, overlap windows, and persisted checkpoints where supported. | Martini can trigger workflows on a schedule, retrieve incremental data, apply idempotent processing, and monitor late-arriving or corrected records. |
| Database or direct analytics access | No | Direct access to the Medidata Rave production database was not confirmed and should not be assumed. Approved APIs or exports should be used instead. | Martini can write approved Rave extracts to external databases or warehouses through supported interfaces without requiring direct Rave database access. |
How Medidata Rave exposes data and business events
Medidata Rave REST APIs
Rave Web Services and related Medidata API capabilities provide the principal HTTP-based mechanism for retrieving or submitting selected study data and metadata. Available resources and representations depend on the API product, study design, environment, account permissions, and enabled modules.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the applicable Rave endpoint, retrieves the required resource, parses the confirmed XML or JSON representation, maps it to a canonical model, applies validation and business rules, and writes the result to an approved target. The workflow records correlation, resource, study, and processing metadata without exposing sensitive clinical values in general logs.
Implementation sequence
Scheduled Rave synchronization
A general event stream for all Rave changes was not confirmed. Scheduled polling is therefore a practical pattern for retrieving changes where the applicable API supports modification filters, cursors, sequence values, or other extraction checkpoints.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow retrieves a bounded study or resource window, processes pages or batches, and persists a checkpoint outside the execution context. An overlap window and downstream idempotency reduce the risk of missing late-arriving updates or duplicating records.
Implementation sequence
Rave callbacks and notifications
Selected Medidata products or customer configurations may provide notification or callback capabilities, but a general Rave webhook mechanism covering every clinical data change was not confirmed.
Martini implementation pattern
Martini implementation pattern: when a documented callback is available for the required event and payload, Martini exposes a protected API endpoint, validates the request, optionally retrieves the current Rave resource, and routes the event through a workflow. The implementation must follow the callback’s specific authentication, event coverage, and retry contract.
Implementation sequence
Rave batch and extraction workflows
Rave supports large-scale clinical data exchange through applicable web-service and data-extraction configurations, but the available format, limits, scheduling, and asynchronous behavior must be confirmed for the customer environment.
Martini implementation pattern
Martini implementation pattern: Martini coordinates extraction windows and batch boundaries, controls request volume, transforms each completed unit, and records counts and failures. A workflow can resume from a safe checkpoint rather than restarting an entire study export.
Implementation sequence
Common Medidata Rave integration patterns
Pattern 1: Export clinical data to a warehouse
When to use this pattern
Use this pattern when approved Rave study data must be made available for reporting, analytics, or cross-system analysis. It is suited to scheduled extraction of Studies, Sites, Subjects, Events, Forms, or DataPages where the customer has authorized the required scope.
Integration direction
Example Mapping
| Medidata Rave Field | Canonical Field | Target Field |
|---|---|---|
| Study OID | study_id | STUDY_ID |
| Subject identifier | subject_id | SUBJECT_ID |
| Event identifier | event_id | EVENT_ID |
| DataPage status | data_page_status | DATAPAGE_STATUS |
Martini implementation pattern
A scheduled Martini workflow calls the applicable Rave endpoint, processes pages or batches, preserves study-specific identifiers and XML structure, and maps data into warehouse tables. It uses an overlap window, checkpoint persistence, idempotent upserts, audit counts, and bounded retries for transient failures while routing authorization or validation errors for review.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- XML and JSON transformation
- business rules
- error handling
Pattern 2: Synchronize Rave data with a clinical supply system
When to use this pattern
Use this pattern when an external randomization or clinical supplies application needs approved subject, site, visit, or eligibility information from Rave, or when an approved status or identifier must be returned to a permitted Rave operation.
Integration direction
Example Mapping
| Medidata Rave Field | Canonical Field | Target Field |
|---|---|---|
| Study OID | study_id | studyId |
| Site identifier | site_id | siteId |
| Subject identifier | subject_id | subjectId |
| Event identifier | visit_id | visitId |
Martini implementation pattern
Martini retrieves only the authorized Rave fields, validates study, site, and subject relationships, transforms them to the target API contract, and applies eligibility and duplicate rules before submission. Response identifiers are correlated to the source context, while transient API failures are retried with backoff and rejected data is surfaced without indefinite retries.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- secure secrets
- idempotency
- error handling
Pattern 3: Monitor clinical data quality exceptions
When to use this pattern
Use this pattern when clinical operations teams need automated detection of missing visits, incomplete forms, invalid combinations, stale transfers, or site-level data-quality indicators.
Integration direction
Example Mapping
| Medidata Rave Field | Canonical Field | Target Field |
|---|---|---|
| Site identifier | site_id | assignment |
| Form status | form_status | u_form_status |
| DataPage identifier | data_page_id | correlation_id |
| Validation message | exception_reason | description |
Martini implementation pattern
A scheduled Martini workflow retrieves selected Rave data, evaluates study-specific validation expressions, groups related findings, and creates or updates ServiceNow incidents using stable correlation keys. Sensitive clinical values are excluded from tickets and logs; duplicate suppression, severity rules, and status synchronization keep operational work actionable.
Martini capabilities used
- scheduled workflows
- API consumption
- validation
- business rules
- data mapping
- API orchestration
- monitoring and error handling
Pattern 4: Expose a controlled submission API
When to use this pattern
Use this pattern when an external clinical application should submit approved data or initiate a Rave operation without holding Rave credentials directly.
Integration direction
Example Mapping
| Medidata Rave Field | Canonical Field | Target Field |
|---|---|---|
| externalStudyId | study_id | Study OID |
| externalSubjectId | subject_id | Subject identifier |
| visitCode | event_id | Event identifier |
| formValues | data_page_values | DataPage and Item values |
Martini implementation pattern
Martini exposes a protected REST API, authenticates and validates the caller, applies study-specific mappings and authorization rules, then invokes the applicable Rave Web Services endpoint. It returns a controlled response, records a correlation identifier, avoids returning sensitive diagnostic details, and separates retryable Medidata failures from request-validation errors.
Martini capabilities used
- API exposure
- authentication and authorization
- workflows
- data mapping
- validation
- business rules
- error handling
Applications commonly integrated with Medidata Rave
Organizations can integrate Medidata Rave with adjacent clinical, operational, analytics, and enterprise applications when the relevant products expose supported APIs or approved transfer mechanisms. The exact data scope, direction, and authorization should be confirmed for each study and tenant.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Oracle Clinical One | Coordinate approved study, clinical operations, or trial technology information when an organization uses both Oracle and Medidata platforms. | Medidata Rave → Martini → Oracle Clinical One | Martini can retrieve authorized Rave data, normalize study and subject-related identifiers, apply domain-specific rules, and call the applicable Oracle APIs. Bidirectional exchanges should use separate workflows, checkpoints, validation, and auditable correlation identifiers. |
| Veeva Vault | Exchange approved study, document, clinical operations, or data-management information between Medidata and Veeva environments. | Medidata Rave → Martini → Veeva Vault | A Martini workflow can orchestrate Rave API extraction and Veeva API submission, map study-specific structures, minimize sensitive values, and route authorization or validation failures for review. A customer-specific interface must be confirmed rather than assumed. |
| Salesforce | Synchronize approved site, sponsor, investigator, or operational status information with a clinical organization’s CRM. | Medidata Rave → Martini → Salesforce | Martini can expose a controlled API or run scheduled extraction from Rave, map approved operational fields to Salesforce objects, and use upsert and duplicate controls. Rave credentials remain in Martini secrets instead of being shared with Salesforce. |
| ServiceNow | Create and track incidents, access requests, integration failures, and operational tasks associated with clinical systems. | Medidata Rave → Martini → ServiceNow | Martini can classify Rave authentication, validation, and transfer failures, create ServiceNow incidents through its API, and synchronize status updates using correlation identifiers and retry rules. |
| Snowflake | Load approved clinical and operational extracts into a governed analytics platform for study reporting and cross-system analysis. | Medidata Rave → Martini → Snowflake | A scheduled Martini workflow can retrieve paged or batched Rave data, preserve study and resource identifiers, transform XML or JSON into warehouse tables, and write through an approved Snowflake access method with checkpoint and audit metadata. |
| Microsoft Azure | Store, process, monitor, or route approved Rave data using Azure services such as storage, functions, or monitoring capabilities. | Medidata Rave → Martini → Microsoft Azure | Martini can call Rave APIs, apply data minimization and validation, and route results to the selected Azure service through its supported interface. Transfers should separate clinical payloads from operational telemetry and use environment-specific configuration. |
| Jira | Create issues for data-quality exceptions, integration failures, and study operations tasks. | Medidata Rave → Martini → Jira | Martini can evaluate extracted Rave data against validation rules, create Jira issues for actionable exceptions, and update or suppress duplicates using stable study, site, subject, and workflow identifiers. |
| Workday | Synchronize approved workforce, organization, or sponsor-side reference information where clinical operations depend on enterprise HR data. | Workday → Martini → Medidata Rave | Martini can retrieve approved Workday reference data, validate organization and user mappings, and pass only authorized values to Rave-adjacent processes or Rave endpoints where the customer’s configuration permits it. |
How to build a Medidata Rave integration in Martini
Objective
Establish the Rave endpoint, study and environment configuration, account permissions, and authentication method before implementing data flows.
Instructions in Martini
- Confirm the applicable Rave Web Services or Medidata API product and endpoint
- Configure HTTPS and the required Basic Authentication or OAuth 2.0 settings
- Store credentials, client details, and tokens in Martini secrets or secure environment configuration
- Verify study, site, subject, and resource permissions with a least-privilege account
Objective
Select a trigger based on the confirmed Medidata capability rather than assuming a general event stream.
Instructions in Martini
- Use a scheduled workflow when polling is required
- Use a documented callback only for the specific event and product that supports it
- Define the extraction window, overlap period, and checkpoint strategy
- Set timeouts and batch boundaries appropriate to the study volume
Objective
Call the confirmed Rave endpoint and handle its response format, pagination, filtering, and batch behavior.
Instructions in Martini
- Retrieve the required Studies, Sites, Subjects, Events, Forms, or DataPages
- Process XML or JSON according to the actual endpoint contract
- Handle pagination, response limits, and asynchronous or batch completion where applicable
- Capture correlation, study, resource, and response metadata without logging sensitive values
Objective
Coordinate source retrieval, transformation, validation, target writes, and recovery in a maintainable Martini workflow.
Instructions in Martini
- Separate extraction, transformation, validation, and delivery stages
- Persist checkpoints outside a single workflow execution
- Use reusable services or workflow components for common authentication and error handling
- Route authorization, validation, and mapping failures separately from transient transport failures
Objective
Convert study-specific Rave structures into a canonical or target-specific model without losing important clinical semantics.
Instructions in Martini
- Map stable identifiers for studies, sites, subjects, events, forms, DataPages, and items
- Preserve XML namespaces, repeating structures, OIDs, code lists, and null-versus-empty semantics
- Normalize dates, times, timezones, and controlled values explicitly
- Apply study-specific mappings rather than assuming generic form names
Objective
Enforce access, data-quality, eligibility, idempotency, and minimization rules before external writes.
Instructions in Martini
- Validate study and resource relationships
- Use stable identifiers and upsert or deduplication logic
- Exclude unnecessary subject-level data from logs and operational tickets
- Classify errors so validation and authorization failures are not retried indefinitely
Common Medidata Rave data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Studies | Identify the clinical protocol, study OID, environment, configuration, and scope for an integration. | Snowflake, Oracle Clinical One, Veeva Vault, operational databases | Martini uses study identifiers and configuration as workflow context, validates access, and routes data according to study-specific mappings and permissions. |
| Sites | Represent participating research sites and support site-level operational reporting or reference synchronization. | Salesforce, Oracle Clinical One, Snowflake, ServiceNow | Martini maps site identifiers and approved attributes, applies study and site access rules, and uses upsert or deduplication logic downstream. |
| Subjects | Represent trial participants enrolled or managed within a study. | Snowflake, approved randomization or supply systems, operational reporting platforms | Martini minimizes sensitive values, preserves stable identifiers, validates study and site relationships, and restricts logging of subject-level data. |
| Events | Represent scheduled or unscheduled study events such as visits. | Oracle Clinical One, clinical supplies systems, Snowflake | Martini maps event identifiers, dates, status, and subject context, then applies rules for eligibility, sequencing, and late-arriving updates. |
| Forms | Represent case report forms used to collect clinical data. | Snowflake, Veeva Vault, data-quality systems | Martini preserves form OIDs and study-specific metadata, tolerates additive schema changes where appropriate, and routes unexpected form changes for review. |
| DataPages | Represent collected form data associated with a subject and study event. | Snowflake, approved analytics platforms, data-quality monitoring systems | Martini processes DataPages in pages or batches, maps repeating structures and values, records extraction checkpoints, and uses idempotent writes. |
Authentication and security considerations
Authentication depends on the Medidata API product
Rave Web Services commonly uses HTTPS with Medidata-provided credentials, often through HTTP Basic Authentication. Supported Medidata API platform products may use OAuth 2.0, with grant types, scopes, token endpoints, and resources determined by the customer’s registration and tenant configuration.
Apply least privilege
Access is affected by study assignment, site and subject permissions, Rave roles, environment, enabled modules, and API registration. Successful HTTP authentication does not imply access to every study or resource.
Protect clinical data
- Store credentials, client secrets, and tokens in Martini secrets or secure environment configuration.
- Use separate configurations and accounts for development, testing, and production.
- Minimize subject-level data in logs, error payloads, and operational tickets.
- Restrict workflow access and retain appropriate technical audit metadata.
Operational considerations for Medidata Rave integrations
Volume and pagination
Confirm page sizes, response limits, filters, cursors, batch behavior, timeouts, and any study-specific service limits. Partition large extractions by study, site, subject, resource, or date range where appropriate.
Checkpoints and idempotency
Persist checkpoints outside the workflow execution context and use a small overlap window for late-arriving changes. Stable Rave identifiers and downstream upserts help prevent duplicate processing during retries or reprocessing.
Study-specific schemas
Forms, items, events, controlled terminology, and repeating structures can change during a trial. Use metadata-aware mappings, tolerant parsing for additive fields, contract tests, and alerts when expected structures disappear.
Errors and observability
Retry only transient transport, throttling, or service failures with bounded backoff. Surface authorization, validation, and mapping errors for correction, and record study, environment, resource, counts, correlation identifiers, workflow version, and failure reason without exposing sensitive clinical values.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than an API call
Rave integrations commonly require authentication, study-aware retrieval, pagination, XML or JSON transformation, validation, checkpointing, idempotency, downstream delivery, and auditability. Martini provides a workflow-based place to coordinate these concerns rather than scattering them across scripts.
Keep integrations maintainable
Martini separates endpoint configuration, reusable workflow logic, mappings, business rules, and environment secrets. This makes it easier to support multiple studies or targets while keeping study-specific differences explicit.
Control operational risk
- Use scheduled, event-oriented, or API-led workflows according to the confirmed Rave capability.
- Centralize retries, error classification, monitoring, and correlation metadata.
- Expose a controlled API when external applications should not hold Rave credentials.
- Apply data minimization and secure configuration consistently across environments.
Frequently asked questions
Medidata Rave is primarily integrated through Rave Web Services and related Medidata REST APIs. Authorized workflows can retrieve or submit selected study data and metadata, process XML or supported JSON representations, and exchange approved data with warehouses, clinical applications, operational systems, or controlled APIs. Scheduled polling is often used when a suitable notification mechanism is unavailable.
Yes. Martini can consume the applicable Rave Web Services or Medidata REST APIs, authenticate with configured credentials, transform Rave XML or JSON, apply study-specific validation and business rules, and write approved results to other systems. Martini can also expose an API for controlled submissions and receive documented callbacks where the customer’s Medidata configuration provides them.
No. A dedicated Medidata Rave connector is not required. Martini can integrate using Rave’s confirmed native mechanisms, principally Rave Web Services and Medidata REST APIs, with secure authentication, scheduled workflows, approved exports, or customer-specific callbacks where available.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Medidata Rave. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Medidata, cloud infrastructure, storage, or other third-party systems depending on subscription, usage, and deployment model.
Rave Web Services and the applicable Medidata REST APIs should generally be evaluated first. The chosen resources, representations, filters, and authentication method depend on the customer’s API product, study, environment, modules, and permissions. GraphQL and SOAP were not confirmed as current recommended Rave integration methods, and direct database access should not be assumed.
A general-purpose webhook feed covering every Rave clinical data change was not confirmed. Selected Medidata products or customer configurations may provide notifications or callbacks for specific use cases. If no applicable callback exists, Martini can poll through a scheduled workflow using checkpoints, overlap windows, and idempotent processing.
Martini can retrieve Rave data in pages or batches, persist extraction checkpoints, transform XML or supported JSON into a canonical or target model, and write results using stable identifiers and upsert logic. Mappings should preserve study-specific OIDs, repeating structures, controlled terminology, and date and timezone semantics.
Martini can classify authentication, authorization, validation, throttling, network, timeout, service, mapping, and downstream errors. Transient failures can use bounded retries and backoff, while authorization and validation issues are surfaced for correction. Stable study, site, subject, event, form, DataPage, or item identifiers support idempotent processing and duplicate prevention.
Related Martini documentation
API Integration
Workflows
Data Processing
Connect Medidata Rave with Martini
Use Martini to build secure, study-aware Medidata Rave integrations that orchestrate API calls, scheduled synchronization, transformations, validation, and downstream delivery.