Skip to main content

Life Sciences

Highly customizable and integrated data management solution for clinical trials and research. Collect data in a standards compliant and automated way, with great visibility into your workflow and status. This is a solution for teams that find themselves building software to enable their clinical research and find a traditional Electronic Data Capture (EDC) hard to customize.


This section is under construction. Check back frequently for updates.

Overview and Problem Space

Clinical Trials and clinical research projects require a high fidelity workflow and data management process. Traditional Electronic Data Capture (EDC) systems are difficult to customize and many teams end up writing software to execute their research. When customizability and integrations are important, Medplum can be a useful tool.

At the end of the day, great standards compliant data management, specifically for assessments, has two major advantages:

  1. A faster path to a high confidence clinical protocol that's well documented.
  2. High quality, conformant data (FHIR, SDTM, ADaM) that's structured well for submission or publication.

Here is a summary of common limitations and problems areas as they relate to the workflow in life sciences.

Work streamDescriptionProblem Areas
Assessment ManagementCOA, Lab panels, medical device managementMaintaining data, version history, usage, provenance for instruments
Schedule of AssessmentsBuilding a schedule of assessments protocolFeedback, documentation and protocol re-use
Protocol DocumentationCreating a protocol document, with referencesBuilding a protocol that can be read by people, and imported into tools
Standards adherenceEnsuring that data is produced adheres to industry standardsData from tools, such as Mapi Trust or Actigraph is non-standard (CDISC/FHIR)
User-facing software integrationCOA, ePRO and other survey based instruments exist in many tools across platforms (iOS, Android, web)Tracking versions and instruments across platforms, integrating responses
Media handlingResearch often entails gathering images, videos, documents, binary filesEDC platforms have mixed support for binary data types
EHR IntegrationClinical research often requires pulling medical history from existing EHRs, systemsGetting data out of the EHR, LIS or other systems


One of the common planning scenarios is designing the Schedule of Assessments, and choosing which instruments (COA, ClinRo, ePRO, Lab Panels, Vitals, connected technologies etc.) go into the schedule. Versioning, and applying feedback from stakeholders, and maintaining the assessment list from study to study is important as well. This guide gives an overview of how to store assessments so that they can be exported, validated and re-used effectively.

Assessment Management

Survey Based Instruments

Survey based instruments are modeled using the FHIR Questionnaires. View questionnaires here, and create new ones here. The representation of the COA in the library is independent from its use in practice. Surveys can be collected on iOS, Android or using a system like Qualtrics and synchronized back as a FHIR QuestionnareResponse via Bots. If the data is structured and tagged correctly, reporting and validation will remain intact.

To effectively manage your survey based instrument, you'll want to ensure that each is represented as a FHIR Questionnaire and is tagged with the appropriate Metadata, specifically:

  • Questionnaire.url: Link to the documentation of the instrument. For example, if it is from Mapi-Trust, include the URL.
  • Identifiers: add any relevant identifiers (from Mapi-Trust, internal systems, CDC, etc.) to the field. Multiple identifiers from different systems are supported and encouraged.
  • FDA ontology: Tag each instrument with PRO, ClinRo, PerfO, ObsRo as a CodableConcept in the Questionnaire.code field
  • Locale and Languages: Mark locales, such as EN-US in as a CodableConcept in Questionnaire.jurisdiction
  • Binary Files: Sometimes binary files such as Android APK files, or iOS binaries are required for a validated instrument. It is recommended to store these as FHIR Media resources, with references to the original Questionnaire in Media.basedOn field, for appropriate indexing.
  • Questionnaire Level CDISC, LOINC and SNOMED tags: add the appropriate tags to the Questionnaire.code field.
  • Question level tags: for each Questionnaire.item add one or more CDISC, LOINC or SNOMED codes.
  • Tagging both the Questionnaire resources and the Questionnaire.item with other ontologies from Meddra, Mapi-Trust as suits your workflow.

This setup and tagging will ensure that data collected is also properly tagged and can be exported readily to other systems or converted to document/PDF format.

You can see a sample of how to construct questionnaires with the appropriate tags on Github.

Consents are a special category, and are FHIR Consent resources. Documentation here.

Lab Based Instruments

Lab panels and assays are modeled as FHIR PlanDefinition for the panel and FHIR ActivityDefinition for the assay. Each ActivityDefinition should also have a SpecimenDefinition and one or more ObservationDefinition. A correct panel setup will ensure that collected data is tagged correctly. The following best practices are recommended.

  • PlanDefinition.type should include LOINC, SNOMED, and CDISC codes where appropriate
  • ActivityDefinition.code should include LOINC, SNOMED and CDISC codes where appropriate
  • ActivityDefinition.specimenRequirement should link to the SpecimenDefinition
  • ActivityDefinition.observationRequirement should link to the ObservationDefinition, which should also be tagged with appropriate LOINC, SNOMED and CDISC codes.

You can see an example of a PlanDefinition for Lab in code and on Storybook.

You can see an example of a simple ActivityDefinition for Lab in code or on Storybook.

Here is an ObservationDefinition for Lab in code and ObservationDefinition on Storybook

Overall, the COVID-19 Data model sample can be useful to get a sense of how to represent labs in FHIR.

Digital Technologies

Digital technologies such as a continuous glucose monitor, blood pressure cuff and more should be modeled as ActivityDefinition with ActivityDefinition.observationRequirement being one or more ObservationDefinition. Both resources should be tagged with Measures That Matter, Meddra, CDISC, LOINC and SNOMED codes where appropriate. Sample codes that apply to these resources are:

Schedule of Assessments

Once the instruments are tagged, the next step is to build the Schedule of Assessments (SoA), which is a tool for assembling the assessments onto a timeline, but it's a relative timeline, may start on an arbitrary date and milestones are relative to one-another. The SoA is technically a protocol, and has many similarities to a Care Plan. The data model is as follows:

  • SoA overall is represented as a PlanDefinition, and you can see a sample on [Storybook]
  • PlanDefinitions have actions, and these are the milestones on the SoA, each action should have a Timing (e.g. between day 2 and day 3) and a Location, even if the assessment is done at home.

You can see a sample of a SoA in Code here.

Exporting your Schedule of Assessments

Exporting the schedule of assessments is possible using the Bot framework. A common pattern is to export the protocol to a number of formats like CDISC PRM, CSV, PDF, DOCX, or allow it to be read as FHIR via the API.

Health Records Integration

Data capture from legacy EHRs, LIS/LIMS, records request aggregators, COA tools, form builders and digital signatures and more. This is done through the integration and interoperability engine.

Patient-facing tools integration

PRO data comes in from a multitude of systems like Qualtrics, custom mobile applications, and various form builder and survey tools. Integrate, normalize and tag the data using the integration and interoperability engine and bots.

Dashboards and Reporting

Build a powerful dashboard that can track your workflow and get where you need to quickly. Our admin console supports building worklists to get you started quickly, for example:

FHIR Resources

ResourceApp LinkCreate NewAPI Documentation
ResearchStudyView AllCreate NewAPI
PlanDefinitionView AllCreate NewAPI
ActivityDefinitionView AllCreate NewAPI
QuestionnaireView AllCreate NewAPI
QuestionnaireResponseView AllCreate NewAPI
ObservationDefinitionView AllCreate NewAPI
ObservationView AllCreate NewAPI
SpecimenDefinitionView AllCreate NewAPI
AdverseEventView AllCreate NewAPI
DiagnosticReportView AllCreate NewAPI
RequestGroupView AllCreated programmatically $applyAPI

Resources and Reference Materials