Clinical Study Schedule of Activities, published by HL7 International - Biomedical Research & Regulation Work Group. This is not an authorized publication; it is the continuous build for version 1.0.0). 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

Core Schedule of Activities Model

Core Implementation Model for Clinical Study Schedule of Activities (SoA)

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 Encounters/Visits (any planned event corresponding to clinical data collection) are represented along the horizontal axis (for an example see Visit 3)
• The Activities (the planned activities expected to occur at the event) are represented vertically (for an example see Vital Signs/Temperature)
• … with the required Activities at each Encounter shown by a cross (X) in the matrix.

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:

• what activities are being done
• when are they being done
• the outcomes from those activities, and potentially
• who is to perform/undertake the activities

Implementing a SoA using FHIR Resources

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:

• ResearchStudy - a representational artifact for a Research Study
• ResearchSubject - an artifact used to link a Patient research to the ResearchStudy

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:

• The ResearchStudy has at least one protocol reference to a PlanDefinition for the Study Definition,
• Under the Study Definition there are references to each of the planned encounters/visits through the action predicate (linking to the PlanDefinition instance for the encounter),
• Within a planned encounter/visit, the planned activities are represented through the action predicate linking to the ActivityDefinition representing the activity.

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).

Observations on how the SoA can be implemented

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.

Following the FHIR Workflow paradigm, what needs to be done has been defined using the Definition patterns, which are scheduled using Request patterns and ultimately manifested as Event patterns. The current implementation examples are constrained to the minimum requirement in order that the core concepts in a clinical trial protocol are accurately modelled

The example below shows how a defined study plan can be related to an executed activity and the required outcomes/results.

<?xml version=”1.0” encoding=”UTF-8” standalone=”no”?>

While the diagram may look complex it is methodologically sound as it builds out an approach using a set of common archetypes. There is a flow of planned -> scheduled -> performed activities that IG implementers can follow to build processes and software meeting the SoA objectives. This serves as a way to drive data collection (for both prospective and retrospective use cases) and it provides a broad scope for current and future use cases. Please note, that much of the workflow is not shown in this representation; there are no references to scheduling and orchestration resources (eg Appointment, AppointmentResponse )

Taking the above diagram a step further, the following is an illustration of which FHIR resources, with their respective associations, may be used to define the scheduling of activities, procedures, observations and investigational product (IP) administrations.

• PlanDefinition resources may be used to define each clinical encounter, the activities within that clinical encounter, the relative timing (before or after) and actual timing between activities. A PlanDefinition may reference other PlanDefinition resources.
• Activities within a PlanDefinition are further described in ActivityDefinition.
• It is the CarePlan resource that links an individual Patient to the PlanDefinition. To maintain anonymity to the sponsor, the ResearchSubject resource is used to pseudonymize any identifiable information about the patient.
• ServiceRequest may trigger the instantiation request for a procedure or diagnostic or other service to be planned, proposed, or performed, as distinguished by the ServiceRequest.intent field value, with or on a patient. The procedure will lead to either a Procedure or DiagnosticReport, which in turn may reference one or more Observation resources, which summarize the performance of the procedures and associated documentation such as observations, images, findings that are relevant to the treatment/management of the subject. ServiceRequest may also instantiate the scheduling of a Encounter, at which the planned activities, such as Procedure, Observation, and MedicationRequest resources for investigation product, may be scheduled and performed.
• Although not directly germane to propagating the protocol schedule, it is important to note that, depending on how and where IP is administered to the patient, evidence of the IP administration may be recorded in MedicationStatement and/or MedicationDispense plus MedicationAdministration. That is discussed in more detail in the Investigational Product Use Case.

Caveats

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.

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.