Clinical Study Schedule of Activities
2.0.0-ballot - STU 2 - Ballot
Clinical Study Schedule of Activities
2.0.0-ballot - STU 2 - Ballot
Clinical Study Schedule of Activities, published by HL7 International / Biomedical Research and Regulation. This guide is not an authorized publication; it is the continuous build for version 2.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/Vulcan-schedule-ig/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
The Schedule of Activities (SoA) forms a key part of a Clinical Trial Protocol; it is usually presented as a table with the columns detailing planned study 'visits' (Encounters) and the rows the details of study activities (Activities) that are to be undertaken at that visit, and they are key to understanding how the objectives of the study are to be implemented.
The image below shows a typical example SoA:
The SoA in this form represents the basic activities required at each Encounter and is usually accompanied by the details of the timings of the events (weeks) and an Encounter identifier (in the example the visit numbers… V1, V2… etc.)
The SoA table is then used as the basic building block for configuring the necessary tools and applications required to manage the progress of study participants during the study. This includes detailing activities such as when study interventions are to occur (e.g drug administration), and when required study evaluations are be made and the data collected and recorded.
These SoA specifications form the basis for developing study specific Case Report Forms (CRFs): the primary data collection instrument. Direct data collection and collation approaches such as the use of medical devices (Sensor Informed trials), or remote study management (e.g. Decentralised Trials), and direct data transfer from service providers such as central laboratories require confirmed syntactic, structural and semantic interoperability.
The key consideration for the SoA is the collection of data to support the hypotheses presented in the Protocol. The CRFs used in Clinical Research are the primary interface for recording outcomes of activities. They are designed to record the sets of data the study requires, and usually takes little account of the practical activities required to obtain the data. For FHIR specified SoAs to be successful when requirements are transcribed from the SoA for eHR implementation, a more 'workflow-based' approach to data management is required. Specifically, transcription needs to be able to clearly define:
The FHIR standard (Fast Healthcare Interoperability Resources) is designed to support the exchange of electronic health records. The 'Definitional Artifacts' section of the 'Specialized' FHIR Resources category provides a set of FHIR Resources that are designed to enable research specifications such as those in a SoA to be represented in a standard format that can consumed by eHR systems to plan and execute research protocols directly.
In order to represent the SoA we needed a set of definitional FHIR resources to represent the planned activities and the relationships between them. The work to date has focused on a Workflow view of data management, and has leveraged the existing FHIR workflow patterns to achieve this.
SoAs do not (a) stand alone - they are study specific, and (b) describe planned activities expected to be executed for each Patient recruited to the study. Two Research-oriented resources have been used to associate SoA with the correct study and to recognise patients as being study participants:
The project has also restricted its investigations and SoA IG development to using the PlanDefinition and ActivityDefinition. Other Structured Data Collection resources (e.g. Questionnaire, EventDefinition, etc.) have not been systematically investigated for their potential to define SoA requirements. The Workflow resources are defined on the FHIR Workflow page; the key points for modeling a SoA deal with the Definition and Request patterns.
The Definitional Artifacts have been used to create the structure - schedule and activities - to support bot study SoA specification (definitions) and planned contextualization.
The basic structure is summarized in the following diagram:
The high-level points are as follows:
Many activities are event or pre-condition based. The action.relatedAction predicate is used to represent the relationships between activities. This specifies what activities are to be done and when they are planned to be done (relative to a reference or pivot event).
The following example illustrates this for a flow of Study Visits:
For example; Informed Consent is required prior to any study activities commencing. This is modeled using the relatedAction predicate on the action predicate. This is illustrated in the above diagram. The Treatment Day 1 Encounter is annotated in the design. The other encounters are defined as being before or after this action; note - in this example we are binding the relationships between encounters; where these encounters are proxies for the activity within the encounter (e.g. First Study Intervention).
It is also possible to define the interval between these actions as illustrated in the Protocol Design Example. In this example the planned event Visit-3 has an id assigned to the action.relatedAction predicate. Prior and subsequent activities use the relatedAction.actionId to reference the pivot activity. This allows elementary sequencing of planned elements to represent the SoA. This sample also represents a simple windowing capability for scheduling activities relative to the index event. There is a separate use case to address how targeted windows can be applied to the scheduling of study activities.
This is also illustrated within an encounter in the Visit 1 and Visit 3 examples. Within an encounter tasks are defined using ActivityDefinition resources, and key tasks have a action.id attribute; tasks that should occur relative to the key task reference the task via the action.relatedAction attribute. In the H2Q-MC-LZZT study within-encounter activities are not as structured as they would be for say a Phase I Pharmacokinetic study, so the activities are defined as being before or after the key task (a specific example includes study data collection activities strictly occurring after collection of informed consent).
Given the structure discussed above, consideration has been given to how best to implement/use the planned activities within an Electronic Healthcare Record System; particularly how they can be used to manage the progress of a ResearchSubject through the study.
Having a standard like FHIR does not imply a standard approach to workflow in EHR systems. How a Study Plan is executed within the context of a EHR system can vary a great deal; the implementation may not actually exist within the EHR system itself, rather through an external platform (perhaps based on SMART-on-FHIR). For the purposes of testing the IG, the following implementation was executed using an external orchestration:
It is vital that study teams invest in a robust Site Assessment Questionnaire to ensure at least the following:
Implementation of an SoA using this IG will still require investment and engagement, however we are trying to provide repeatable (and adaptable) patterns that can be used as part of a study start for sites with capabilities to optimise their experience around the conduct of a clinical study.
The SoA Working group team has relied heavily on the Workflow patterns as mentioned in the core specification as a how the process of data collection could proceed, without being prescriptive about how activities should be manifested in the many systems that are involved in the day to day execution of healthcare. Some examples of existing workgroups and workgroup products that we consulted with included:
The SDC workgroup represents a implementation for Research based on the collection of clinical data by way of Questionaires, this is not unaligned with the approaches proposed in the current IG; we have focused on the use of ActivityDefinitions for scheduling Clinical Trial Activities in the Healthcare system, but Questionnaires can be used in addition to the ActivityDefinitions (and the pre-filling of Questionnaires referenced in SDC IG could leverage the Activities as defined in concordance with the IG).
The SoA FHIR IG assumes that how activities/tasks get executed is dependent on their respective services, procedures, and administrative mechanisms. The working group has assumed that it will vary dependent on the scenario and how each system, application, device, etc. are setup.
IG © 2022+ HL7 International / Biomedical Research and Regulation.
Package hl7.fhir.uv.vulcan-schedule#2.0.0-ballot based on FHIR 6.0.0-ballot3.
Generated
2026-03-31
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change