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.

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.

Planning​

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 Questionnaire.id 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:

• 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 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 app.medplum.com supports building worklists to get you started quickly, for example:

• Adverse Events dash
• Protocols and SoA Dash
• Per Patient SoA

FHIR Resources​

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
• SNOMED
• 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