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:
- A faster path to a high confidence clinical protocol that's well documented.
- 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 stream||Description||Problem Areas|
|Assessment Management||COA, Lab panels, medical device management||Maintaining data, version history, usage, provenance for instruments|
|Schedule of Assessments||Building a schedule of assessments protocol||Feedback, documentation and protocol re-use|
|Protocol Documentation||Creating a protocol document, with references||Building a protocol that can be read by people, and imported into tools|
|Standards adherence||Ensuring that data is produced adheres to industry standards||Data from tools, such as Mapi Trust or Actigraph is non-standard (CDISC/FHIR)|
|User-facing software integration||COA, ePRO and other survey based instruments exist in many tools across platforms (iOS, Android, web)||Tracking versions and instruments across platforms, integrating responses|
|Media handling||Research often entails gathering images, videos, documents, binary files||EDC platforms have mixed support for binary data types|
|EHR Integration||Clinical research often requires pulling medical history from existing EHRs, systems||Getting 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.
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
Questionnaire.idfield. Multiple identifiers from different systems are supported and encouraged.
- FDA ontology: Tag each instrument with PRO, ClinRo, PerfO, ObsRo as a CodableConcept in the
- Locale and Languages: Mark locales, such as
EN-USin as a CodableConcept in
- 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.basedOnfield, for appropriate indexing.
- Questionnaire Level CDISC, LOINC and SNOMED tags: add the appropriate tags to the
- Question level tags: for each
Questionnaire.itemadd one or more CDISC, LOINC or SNOMED codes.
- Tagging both the Questionnaire resources and the
Questionnaire.itemwith 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.typeshould include LOINC, SNOMED, and CDISC codes where appropriate
ActivityDefinition.codeshould include LOINC, SNOMED and CDISC codes where appropriate
ActivityDefinition.specimenRequirementshould link to the SpecimenDefinition
ActivityDefinition.observationRequirementshould 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 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:
- Glucose Reading for an ObservationDefinition
- Blood Pressure panel for an ActivityDefinition
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
actionshould 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 app.medplum.com supports building worklists to get you started quickly, for example:
|Resource||App Link||Create New||API Documentation|
|ResearchStudy||View All||Create New||API|
|PlanDefinition||View All||Create New||API|
|ActivityDefinition||View All||Create New||API|
|Questionnaire||View All||Create New||API|
|QuestionnaireResponse||View All||Create New||API|
|ObservationDefinition||View All||Create New||API|
|Observation||View All||Create New||API|
|SpecimenDefinition||View All||Create New||API|
|AdverseEvent||View All||Create New||API|
|DiagnosticReport||View All||Create New||API|
|RequestGroup||View All||Created programmatically $apply||API|
Resources and Reference Materials
- CDISC to FHIR Mapping on HL7.org
- CDISC Foundational Concepts
- CDISC Controlled Terminology
- Mapi Research Trust COA library
- HumanFirst Atlas Measure Ontology
- Clinical Research Measures that Matter
- LOINC Codes
- CDISC Primer: SDTM, ADaM
- Blog Post: The Pre-Product Startup and the FDA on Y Combinator by Reshma Khilnani
- Blog Post: FDA Orientation for Early Stage Startups on Y Combinator by Reshma Khilnani
- Blog Post: How to start a Biotech Company on a Budget on Y Combinator by Reshma Khilnani