記住我
The interoperability of clinical information is a major issue that hinders data exchange and knowledge reuse between clinical institutions []. An important type of clinical information is the representation of institution-specific care protocols, known as clinical pathways (CPs), defined as “task orientated care plans which detail essential steps in the care of patients with a specific clinical problem and describe the patient’s expected clinical course” []. This definition has been reviewed in the studies by De Bleser et al [] and Vanhaecht et al [] and further refined in the study by Kinsman et al [] through five criteria: “(1) a structured multidisciplinary plan of care; (2) used to channel the translation of guidelines or evidence into local structures; (3) detailed the steps in a course of treatment or care in a plan, pathway, algorithm, guideline, protocol or other inventory of actions; (4) had timeframes or criteria-based progression (that is, steps were taken if designated criteria were met); and (5) aimed to standardise care for a specific clinical problem, procedure or episode of healthcare in a specific population.” CPs often rely on medical evidence expressed in clinical guidelines (CGs), which standardize abstract best practices for the diagnosis and treatment of specific medical conditions based on both medical evidence and expert consensus to ultimately improve the quality and uniformity of care, describing the strict temporal order in which clinical work needs to be carried out. For this purpose, many clinical task-oriented tools have been used over the years, such as Asbru, GLIF, GLARE, PROforma, EON, or GUIDE [], but none of them seem to have reached the popularity of general-purpose process management tools such as the business process model and notation (BPMN) from the Object Management Group (OMG) [], probably because of their complexity and narrow use limited to high-technology institutions with enough financial and technical means. In the last years, BPMN, which is widely used in other industry domains, has also emerged in clinical domains as a process management standard. Many studies describe the use of BPMN to represent clinical processes to improve efficiency or serve as a basis for the development of clinical decision support systems, which require seamless integration between electronic health record (EHR) data, decisions, and the specific workflow of a medical institution [-]. Although BPMN has proven to be effective in representing clinical processes, the transition to process execution in real clinical institutions is still scarce []. Indeed, although BPMN can effectively help clinicians visually understand clinical processes and detect possible inefficiencies, the implementation of otherwise complex, stepwise clinical workflows in an ordered manner is not easy to accomplish as temporal interrelations between tasks are crucial. In the last years, new clinical-oriented process representation standards have emerged that address the specific needs of clinical workflows, such as openEHR Task Planning (TP) []. Our work is based on the hypothesis that the clinical-oriented business process management (BPM) tool TP provides a more adequate way to represent CPs, bridging the gap between abstract CG logic and clinical workflow and offering essential tools for the representation of complex health care processes such as infection treatment. In our research, we analyze how TP can represent complex infection CPs taking as a case study the catheter-related bloodstream infection (CR-BSI) CGs developed by the Johns Hopkins Hospital (JHH) Antimicrobial Stewardship Program, an international gold standard that includes recommendations aiming to standardize clinical practice around antibiotic prescription, thereby helping minimize antibiotic resistance [].
The structure of this paper is as follows: in the Introduction section, we explain the background; in the Methods section, we illustrate the methodology used; in the Results section, we describe our experiments; and, in the Discussion section, we discuss the relevance and limitations of the results.
Related WorkThe best up-to-date evidence-based clinical knowledge is usually expressed in CGs, defined as “systematically developed statements to assist practitioner and patient decisions about appropriate healthcare for specific clinical circumstances” [], often used in a paper-based mode. Many studies have successfully represented CG knowledge using different notations, such as the procedural medical-oriented Arden Syntax, rule-based systems such as Drools, guideline definition languages (Graphic Language for Interactive Design [GLIDE] and the openEHR Guideline Definition Language), or Semantic Web rule systems such as SPARQL Inferencing Notation (SPIN) or Shapes Constraint Language (SHACL) []. However, knowledge representation technologies do not suffice to represent a specific patient evolution over time, which has led to the development of medical-oriented task-based systems such as PROforma [], Asbru [], or Prodigy [], which have been successfully used in many clinical scenarios but are effectively limited to a few medical institutions owing to the high costs and efforts associated with their implementation. This has favored the introduction in the last years of popular, easy-to-use, general-purpose BPM standards in the health care landscape as a working alternative to complex, medical task-oriented knowledge systems. However, modeling specific constraints in clinical processes remains a challenge because of the intrinsic domain complexity. Much research has been conducted over the years to eliminate or compensate for the temporal shortcomings of generic BPM notations, such as with Petri nets (a graphical workflow formalism for conceptual modeling of distributed systems [,]), Process Mining for Healthcare [], or improved integration with data or decision support [,,].
Clinical ContextCR-BSI is a highly recurring infection and a major cause of morbidity and costs in hospitals. The leading cause of CR-BSI is gram-positive bacteria present in intravascular catheters, especially the coagulase-negative Staphylococcus species, which must be treated with a multidisciplinary approach based on catheter removal or catheter salvage combined with an antimicrobial lock therapy. Only in the United States, >150 million intravascular catheters are purchased by hospitals each year [,]. In addition, >250,000 intravascular CR-BSI cases happen each year, with an attributed mortality rate of 12% to 25% []. Of these, approximately 80,000 CR-BSI cases take place in intensive care units, where “more than 15 million central vascular catheter (CVC) days occur each year” []. This happens in a context of insufficient research on new antibiotics and limited supply of the existing ones, which narrows down the possible therapies for highly recurring bacterial infections, many of which are still susceptible to generic antibiotics with lower toxicity levels and lower risk of resistance development []. The treatment options for CR-BSI depend on the microorganism causing the infection, which determines the type of antibiotic and the time, frequency, and dosage of its intake. Furthermore, the type of catheter, the way it is handled, the duration of its placement, and the patient conditions codetermine the risk of a hospital-acquired CR-BSI, increasing the length of hospital stay and mortality figures especially in patients who are critically ill and whose catheter is not removed []. Therefore, specific CGs have been developed for health care staff to prevent the development of CR-BSI and issue recommendations regarding the most suitable course of treatment. The JHH CGs, based on current literature, Infectious Diseases Society of America national guidelines [], and JHH medical evidence, cover the entire infection course from diagnosis through antibiotic treatment and assist clinicians in the selection of the optimal antibiotic therapy in an attempt to fight antibiotic resistance and still remain effective [].
BPMN Process FormalismBPMN is a mature, general-purpose BPM graphical representation and ISO standard developed by OMG based on an unstructured graph-oriented language combined with features from other workflow languages that can be represented using Petri nets []. In BPMN, a process is a free sequence of activities or events ordered in a sequence flow and connected through split or merge gateways that redirect the flow into one or multiple paths. This standard has been widely used by business process managers in many different application domains owing to its simplicity. Despite not being specifically designed for clinical processes, BPMN has proven its value in the health care domain to represent CPs, allowing for an easy-to-understand representation of CP recommendations [,,,]. However, its use in clinical domains is still scarce owing to the complexity of clinical processes and organizations, the critical relevance of care protocols, the difficulties in handling temporal constraints, and the uncertainty surrounding patient evolution and treatment effectiveness []. Furthermore, the integration of BPMN process models with EHR data is usually modeled using Unified Modeling Language [] to address the BPMN shortcomings in that regard []. In addition, BPMN provides a limited set of capabilities for modeling temporal constraints [,] as the standard lacks out-of-the-box temporal semantics. Therefore, many extensions of the BPMN metadata model have been proposed over the years to address the specific demands of clinical processes [,,-].
openEHR TPopenEHR is an initiative of the openEHR Foundation working closely with the European Committee for Standardization (CEN), the International Organization for Standardization (ISO), Health Level 7 (HL7), OMG, and other organizations on EHR and clinical modeling standards that provides an archetype-based standard data model for EHR systems designed with interoperability in mind []. In 2016, the openEHR Foundation released a new clinical-oriented workflow management standard, the TP specification, that includes a Visual Modeling Language (TP-Visual Modeling Language [TP-VML]) backed up by formal semantics, which ultimately would allow for the automatic translation of graphical workflow models into executable models [,]. TP complements openEHR by allowing modeling orders and actions in the future, structured as work or task plans, as well as their eventual execution in distributed environments, improving features partially present in other workflow languages (BPMN, Yet Another Workflow Language [YAWL] [], Case Management Model and Notation [CMMN] [], or Decision Model and Notation [DMN] []). The TP engine executes both TP work plans and openEHR Decision Language (DL) rules []. Moreover, TP allows for the specification of complex times in medication orders (eg, “3 times a day before meals” []), and it is conceived as a clinical process navigator, empowering users to perform ad hoc modifications at the time of execution to reflect real-time changes and supporting auditing, reporting, and billing to analyze task performance, execution, and eventual deviations from the original plan. Although openEHR has a wide coverage as a research area [-], the TP specification has been used in fewer studies [-] and is still under development. The contributions of our work to support our hypothesis of the native suitability of clinical-oriented BPM formalisms for infection CPs are as follows: (1) identification of key features required for modeling infection CPs, as laid out in the literature, the JHH CGs, and the successive BPMN extensions; (2) theoretical analysis of how TP addresses the identified key features; (3) a case study to empirically show the native TP adequacy by modeling typical CR-BSI infection patterns using TP; and (4) analysis and proposal of potential extensions of the current version of TP for improved modeling of infection CPs and possibly of other complex CPs.
Our research aimed to explore and identify key features to represent infection CPs to then analyze how they are present in the TP standard. The analysis can lead to a potential list of benefits and possible improvements for the representation of infection CPs using TP. For this purpose, in this study we adopt the methodology illustrated in .
Figure 1. Methodology followed. BPMN: business process model and notation; CR-BSI: catheter-related bloodstream infection; TP: Task Planning; TP-VML: Task Planning Visual Modeling Language. View this figureStep AWe identified key features required for modeling infection CPs by reviewing scientific literature, BPMN extensions in clinical settings, JHH CGs, and an extended BPMN-based model of JHH CR-BSI. The identified key features formed a basic set of requirements that served as a starting point to analyze the theoretical adequacy of TP for the representation of infection CPs.
Step BWe conducted a theoretical analysis of the presence of the previously identified key features in the TP specification by performing an in-depth evaluation of the current version of TP to understand how these capabilities were addressed by the standard. When possible, a one-to-one comparison of both standards’ capabilities was performed, which could help identify possible improvements. In addition, when new, potentially interesting TP capabilities were detected, we discussed their relevance.
Step CWe conducted an empirical test of the suitability of the current version of TP for conceptual modeling of infection CPs. To that end, we modeled typical infection treatment patterns from the JHH CR-BSI CGs using the same logic used in the extended BPMN version []. When opportunities for improvements were detected, we proposed alternative TP models.
Step DTaking the output of steps B and C, we proceeded with the analysis of benefits and potential enhancements to the current version of the TP standard and made a proposal of possible extensions to improve the representation of infection CPs. For this purpose, we followed the steps of the methodology for BPMN extensions laid out in the study by Braun and Schlieter [], which we consider adequate for TP.
BPMN has been extended over the years with domain-specific concepts to meet the main requirements of process representations in clinical domains. Therefore, an analysis of the BPMN missing capabilities through its extensions in clinical settings is essential to identify key features that any CP representation should fulfill. Furthermore, any language for modeling CPs should contain (1) concepts for medical business process modeling (patient state, treatment step, decision, or process flow) plus the ability to integrate information objects and responsibilities, (2) indefinite order relations as well as compulsory parallel relations between treatment steps and iterating treatment steps, (3) the evidence class of any recommendation and decision and a link to the source of the evidence, and (4) temporal dependencies and explicit time events [].
The key features proposed in this study were derived from an analysis of existing literature selected based on quality and content regarding (1) BPM extensions in clinical domains affecting the representation of, among others, time, resources, and coordination of CPs by multidisciplinary teams working together in a care process [,-,,-]; (2) review studies of BPMN extensions both in clinical and nonclinical domains []; and (3) analysis of JHH CG features for infection management [,,], such as parallel work, synchronization with EHR data, or uncertainty in the course of an infection treatment. Although broadly inclusive, our criteria were proposed as a set of minimum requirements to represent infection CPs. First, the well-structuredness of a process conceptual model helps increase its legibility and understanding by clinical staff, thereby enabling the detection and analysis of possible process improvements. In addition, it is a requirement to avoid deadlocks and inconsistencies in and between processes, thereby facilitating the future maintenance and evolution of the process representation. Process modularity allows for the decomposition of large, complex clinical processes with many involved parties in their constituent subprocesses, thereby allowing for increased readability, process reuse, and faster model building and verification of soundness across the organization. Events allow for conceptual modeling of facts that take place at the time of execution, the occurrence of which is possibly unknown at the time of design. Events deal with uncertainty and are always present in the treatment of infections, whose course depends on factors unknown at the time of design, such as the patients’ eventual response to medication. Parallel execution of tasks optimizes execution time to promptly react to clinical happenings as clinical institutions consist of complex multilayered organizational units, possibly externalized and interacting with each other. Task duration allows for the expression of a constraint, a deadline, or simply information to all process actors. For example, a blood test can take a minimum of 1 day and a maximum of 2 days to complete. If purely informational, workflow execution should not wait for this task to complete but, if meant as a constraint, the model should include semantics to hold the execution of subsequent tasks. The time distance between nonconsecutive tasks can be specified using relative time constraints such as edge duration between the starting or ending instant of a predecessor task A and the starting or ending instant of a successor task B. These constraints are determined by best practices or the institution’s average figures to define a minimum or maximum waiting time when dispatching work to other organizational units. Synchronization between subprocesses is ultimately reduced to the synchronization between their inner tasks. Use of resources is relevant in infection CPs as catheters are a main cause of infection in hospitalized patients, requiring both catheter lock therapy (CLT) and systemic therapy (ST) applied repeatedly and alternatively but not simultaneously through the existing catheter, which must therefore be used in exclusive mode by the executing task. Multiple instances of a task might be required to unfold repeatable tasks such as therapy or follow-up tasks, although, in many cases, their multiplicity level is unknown at the time of design and can only be determined at the time of execution (either by the user or by the process logic) as it depends on the clinical evolution of a patient or the adequacy of the prescribed treatment. Delays between iterations of looping activities, executed as long as a loop condition evaluates to true, allow for the expression of things such as “Vancomycin every 8 hours during 7 days” []. Furthermore, the integration of clinical data is useful for reviewing the availability of process-required data, their location, or the detection of inconsistencies or potential improvements. Data are used for input or output to make decisions, initiate a process, coordinate tasks, or inform process actors, whereas data stores allow for data persistence beyond the execution of a process model. In addition, in infection CPs, a close relationship between EHR information and model metadata is required to be able to dynamically adapt to clinical happenings. Finally, overrides at execution time, either by the user or the system’s logic, are required to deal with unexpected happenings during the course of an infection, which can unleash relevant changes in the care process.
Step B: Identification of Corresponding TP Features for Infection CPsThe TP specification is natively oriented toward the conceptual modeling of clinical processes, thus theoretically providing out-of-the-box capabilities that are present in BPMN only after successive extensions. In this section, we analyze how TP supports the key features identified in the previous section. First, well-structuredness is a built-in feature in the TP standard semantics, which impose implicit restrictions on a process model. Process modularity is achieved in TP by the intrinsic grouping of reusable pieces of work in work plans, task plans, and, optionally, subplans for fine-grained work details. TP events regulate the temporal behavior of TP tasks or task groups by means of task-waits that prevent task execution until facts occur that satisfy a wait condition, such as the occurrence of a task transition or changes in global tracked variables. Parallel execution of tasks can be achieved in TP using the execution type attribute of the plan item top-level class. In addition, conditional decision structures exist to represent if-elseif-else, case, or event-based conditions, and the optional concurrency-mode attribute defines 4 possible states of a task group during and after the execution of its conditional paths. However, task duration, either as constraint or merely informative, does not exist in the current version of TP. When duration is meant as a constraint, TP implements this behavior through task-waits associated with events instead. Relative time constraints between tasks are managed in TP through task-waits for both deterministic and nondeterministic events combined with the use of dispatchable tasks. Resources are minimally represented in TP through Resource_Participation objects required for task execution. The allocation and tracking of workers to a task or task group is done at the time of execution as part of the materialized model (ie, the M* classes, which are only minimally specified in the current TP version). Multiple instances of a TP task can be dynamically generated at the time of execution if they are marked as repeatable in the process model by the optional repeat-spec attribute, which specifies the minimum and maximum number of iterations, and an optional terminate condition to exit the repeat loop. Each iteration is unrolled into literal sequential copies in the materialized image of the work plan. Delays between iterations of looping tasks or task groups are possible with the optional period attribute of a repeat-spec associated with a repeatable task or task group to be able to express things such as daily every 8 hours, acting as a spacer between the execution of the literal copies of each iteration. Furthermore, clinical data integration is indirectly achieved through the capture data set attribute, a data set template or form via which data can be introduced during task execution. As TP is part of the openEHR standard, data references are encapsulated using archetypes, so the template-id attribute specifies the archetype human-readable identifier (HRID) to be used, triggering the population of a data set []. Finally, overrides at execution time are built-in in TP, which by default assumes that, at the time of execution, users can have information that is unknown to the system for any number of reasons. The designed process model is performed in an advisory, adaptive way, allowing for logical deletion and addition of tasks at runtime and override of plan parameters such as task execution time or preconditions []. shows the list of the identified key features and their coverage in extended BPMN and TP.
Table 1. Coverage of key features in the extended business process model and notation (BPMN) and Task Planning (TP).FeatureExtended BPMNTPStructured workflow definitionSESEa restrictionsBuilt-inProcess modularityCall activityDispatchable tasks or task hierarchy or subplansEventsTimer or signaling eventsSpecialized task transition and state trigger events, among othersParallel executionGatewaysExecution type and concurrency modeTask durationBPMN extensionN/AbRelative time constraints between tasksBPMN extensionBuilt-in task-waitsUse of resourcesMinimally definedMinimally definedMultiple tasksMultiplicity markerRepeatable tasksDelays between task iterationsN/ARepeat attribute “period”Data integrationN/A, uses UMLcCapture data sets or subject’s proxy servicesOverrides at the time of executionOnly add activities and eventsBuilt-in (remove or add tasks, plan parameters, or subject preconditions)aSESE: single entry, single exit.
bN/A: not applicable.
cUML: Unified Modeling Language.
Step C: CR-BSI Case StudyTypical Process Patterns in Infection TreatmentThe treatment of infections shares some common distinctive patterns that are typical of diseases caused by bacterial microorganisms. First, all types of infections require laboratory tests to determine the pathogen causing the infection in the first place to decide on the most effective antibiotic treatment. In addition, infections must be treated readily to avoid complications that could become life-threatening, following empirical evidence laid out in CGs even though laboratory results are not yet known. Furthermore, antibiotic treatment must follow strict administration rules to be effective, such as dosage, frequency, and duration. Finally, patients must be monitored throughout the entire process to quickly adjust the treatment in case problems arise. We represented some of these distinctive patterns of CR-BSI in TP to empirically check the suitability of TP for modeling infection CPs. The CR-BSI process patterns were originally elicited from the JHH Antibiotic Guidelines []. The BPMN-based CR-BSI process models [,] contain both standard BPMN flow objects and extended elements such as task and edge duration. For modeling the CR-BSI TP flows, we used the open-source draw.io tool, importing the TP-VML libraries []. shows the correspondence of the extended BPMN process models from the studies by Zerbato [] and Zerbato et al [] with the TP process models depicted in this study.
Table 2. Correspondence between extended business process model and notation (BPMN) and Task Planning process models of catheter-related bloodstream infection.PatternBPMN figure numberDescription15 []ETa (generic)2NoneDetermination of ET33 []Staphylococcus aureus treatment44.1 []CLTb in coagulase-negative StaphylococcusaET: empiric treatment.
bCLT: catheter lock therapy.
Process Patterns in CR-BSI TreatmentWe modeled the process patterns of CR-BSI () using TP, maintaining the same logic and assumptions made in the study by Zerbato et al [] when interpreting the JHH CGs.
Process patterns of catheter-related bloodstream infection (CR-BSI).Process patterns
Empiric treatment (ET): when suspicion of an infection exists, the clinical approach is to immediately start treating the patient with a wide-spectrum antibiotic following the empirically gained knowledge laid out in clinical guidelines (CGs) while laboratory tests are ordered in parallel to identify the causing microorganism. As soon as laboratory tests are available, the ET is revised and adjusted if required, either by changing its dosage or duration or replacing it with an organism-specific antibiotic for the concrete pathogen causing the infection.Determination of ET: this is typically a cognitive decision task that allows clinicians to select the best course of treatment based on CGs or clinician knowledge, clinical facts, and available culture results, if any.Staphylococcus aureus treatment adjustment: infection treatment usually involves strict management of temporal constraints as antibiotics need a specific administration pace and duration to be effective. During infection treatment, patient evolution and vital signs are continuously monitored to quickly adjust the originally prescribed therapy (eg, its dosage or duration).Catheter lock therapy (CLT): many infections are caused by the use of catheter implants in hospitalized patients, of which CR-BSI or urinary tract infections are typical examples. Intravascular catheters routinely develop microbial communities (biofilms) upon contact with environmental or skin pathogens. When such infections occur and the catheter cannot be removed as it can be counterproductive, antibiotic locks are recommended by CGs as complementary therapy so that both the systemic infection caused by the catheter and the area around the catheter are treated. This means that the systemic therapy must be repeatedly but not simultaneously applied with the CLT during a certain period. Both therapies use the same catheter as the vehicle for treatment, so the catheter becomes a shared resource that must be locked exclusively by each therapy task to prevent simultaneous use.Textbox 1. Process patterns of catheter-related bloodstream infection (CR-BSI).Pattern 1: Empiric TreatmentThe empiric treatment pattern () illustrates the relevance of repeat loops and nondeterministic events in infection CPs. We represented a TP parallel AND-all-paths task group with 2 distinct branches: branch 1 represents the ordered set of laboratory tests, whereas branch 2 represents the ET administration. As more than one laboratory test is ordered, a second inner AND-all-paths task group is modeled to indicate that all cultures need to be completed to be able to interpret the results. Once they become available, a nondeterministic task transition event is fired, signaling the ET repeatable task, which has the laboratory tests transition event to the complete state as repeat terminate condition, ultimately interrupting the ET task.
This pattern was represented in extended BPMN [] using deterministic events instead.
Figure 2. Catheter-related bloodstream infection empiric treatment (ET) pattern 1 using Task Planning Visual Modeling Language. View this figurePattern 2: Determination of Empiric TreatmentThis pattern shows the relevance of encapsulating decisions in rules, which was not possible in BPMN. In case of CR-BSI being suspected, the determination of the empiric treatment requires gathering epidemiology information from the hospital. If methicillin-resistant bacteria have high prevalence, a wide-spectrum antibiotic (Vancomycin) is usually recommended. Otherwise, a decision between different antibiotic treatments is taken (empiric treatment 1-4 for simplicity) based on the suspicion of a pathogen and on patient conditions. shows a representation using a gate task group for the binary decision high–methicillin-resistant bacteria present, which, if positive, includes a nested case task group with multiple exclusive treatment choices and an inner second binary gate to decide between empiric treatment 2 and empiric treatment 3.
However, this pattern can be easily representable via a decision table, so we would rather model it in TP using a DL rule evoked from a determine ET task, which would encapsulate the knowledge associated with this decision in a single rule to be further maintained and evolved by knowledge experts, allowing for the separation of concerns ().
Figure 3. Catheter-related bloodstream infection determination of empiric treatment (ET) pattern 2 using Task Planning Visual Modeling Language. View this figure
Figure 4. Catheter-related bloodstream infection determination of empiric treatment (ET) pattern 2 using Task Planning Visual Modeling Language with a Decision Language rule. View this figurePattern 3: Staphylococcus aureus Treatment AdjustmentThis pattern showcases the importance of overrides in dealing with uncertainty during the course of an infection treatment. The JHH CGs state the following: “Criteria for a 14-day course of therapy: patient is clinically stable; follow-up blood cultures drawn 2-4 days after the initial cultures are negative for S. aureus; the patient defervesces with 72 hours of initiation of effective antistaphylococcal therapy. All other patients should receive 4-6 weeks of therapy based on extent of infection” [].
shows a possible TP model using deterministic events, as in the study by Zerbato et al []. The decision review duration is a subplan that decides whether therapy duration should continue as planned or be prolonged to a minimum of 28 days and a maximum of 42 days. We used a parallel and-all-paths task group with 2 branches: the first branch is a parallel task group follow-up representing the measure temperature and check culture results timeline-driven tasks executed at day 3 and 4, respectively, after treatment start and the second branch is a repeatable task group that executes the initial 14-day short therapy. Once the follow-up branch ends, the review duration subplan is launched asynchronously to determine if the short therapy should be prolonged. When the short therapy ends, and only if a longer therapy was decided, a therapy extension repeatable task is launched until the minimum number of iterations (14) is reached. From that moment on, therapy can be interrupted through a repeat-spec terminate condition if a state trigger event signals positive patient evolution. The therapy extension cycle will end either when patient evolution is positive or, in the most extreme scenario, when the repeat.upper limit (28 in our case) is reached. Although this is a good example of how repeatable tasks are of great value for the representation of the course of treatment of infections, we had to perform some calculations with the days to faithfully represent the CPs. For simplicity, we assumed that the treatment was applied once daily but, in reality, antibiotics must be taken in strict time intervals expressed in hours rather than days. Alternatively, a DL rule can be introduced to assess patient evolution as part of the decision logic that determines either a short or a long therapy.
The previous deterministic scenario could be improved, as shown in . The main difference is that, in case treatment duration is prolonged by the adjust treatment task, a capture data set (form) would collect the new treatment information, update the EHR subject’s proxy relevant variables accordingly, and trigger a new repeat override-condition that would reset the repeat attributes to repeat.lower=28 (instead of 14) and repeat.upper=42. However, this behavior has several implications that will be discussed in the following section.
Figure 5. Catheter-related bloodstream infection Staphylococcus aureus (S. aureus) treatment adjustment pattern 3 (P3) using Task Planning (TP) Visual Modeling Language. JHH: Johns Hopkins Hospital. View this figure
Figure 6. Catheter-related bloodstream infection Staphylococcus aureus (S. aureus) treatment adjustment pattern 3* using extended Task Planning (TP) Visual Modeling Language. JHH: Johns Hopkins Hospital. View this figurePattern 4: CLTThis pattern illustrates task synchronization when sharing a common resource in exclusive mode. CLT is a technique meant to reduce treatment failure that fills up a catheter with an antimicrobial agent and lets it dwell for a long-enough period. CLT must be administered through the same catheter used for ST, so task synchronization is essential to guarantee catheter availability. Owing to the lack of details in the JHH CGs regarding the alternation and frequency of CLT, we made a few assumptions: (1) both therapies are repeated within fixed but possibly different periods, (2) their timing is independent from each other, and (3) they take place at random but predictable times. With these premises, we modeled 2 repeatable parallel task groups: one including the CLT task and the other including the ST task. Both task groups first execute an instrumental “catheter lock” plan to issue an exclusive hold on the catheter as soon as it becomes available and end with a catheter release. The catheter lock includes a repeatable task group that checks catheter availability and ends as soon as the catheter becomes available, moment at which the catheter is locked, and a callback notification is sent to the calling task (either ST or CLT). Once the corresponding therapy task is executed, the trailing catheter release task is called to release the catheter ().
Ideally, this lock mechanism should be a built-in behavior in TP when a resource is defined as exclusive, greatly simplifying the process model as both the instrumental catheter lock and the catheter release task plans would not be necessary ().
Figure 7. Catheter-related bloodstream infection catheter lock therapy (CLT) pattern 4 using Task Planning Visual Modeling Language. CG: clinical guideline; JHH: Johns Hopkins Hospital; ST: systemic therapy. View this figure
Figure 8. Catheter-related bloodstream infection catheter lock therapy (CLT) pattern 4* using extended Task Planning Visual Modeling Language. JHH: Johns Hopkins Hospital; ST: systemic therapy. View this figureStep D: Analysis and Possible ExtensionsOverviewWe were able to model typical process patterns of CR-BSI in TP (-) keeping the logic applied to the interpretation of the JHH CGs in the study by Zerbato et al [] with no amendments or extensions to the current version of the TP standard. According to the 4 requirements for CP languages [], the TP specification fulfills requirement 1 with the openEHR architecture and foundation classes as well as many of the requirements 2, 3, and 4 by means of parallel concurrency modes extensible with specific rules, dispatchable and performable tasks associated with defined actions, or temporal constraints between tasks using advanced events. In this study, we in fact analyzed the suitability of domain-specific features of requirements 2 to 4 for infection CPs. However, in some cases, we depicted alternative process models using a different approach (eg, pattern 3* and pattern 4*) by proposing extensions that enhance the TP standard capabilities for modeling infection CPs, such as new annotation capabilities of tasks, enhanced cyclic constructs, new override behavior of the TP engine, new events, and enhanced resource management. To determine these potential TP extensions, we followed the methodology proposed in the study by Braun and Schlieter [] for BPMN extensions, which we consider applicable for TP, consisting of 6 steps that extend the approach of Stroppi et al [], resulting in an equivalence or no equivalence conclusion. A no equivalence conclusion can have 3 reasons: (1) the entire concept is missing (extension concept), (2) a relationship between 2 concepts is missing (association between concepts), or (3) attributes owned by a concept are missing (property of a concept).
shows a summary of the main TP constructs used in the CR-BSI models. Models where an extended approach was proposed are denoted by a trailing *.
In the following sections, we analyze the most frequently used TP constructs and their possible improvements, which could lead to potential extensions of the standard.
Main Task Planning (TP) constructs used in each use case.TP construct and patterns in which it was used
And-all-paths parallel task group (TG): pattern 1, pattern 3, pattern 3*, pattern 4, and pattern 4*Repeat task or TG: pattern 1, pattern 3, pattern 3*, pattern 4, and pattern 4*Gate binary decision group: pattern 2, pattern 3, and pattern 3*Timeline event: pattern 3 and pattern 3*Asynchronous dispatchable task: pattern 3 and pattern 3*Task transition event: pattern 1 and pattern 3*Synchronous dispatchable task: pattern 4State trigger event: pattern 3System notification event: pattern 4Case decision group: pattern 2Decision Language rule: pattern 2*Textbox 2. Main Task Planning (TP) constructs used in each use case.Parallel Execution and Decision-making ConstructsThe 4 TP concurrency modes associated with the parallel execution type cover a wide range of situations that might arise in actual clinical scenarios and were expressive enough for the representation of CR-BSI patterns. The and-all-paths concurrency mode was most frequently used, followed closely by the gate decision group construct, for single binary decisions. Occasionally, we used a case decision group in pattern 2, a cognitive diagnosis decision-making task that can be better represented as a single DL rule. Throughout the modeling process, we did not detect any need for improvements in the existing TP decision constructs or in parallel execution. However, the standard allows for the definition of rules if more sophisticated parallel behavior is required in complex scenarios.
Repeatable Task ConstructsThe second most used TP construct was the task or task group repeat, widely used for medication plans, therapy administration, or monitoring of patients’ vital signs. Antibiotic treatments usually have the form Ciprofloxacin 400 mg IV Q8H, which can be represented in TP using the repeat attribute of a plan item, which unfolds copies of the successive antibiotic intakes in the TP execution engine. This attribute specifies a minimum and, optionally, a maximum number of iterations, a time interval or period between iterations, and a terminate condition evaluated as soon as the minimum number of iterations is reached before the execution of new iterations. The terminate condition can be any plan definition event exiting the repeat loop whenever event conditions are met. The TP repeat construct is a hybrid loop as it mimics both a for programming loop until the repeat.lower limit is reached and, after that, a while programming loop. This construct has proven to be essential for modeling CR-BSI CPs, which is why it could be further enhanced to achieve its full potential. For example, in pattern 3, treatment duration is adjusted on the fly when the patient does not evolve as expected—the treatment starts as a 14-day–long repeatable short therapy task and transitions smoothly to a 28- to 42-day therapy extension. The model is improved in the alternative pattern 3* to avoid the need to represent 2 distinct therapy tasks by proposing a mechanism to signal a repeatable task not to terminate but to modify its attributes while still running; that is, an override of the TP metadata model triggered by the process intrinsic logic. The main advantage of pattern 3* is a much simpler visual representation and a more powerful repeat construct with adaptive capabilities to respond to events not known at the time of process design. However, this behavior assumes a few things: first, the patient’s medication record is stored in the EHR and available to the TP engine; second, whenever treatment is adjusted, it first updates the EHR through a capture data set, generating a new medication instruction; third, there is some predefined mapping mechanism between the medication instruction and the repeat metadata, used by the TP engine upon the execution of the adjust treatment task (eg, taking the information in the ORDER REF class, which “represents a logical tracking reference to one ‘order’ in the real world” []); finally, the pattern 3* model would also require modifications in the TP abstract syntax, a new repeat override condition attribute in the Task_Repeat class to trigger the reset of the repeat attributes using the new treatment information in the subject’s proxy (), and changes in the TP engine to keep internal state records of repeat iterations and dynamically update the materialized literal copies, unfolding pending iterations and considering the ones already consumed.
The Task_Repeat attributes would be automatically bound to the patient’s EHR medication record through a defined action associated with the task and its corresponding prototype based on its turn on a medication archetype containing a structured description of the therapy administration and time. When the adjust treatment task is performed, an action instance would be created from the prototype reflecting any divergences from the planned form of the task. To support this scenario, we suggested the extension of the Task_Repeat class, as outlined in .
The execution logic of our extended Task_Repeat class would be as follows: if start-condition is true and repeat.lower is >0, a loop is started of 1 to repeat.lower iterations (the for part of the repeat loop). This minimum number of iterations is executed unconditionally unless a skip-condition is met in any of the iterations. Only when iteration number repeat.lower+1 is reached the rest of the conditions could apply; that is, an override or terminate condition.
Figure 9. Possible mechanism of Staphylococcus aureus treatment adjustment pattern 3* with repeat override condition. EHR: electronic health record; GUI: graphical user interface. View this figureTable 3.
Proposed new attributes of Task Planning classes.Class and attributeExplanationPossible valuesTask_RepeataDL: Decision Language.
bN/A: not applicable.
Resource ConstructsIn infections, catheters are used as a vehicle for the administration of different therapies sometimes incompatible with each other, as we have seen in pattern 4 with CLT and ST, where we had to define 2 instrumental catheter lock and catheter release tasks, unnecessarily increasing flow complexity. In the alternative pattern 4* model, we eliminated the need for them by extending the resource participation class with new attributes to represent clinically relevant resources, the state of which can change at the time of execution owing to unexpected clinical happenings. This would require a resource state machine in the TP materialized model, similar to the TP engine task state machine, that would help improve the resource perspective of the TP standard, similar to how it was done for BPMN []. Accordingly, the TP engine should adopt a new specific behavior for resource allocation or deallocation at the time of execution. In the pattern 4* model, the catheter resource could be tagged as of exclusive mode so that the TP engine can exclusively allocate the resource to the executing task, implementing a built-in exclusive lock and release strategy to avoid deadlocks. shows the proposed new attributes of the Resource_Participation class.
The proposed extensions affect the abstract syntax; that is, the TP standard metadata model and the TP engine logic. In addition, the EHR could document resources used in the patients’ medical procedures, especially those implanted that can cause or aggravate an infectious disease. For example, in CR-BSI or urinary tract infection, it is relevant to know if the catheter has been removed, irrigated, replaced, or salvaged to determine treatment duration.
EventsThe TP task-waits allow for the introduction of dynamically determined delays between tasks, adding fundamental modeling capabilities through the use of specialized, nondeterministic events: task transition, state trigger, callback, manual, and system notification. The task transition event makes use of the TP engine state machine representing all possible states and transitions between tasks, which is essential for dynamically detecting task completion in infection treatment processes. The state trigger event signals changes in the values of global monitored varia
留言 (0)