Every clinical pharmacologist who has tried to build a real-time PK dosing integration with a major EDC has eventually encountered the gap between what the HL7 FHIR specification describes and what any specific EDC implementation actually delivers. FHIR R4 is a well-designed interoperability standard. EDC vendors' implementations of FHIR are, with varying degrees of generosity, works in progress.
Medidata Rave is the most common EDC in sponsor-funded oncology trials. This article covers what the Rave FHIR R4 API currently supports for PK dosing system integration, what it does not support, and the practical workarounds that most integration teams end up using. This is based on direct integration experience, not documentation review.
The Resources You Actually Need
A PK dosing system needs three categories of data from the EDC: patient demographics (for populating covariate fields in the population PK model), drug administration records (infusion start time, end time, dose administered), and lab values (creatinine clearance, CBC, and PK concentration results). These map to three FHIR R4 resources: Patient, MedicationAdministration, and Observation.
FHIR R4 defines all three resources with sufficient detail for PK integration purposes. The Patient resource carries demographics, birth date (for age-based covariate calculation), and reference fields that link to encounter and episode of care records. MedicationAdministration carries the drug, the dose, the route, and critically the effective period (start datetime and end datetime for IV infusions). Observation carries coded lab values with LOINC codes, numeric values and units, and the reference range.
In the specification, this looks adequate. In Rave, the picture is more complicated.
What Rave Actually Emits
Medidata's Rave FHIR API (available through the Medidata Platform API framework as of the 2022 update) supports read operations on Patient, Observation, and a limited version of MedicationAdministration. The Patient resource export is generally reliable for demographics fields. Observation export for lab values works if your trial's eCRF was built with LOINC-coded fields - which is not the default in most Rave builds.
Most Rave implementations use custom field names for lab values, not LOINC codes. A creatinine clearance field built as "CRCLRC" in the eCRF does not automatically map to LOINC code 2164-2. The Medidata Translator layer is supposed to handle this, but translator configuration is a per-study setup task that requires the data management team to explicitly create the LOINC mappings during eCRF specification. In studies where TDM integration was not planned from study startup, these mappings typically do not exist and must be added retroactively.
Retroactive LOINC mapping in Rave requires a Protocol Amendment if the eCRF modification touches any fields included in the locked eCRF version. For a study that has already completed screening, this can take 4-8 weeks through the sponsor's change management process. Plan the LOINC mapping work during eCRF build if TDM integration is contemplated - this is the single most common delay in post-startup integration projects.
The MedicationAdministration Problem
The infusion timing problem is the biggest practical gap in current Rave FHIR implementations. MedicationAdministration requires an effectivePeriod element with start and end datetimes to represent IV infusion timing. Rave's standard drug administration eCRF captures start date and time and stop date and time in separate fields. Whether these fields map to the FHIR effectivePeriod in the Rave FHIR export depends on how the eCRF field mapping was configured.
In implementations we have reviewed, approximately 60% of Rave studies have the infusion time fields correctly mapped to effectivePeriod in the FHIR export. The remaining 40% export drug administrations with only the medication code and dose - effectivePeriod is null. A PK calculation with no infusion end time cannot correctly estimate post-infusion concentration-time curves for drugs administered as prolonged infusions, which includes most IV cytotoxics.
The workaround for missing effectivePeriod is to use the nominal infusion duration from the protocol (if the actual infusion duration was not captured in its own eCRF field) and to flag those estimates as using protocol nominal rather than actual timing. This is a compromise - the consequences for AUC accuracy depend on how variable actual infusion durations are at your sites, which is usually unknown without manual chart review.
Real-Time vs Batch: Timing Expectations
FHIR R4 supports both real-time (event-driven) and batch data retrieval models. In the real-time model, the EDC posts new or updated resources to a subscriptions endpoint when data are entered and saved. In the batch model, the downstream system polls for new data at regular intervals. Rave's FHIR implementation currently supports polling (batch) with a minimum polling interval of 5 minutes. True event-driven subscription is on Medidata's roadmap but not yet available in production.
For most TDM workflows, a 5-minute polling interval is acceptable. A CRC enters a PK sample result in Rave, the dosing system picks it up within 5 minutes, runs the MAP Bayesian update, and generates a revised AUC estimate. In the typical TDM workflow, the physician reviews the AUC recommendation 30-60 minutes after the last PK sample is entered, so 5-minute data latency does not create operational problems.
Where polling interval matters is in acute dose-decision scenarios - for example, busulfan TDM during conditioning, where dose decisions for the next 6-hour administration may be needed within 2 hours of the preceding sample. In these contexts, a polling-based integration with a 5-minute lag is workable but requires protocol-specified decision timelines that account for the data latency.
Alternative Integration Paths: When FHIR Is Not Enough
When FHIR mapping issues make the Rave FHIR API unreliable for a specific study, two alternative integration approaches are commonly used.
The first is Medidata's Clinical Data API, which provides direct access to subject and form data using the study's native field names. This bypasses the FHIR mapping problem entirely and retrieves exactly what was entered in the eCRF. The downside is that downstream systems must map the study-specific field names to their own data structures, which makes the integration study-specific rather than generalizable. For multi-study platforms like DoseMind, this creates maintenance overhead for each new study.
The second is a lightweight eCRF supplement: add a TDM-specific eCRF module to the study that captures PK sample times and concentrations in a standardized, pre-mapped format specifically designed for FHIR export. This is a mid-cycle protocol change but a smaller one than a full LOINC mapping project, and it gives you clean FHIR data going forward without depending on historical field mapping decisions. This approach works well for studies that are mid-execution when TDM integration is initiated.
Veeva Vault EDC: A Comparison Point
Veeva Vault EDC, the second most common EDC in large oncology programs, has a different FHIR implementation story. Vault's FHIR R4 support is more recent (2023 generally available) and was designed with interoperability as a primary requirement from the start rather than a retrofit. The MedicationAdministration effectivePeriod mapping is configurable during study setup and defaults to mapping actual infusion times if they are captured in the eCRF. LOINC code mapping is part of the standard field specification workflow rather than a separate translator configuration step.
For new studies starting on Vault where TDM integration is planned, the FHIR integration path is meaningfully cleaner than on Rave. For existing Rave studies, retrofitting TDM integration remains a data management project that requires the steps described above.
The Site EHR Layer: Often the Most Reliable Data Source
An underappreciated option for PK data integration is bypassing the EDC entirely and connecting to the site's electronic health record (EHR) system, which in most academic medical centers in the US is Epic or Cerner. Both Epic and Cerner have mature FHIR R4 implementations that include actual infusion pump records, laboratory results with collection timestamps, and creatinine clearance values calculated by the hospital's clinical laboratory system.
The limitation is patient identification linkage: EHR records use the hospital's medical record number, while the EDC uses the trial subject ID. Establishing and maintaining the crosswalk between these identifiers requires an additional data governance step and adds complexity for multi-site trials where each site has a different EHR system. But for single-site investigator-initiated trials, the site EHR may be the most reliable source of accurately timestamped infusion and lab data available, and FHIR R4 from a mature EHR implementation is typically more reliable than from a clinical trial EDC.
Conclusion: Integration Requires Planning at Protocol Design Time
PK dosing system integration with an EDC is not a plug-and-play activity. The decisions made during eCRF specification - which fields capture infusion times, how lab values are coded, whether LOINC mapping is configured in the translator layer - determine whether FHIR-based integration will be smooth or a months-long remediation project. The correct time to plan TDM integration is during protocol design, not after database lock.
DoseMind supports integration with Medidata Rave, Veeva Vault, Oracle Clinical One, and direct EHR FHIR R4 endpoints. Our integration team provides a pre-study data architecture review that identifies FHIR mapping requirements before the eCRF is built. Contact us at hello@dosemind.com to begin an integration assessment for your next trial.