Healthcare interoperability standards such as the Fast Healthcare Interoperability Resources (FHIR) [1] are providing new methodological approaches for the collection, collation, and confirmation of clinical research data for both observational studies and trials supporting product regulatory submissions [2-4]. To be successful, clinical research studies require that (1) the correct data are available to answer the research question and (2) these data are collected at the correct times. These are detailed in the study protocol, where the schedule of activities (SoAs), usually in the form of a square table, provides the key data and scheduling requirements. Various recent projects are underway to explore methods for digitizing all or parts of study protocols with FHIR as a key interoperability component (International Council for Harmonization M11, CDISC Unified Study Definitions Model, and Vulcan Utilizing the Digital Protocol) [5,6].

In a previous paper [7], a graph-based minimum viable set of characteristic attributes needed to define a study’s SoA was developed, along with commentary on the range of “variations on the theme” encountered in different clinical study types and therapeutic areas. Operational use cases that depend on the SoA were also considered. The resulting graph representations of an SoA were converted to FHIR PlanDefinitions compliant with the Health Level 7 (HL7) Vulcan clinical study SoA Implementation Guide (IG) [8].

While the current Vulcan SoA IG can model a wide variety of clinical study SoAs, it is recognized that it is principally limited to defining relatively simple SoAs. It works well to convert SoA tables to FHIR resources; however, it does not have methods to define schedules that repeat (cycle), an essential part of most oncology studies. Similarly, it does not offer methods for conditional switching or to select different permitted (multiple) study paths. It may be coerced in some cases to manage specific situations, but this is not ideal when these “fixes” are key scheduling requirements. This can mean that a Vulcan SoA IG–compliant SoA will specify only part of the total scheduling options that a specific study requires. Subsequent use by consuming applications, such as electronic health record (EHR) systems, may or will require additional tooling to implement all study scheduling variations and control.

Considering previous work, this study investigated (1) what attributes or modifications to a graph model are needed to cover the extended use cases outlined earlier and (2) develop a FHIR PlanDefinition representation that can communicate these requirements. Additional tooling—such as FHIRPath expressions, clinical quality language, or system-specific methods (eg, EHR)—will be required to fully implement the FHIR PlanDefinition into the operational workflow of a clinical system.

The primary objectives of this study were to (1) develop methods for defining multiple SoA paths within a single graph, (2) develop methods for defining SoA conditional scheduling requirements, (3) develop a human-understandable syntax to support specific study specification, (4) reflect these requirements as FHIR definitional resources, and (5) test and confirm converting the graph representations to FHIR and vice versa

The study does not include human participants, use of medical records, or patient information.

Figure 2 illustrates the general problem that arises even with a simple study design when considering how to define all protocol-defined permitted paths. Figure 2A shows how the scheduled visits of Table 1 might be presented as a directed graph. However, the “unscheduled” visit “floats” independently as it is to be used on an “as required” basis over the period of the planned visits.

Defining all permitted paths (ie, extending Figure 2A to add all protocol-implied paths) is shown in Figure 2B and is easily achieved simply by adding appropriate visit-visit edges. Similarly, all potential activity sequencing options can be defined using the same method (Figure 3).

No additional node or edge attributes beyond those listed in Table 2 are required to define all permitted paths. However, ensuring that the timing calculations for any path are computable cannot be achieved using the planned timings alone. Here, the problem is that the scheduled planned timings are node (visit) attributes, but calculating the timings for any path requires a summation of the transitions along whichever path is selected (Figure 4).

Unscheduled visits may necessitate rescheduling of scheduled events. The addition of a transitionDelay edge attribute (Table 3; defined as the time to wait before transitioning to the next node) was found to provide the necessary timing information. It also provides the basis for a key timing consistency check.

Figures 2B and 3 also illustrate that there are many cases where specific conditions require different (but permitted) routes to be followed. Some cases are generic and are present in any study (eg, participant’s right to withdraw at any time), some are protocol-specific (eg, if the participant is male, a pregnancy test is not required), and some complex, as illustrated in Figure 2B for managing all “unscheduled” path options (eg, an “unscheduled” visit following V_n cannot return to early visits, only being able to proceed to the next planned visit).

To accurately carry all conditional scheduling requirements within a single SoA graph, it was found that 3 things were required as follows:

Both graph node attributes and edge attributes in the model here could be used to hold conditional scheduling information. Adding conditions to the nodes (eg, [visit] repeatAllowed: true/false) was found to satisfy some standard requirements (eg, can a visit be repeated? V2: repeatAllowed: false, and Unscheduled: repeatAllowed: true), but the other requirements were very poorly satisfied (particularly regarding what routes are available following an unscheduled visit). Adding the following edge attribute was found to accurately and easily model all the SoA tested use cases:

