Producing Shareable Clinical Pathways

Overview

Shareable clinical pathways are workflow definitions that outline the necessary steps and goals in the care of patients with certain conditions. Clinical pathways outline clinical guidelines and the reusable, shareable practices that provide a link between clinicians, patients, and clinical environments. Communication can be improved with clinical pathways; clinicians, patients, and care team members are given the same steps and goals to ensure common practices and goals. It is with this coordination that clinical pathways aim to improve the coordination and outcomes of care over time.

The objective of creating these shareable clinical pathways ischallenging one. but by applying the following patterns and principles it is possible to construct the such clinical pathways.

Qualities of Clinical Pathways

As with all interoperability work, the creation of shareable clinical pathways comes with significant challenges that must be overcome to realize potential benefits. Clinical pathways are a complex and difficult to define concept. Because there must be both an appropriate amount of flexibility and standardization built into a clinical pathway, modelers are faced with numerous challenges of creating such pathways. In order to produce shareable clinical pathways, modelers must first create a language of patterns that define the qualities needed to produce such precise and objective pathways.

Initial Patterns Identified

Semantic Clarity / Pathways must be defined in such a way that there is no room for interpretation of meaning
A Complete Solution / Every aspect of the pathway must be defined. Incomplete pathways lead to local customization for completion, devaluing the use of such pathways
Focused Pathways / The pathway must be specific and targeted. Vague and large-scale pathways cannot be easily shared

Clinical Pathway Principles

The following principles are typically associated with object-orientated development but need to be incorporated in the design of sharable clinical pathwayscomponents to ensure precision, clarity, and reusability.

Open and Closed Principle

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.

The Open ClosedPrinciple is probably the most fundamental principle enabling the development of shareable clinical pathways. This principle can be applied to a complete pathway as well as individual components within the pathway. In the context of a pathway, an organization does not need to modify the flow of events and logic to use the pathway but can customize the flow by extending components of the flow to match their environment.

Using the example of a pathway supporting the treatment of an ankle injury, there would be a goal to reduce swelling. If the pathway defined an event: “Apply Ice Cubes,” and an organization used a “Cold Pack” rather than “Ice Cubes,” the organization would need to modify the pathway to say “Apply Cold Pack,” breaking this principle. If the pathway defined the event as “Apply Cold Treatment,” the organization could extend the event locally by adding “Apply Cold Pack” if needed. If each organization needed to materially modify a pathway, the benefits of such a pathway are lost.

Liskov Substitution Principle

FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.

As with clinical pathways- defining a component for use within a shareable pathway – there is an intrinsic need to design by contract and as such the use of such a derived component meet the requirements for such a contract.

Design by contract becomes particularly important in working with decision points within the workflow. The workflow must rely on all DMN returning the same 1 to many results regardless of the localization of the DMN. The workflow cannot be designed in such a way that it needs to integrate the localization of the DMN to continue processing. Take for instance a sample decision point in a shareable workflow determining “Is ankle broken” returning two decisions “YES/NO”. While it might make sense for a localization to have a response of “MAYBE” this breaks this principle because the shareable workflow is expecting “YES/NO”. An appropriate design would have the shareable workflow expect “YES/NO/MAYBE” as a result and while some localizations would never turn MAYBE the principle is upheld.

Dependency Inversion Principle

HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.

ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS.

The proper application of the Dependency Inversion Principle is necessary for the creation of reusable frameworks. This is critical in the production of shareable clinical pathways.

Applied to the development of clinical pathways, events within a clinical pathway need to be designed in such a way that their verbiage is not dependent on the context of execution, rather they are applicable to many contexts. If, instead of “Apply Cold Treatment,” the pathway stated “Apply Cold Treatment to Left Ankle” it wouldclearly limit the use of such an event to pathways dealing specifically with left ankle injuries. This might seem trivial in nature but highlights the need to define reusable events and decisions as a cornerstone to providing a framework of shareable clinical pathways. If the decision or event cannot be used in multiple pathways without modification it does not follow this principle.

One last pattern: A Ubiquitous and Pervasive Perspective

Pervasive computing is a natural extension of the existing computing paradigm.In the pervasive computing vision, software agents, services, and devices are allexpected to seamlessly integrate and cooperate in support of human objectives – anticipating needs, negotiating for service, acting on our behalf, and deliveringservices in an anywhere, any-time fashion

The perspective of the CP needs to build upon the notion of ubiquitous and pervasive computing to provide a complete and implementable workflow. The

Standard Ontology for Ubiquitous and Pervasive Applications(SOUPA) provides such a perspective to allow the identification and classification of elements of the workflow. This ontology might not be complete but does provide a set of understandings we can apply to define and model workflows

Using the ontology, if we start to recognize events as activities that have both spatial and temporal extensions we then can leverage the definition of SpatialTemporalThing to quickly understand the parts of the event that relate to timing and location of such events. This classifications and ones like it are critical in the development of solutions taking shareable CP and generating/transforming them into executable platform specific CP.

The following are placeholders for future work

A Domain Specific Language for Clinical Pathways

What we have described here is the basics for a DSL supporting the development of CP that are indeed sharable and to some extend automated. …..