Short Description

Designing an interoperable definition for Clinical Research activities is going to be a key driver for accelerating the reuse of healthcare data in accelerated delivery of treatments to Patients.  This project is focused on using FHIR for communicating study designs, so that they could be incorporated into EHRs

Long Description

With the productisation of the draft IG for Schedule of Activities we will need to work on formal advancement of the stability of the content therein in order to have the IG ready for ballot in the New Year.


Test an Implementation Guide

Track Lead(s)

Mike Ward, Geoff Low, Jean Duteau

Track Lead Email(s);;

Specification Information

Current Implementation Guide draft:

The SOA GitHub link:

Call for participants

EHR Vendors; Study Design Software Vendors; Curious Implementers

Zulip stream

Track Kick off Call


Clinical Input Required?Yes
Related Tracks?2023 - 01 Vulcan - Real World Data (RWD) for Research and Regulatory Submissions

Name: InterSystems FHIR Server

server endpoint: TBD

version: r4

Testing Scenario:


Research Study Dataset (SoA)

Synopsis:  As the implementations of Research Protocols using EHR systems increase there is a need for realistic sample study data covering the planning, execution and outcome of Study activities:

There should be examples of:

  • screen failure,
  • early termination (with different scenarios for termination),
  • study completion,
  • follow-up
  • extension studies (including master protocols).

As a extension we should consider coherent sample data infers that there should be some consistent change for the participant to cover the common use cases of no response, partial response, complete response to the study intervention. 

Investigational Product Administration

Synopsis:  A key point of reference in a Clinical Trial is the administration of Investigational Product (which may be a drug, therapy or procedure).  Study Elements are defined relative to these interventions, sometimes very directly (eg PK study) or more indirectly (eg Screening versus Treatment Epochs)

IP Administration Scenario 1:

Using the LZZT protocol (see below); 

  • Study Medication application Visit 3 (define an ActivityDef)
    • Intent to apply daily patch (ActivityDef --> MedicationRequest --> Placebo/Medication + dose)
    • Outcome of intent (Request -> MedicationAdministration)
    • Intent to remove daily patch (MedicationAdministration)
    • GOTO START ^^

IP Administration Scenario 2:

  • Patch Tolerability Visit 1/2 -> TTS (Medication)
    • Outcome of Tolerability assessment (3.9.34 in the protocol)
    • Can we establish screening failure based on this data

IP Administration Scenario 3:

  • Activities occuring relative to the MedicationAdministration
    • PlanDef -action-> ActivityDef (id IPAdmin)
    • Lab data post administation

​IP Administration Scenario 4:

  • Reconciliation
    • We're not there when IP is applied?
    • MedicationStatement vs MedicationAdminstration

Unscheduled Activities

Synopsis:  Up until to now the Study Design has been limited to pure 'happy path' implementation; where each subject has a single path through the study.  More practically it is known that there can actually be variations in what datapoints are expected for a study participant as part of the activitie s

Unscheduled Activities - Scenario 1

  1. Implement an unscheduled PlanDefinition for a set of Unscheduled Activities as an encounter that can be referred to in the SoA
    1. Add an encounter based on the unscheduled PlanDefinition (PD->CP->SR->EN)
    2. Annotate the PlanDefinition as an Unscheduled Encounter
    3. Identify the set of activities/outcomes based on the Unscheduled Activity

Unscheduled Activities - Scenario 2:

  1. Describe the activity of Early Termination (as a Narrative)
    1. Let the Provider suggest how they would implement

Unscheduled Activities - Scenario 3:

  1. Describe conditional activities 
    1. Describe the methodology for requesting a Reproductive Status Activity based on subject sex