This approach was also user-friendly, as only the conditions on each edge (transition) were needed to ensure the use of any specific path (ie, by answering the question “under what conditions can this path be selected or is not available?” and this can also include multiple conditions).

A parameterized specification syntax was developed to hold the edge attribute conditions that can be consumed as inputs to a truth table engine that would resolve all edge conditions to the single “true” or “false” as described above. Simple {“function”: “inputs”} pairs were used to specify the “true” or “false” state at runtime for that condition (eg, {“consentObtained”: true}) or any combination of conditions.

The following examples show how several commonly required SoA conditional requirements can be defined using this approach.

The primary use case here is the definition of permitted paths through the study, including, but not limited to, the primary path. For example, in Figure 2B, paths exist to and from “unscheduled” to all “visits” permitting return to the primary schedule. However, “unscheduled” visits cannot return to a previously visited “visit” (discussed earlier). Two rules are required for this case: one to confirm the existence of previously visited visits, and one to ensure that all “future” visits have not yet been visited. The following example shows the rules required on edge U>V3 in Figure 2B, which will ensure that only this path is available at runtime:

(ie, If visits instantiation start [IS], V1, and V2 have occurred and visits V3, V4, V5, V6, and instantiation finish [IF] have not occurred, moving from unscheduled visit [U] to V3 is allowed).

Similar rule pairs, when applied to all U>V_n edges, can then ensure that only “forward” paths are available for selection.

Restricting, adding, or skipping activities dependent upon participant conditions is a very common feature of SoAs, with the details often provided as footnotes to SoA tables. Examples include requiring pregnancy testing if the participant is female (and conversely not requiring this if the participant is male) and not proceeding with further tasks if inclusion criteria cannot be met (Figure 3). Example rules for these cases are simple to define, but consideration of all edge options is usually required, as follows:

An important feature of many SoAs is the requirement to repeat activities (eg, blood pressure measurements) or to repeat visit blocks. This last use case is particularly important in the case of many oncology studies where repeating treatment cycles is an inherent part of the study design and will have some limit on the number of cycles and the requirement to exit the study if too many cycles are proving necessary. Typical edge rules for controlling repeat or cycle situations include the following:

Limit the number of cycles to a max of 5.On edge to start of cycle: {“n_cycles”: “<6”}

Often, the requirement to select different SoA paths is dependent upon states, milestones, or events, as, for instance, defined by the FHIR ResearchSubject resource [1]. This can be illustrated by the following examples:

The syntax also permits any number of conditions to be defined easily within a single SoA graph for any given edge to obtain a sample for genetic testing. This can be illustrated by the following example:

The runtime assessment of each condition then serves as the input to a logic engine that determines the final true or false state.

Undefined SoA paths can also be recognized using this approach. An undefined path is defined here as one that may occur but is not recognized formally within the SoA graph. A good example of this is the right to withdraw from a study at any time or skip an activity. Formally recognizing every point where these conditions may occur and providing a defined path may add too much complexity to the graph, and it may be unreasonable to model it. However, placing a general requirement on all transitions (edges) of {“withdrawn”: false} will permit proceeding through the schedule until {“withdrawn”: false} == “false” (ie, withdraw is now “true”). Using suitable runtime coding, the “undefined” transition can be applied to the specific participants’ SoA graph instance.

The primary objective of this study was to identify methods that enable SoAs to be more fully defined using FHIR resources. The SoA graph review identified the necessary additional requirements needed to satisfactorily model SoA specifications, such as those shown in Figure 1. To successfully define these specifications using FHIR resources, they must meet the following requirements:

The Vulcan SoA IG [8] was used as the starting point for developing a more comprehensive SoA FHIR model with the goal of extending or modifying it to be able to manage the complex designs, conditions, and “variations on the theme” as discussed earlier.

From the graph attributes model developed earlier, it follows that for the PlanDefinitions to fully specify all SoA requirements, it needs to hold a definition of the SoA graph, and not the SoA table. Reviewing the use of the PlanDefinition.action and PlanDefinition.action.action elements, the basic graph node and edge relationship can be defined. Specifically, with nodes (visits) mapped to PlanDefinition.actions and edges(transitions) mapped to PlanDefinition.action.actions, all the relationships defined, for example, in Figure 1, can be specified within a single PlanDefinition.

PlanDefinition.action in its standard form does not support those elements (attributes) to hold all the necessary SoA specification details. These have been added using 2 extensions, that is, soaTimePoint and soaTransition (Figure 5 [7]) to hold the graph information, which in turn then forms the basis for an soaPlanDefinition profile (Multimedia Appendix 1).

Conditional SoA requirements can now be specified using the PlanDefinition.action element condition (applied to PlanDefinition.action.action), with each edge having all or any true or false conditions for that transition. When combined with PlanDefinition.groupingBehaviour and PlanDefinition.selectionBehaviour, path selection can be restricted to 1 path only, with only those transitions that are permitted being available for selection. Figure 6 shows the FHIR Shorthand specification for node V2 in Figure 2 and Multimedia Appendix 2.

To operationalize the FHIR PlanDefinition within the workflow of a clinical system, such as an EHR, additional tooling is required. The illustrative syntax presented in the examples—for instance, expression = “{‘interactions_not_exist’: [‘V3’, ‘V4’, ‘V5’, ‘V6’, ‘IF’]}”—serves to demonstrate the underlying logic but is not directly executable within an FHIR environment. In practice, these expressions must be translated into an FHIR-compatible solution, typically by leveraging FHIRPath, clinical quality language, or system-specific functionality. Such translation ensures that the abstract representations in the PlanDefinition can be implemented as concrete, machine-interpretable instructions within the clinical system’s workflow.

All the interim and final products, methods, and results described earlier were validated using the testing schedule shown in Figure 7. Once interim inconsistencies were reviewed and resolved, no SoA information loss was present after recovering an soaGraph from a FHIR PlanDefinition (Figure 7; test cycle 1) or after loading and recovery from test FHIR servers (test cycle 2).

More than 25 studies, ranging from relatively simple designs, as shown in Figure 1, to complex studies incorporating cycles and multiple SoAs (not shown), were used to test and validate the approach. All tests could be accurately defined, with the most frequent finding during this exercise being that it highlighted inconsistencies in the protocol specifications themselves. It also lends itself to defining SoAs more succinctly and potentially more accurately. Figure 8 is a template for studies that includes cycles and shows that each required visit (interaction) is only defined once. With appropriate edge (transition) attributes and conditions, this can be modified to define many specific study scenarios.

The HL7 FHIR standard is becoming, if not already, the de facto healthcare interoperability standard [2,15-18]. The primary source of many clinical trial data is EHRs, and studies usually require manual transcription of these data into electronic data capture systems. For both quality and volume reasons, this is often not optimal and has led to efforts to obtain data directly from electronic data capture systems (direct data capture) [19-22].

This study’s protocol and the SoA provide the primary definitional source for a study’s required research data and details of other operational requirements. The value of definitional FHIR resources to support clinical research and similar initiatives has been recognized in the Specialized Definitional Artifacts category [1].

The PlanDefinition resource is the primary resource for defining “a predefined group of actions to be taken in particular circumstances.” The Vulcan SoA IG [23] has developed a set of profiles using this resource to define SoAs. As mentioned earlier, this model does not include methods to define either conditional scheduling, certain study designs (notably cycles), or the scheduling of expected but not planned events (particularly “unscheduled visits”). This work has re-evaluated how PlanDefinition might be modified, revised, or extended to model these situations.

Using a systematic review of the relationships and attributes required to define the SoA characteristics discussed earlier, a graph-based method has been developed that can manage all these cases. Subsequently, by associating PlanDefinition.action and PlanDefinition.action.action directly with graph nodes and edges, respectively, SoAs with all scheduling variations, conditional paths, and methods to manage planned but unscheduled events can be defined within a single PlanDefinition. Recognizing that an SoA “activity” has both timing and task elements (ie, is “X” in tabular SoAs), the model formally disassociates the scheduling information from the task or activity definitions, which can then be linked using the PlanDefinition.action.relatedAction.targetId element. This approach also enables SoA activities as described in study protocols (or not described) to be fully traceable in the SoA schedule, but specified fully using other appropriate FHIR definitional resources (eg, ActivityDefinition and ObservationDefinition)

Earlier work based on using both graph methods for SoA definition [23,24] and FHIR for interoperability [25-27] has shown the value of this approach for communicating sponsor protocol requirements systematically for implementation in EHRs and similar systems [4,21,22,28-31]. The work here has re-evaluated the approach to specifying SoAs as FHIR PlanDefinitions to find solutions to several key required SoA characteristics not addressed previously. The model described here uses a radically different conceptual approach, redefining several PlanDefinition elements to be able to hold a graph representation of an SoA. The current method can successfully represent a wider range of SoA concepts than before and can also specify a large range of other SoA use cases that are key to many protocol designs (not shown). Because here all SoA requirements can be accurately specified within a single PlanDefinition, this should simplify the implementation by consuming applications. It is also clear that, with modification or the use of standard PlanDefinition elements, it can support other important SoA use cases not directly considered here (eg, protocol amendments with SoA consequences)

The methods in this study were developed using FHIR Release #5 (version 5.0.0) [1] and are not necessarily compatible with earlier FHIR versions.

The methods described in this study offer an alternative approach to defining clinical study SoAs using FHIR definitional resources compared to previously published articles and may offer advantages with regard to some key requirements not addressed by other proposed approaches.