Hybrid Clinical Pathway Approach

The “hybrid” approach represents an end-to-end development pattern starting with designing a clinical pathway and ending with an operational solution. The Hybrid Approach separates the design of the clinical pathway from the execution platform  that consumes and executes the design artifacts.  The goal of this separation  is to enable the pathways developed by leading hospital systems and professional organizations to be sharable by different organizations. This should lead to better healthcare outcomes as well as being able to amortize the cost developing the design because the pathways are shareable.

Another goal of the hybrid approach is to  enable process improvement. The key principle for achieving this goal is the decomposition of the design element and the implementation into separate areas of concerns. This isolates changes within one of the areas and thus simplifying process improvement.  At the present time, the identified components of the hybrid approach  are process, data, and services. This separation of concerns is applied to the design segment and the implementation platform.

The third element of the hybrid approach is “loose coupling” between the components so that a change in a component does not necessitate change in other components. This ensures that change is again isolated to a signal component and a transformation service which is designed to manage change. There are several techniques to accomplish this loose coupling, such as using APIs that provide an abstract interface to multiple implementations for the same service or adaptors that provide transformations between the components.

The final consideration is that the promise of the hybrid approach could not be achieved without standards. For the initial effort, the focus has been on HL7 Standards FHIR and augmented with OMG standards.

State of Hybrid Approach

Significant effort has been put forward by the HL7 FHIR community to progress standards to be able to address clinical pathways, especially in the domain of executable pathways. In addition, the BPM+ Health community with the OMG has expended  significant efforts to progress a model-driven design for healthcare.

To test the hybrid approach, the hybrid work stream was formed for the September 2020 FHIR Patient Management Track. As this was the first effort to test the hybrid approach, the scope was limited to the published Intermountain Hypertension Clinical Pathway. For the design elements, the following table represent the standards and tools that were investigated:

For the executable platform elements, the following table represent the standards and tools that were investigated:

For the executable platform elements, the following table represent the standards and tools that were investigated:

Lessons Learned from 9/2020 Connectathon

Process Design

• Pros:

o   During the connectathon, the diagrams produced by the design tooling was excellent for the different roles needed in developing a clinical pathway to communicate effectively and efficiently with one another.  This is of HIGH value.

• Concerns:

o   Designs produced by Red Hat tools were not consumable in Trisotech runtime environment and designs produced in Trisotech tools are not consumable by the Red Hat runtime environment.

o   The design tools do not import work product and domain knowledge captured in HL7 Logical data standards. The OMG SDMN is a potential approach to this solution, but it is a work in progress and there is no known implementation.

• Areas to Investigate:

§  The clinicians recommended that the diagrams produced by the tooling be able to produce customized views of the diagrams based on the audience, aka the roles of the actors, for even more effective communication.

Logical Data Design

• Pros:

o   The critical importance of being able to specify the exact data necessary to execute the specific clinical pathway was indisputable. The term Situation Data will be used to describe this data for the pathway.

o    The HL7 ANF standard provided promise as a semantic foundation providing logic data descriptions.

• Concerns

o   The logical design of data concepts is presently driven by the process design tools and does not leverage the domain knowledge of HL7 standards.

o   Situational Data is required for execution by the process implementation engines.  a FHIR resources and profiles are not sufficient to providing the full set of information required.

• Areas to Investigate

o   Promise of using ANF, MDMI, FHIR, descriptive logic, and LOINC/SNOMED terminologies showed promise in formulating and producing Situational Data needed in process engines. 

Decision Services

• Pros

o   DMN and CQL were very useful.

• Concerns

o   There is no plug-and-play capability at the logical level for decision services; the APIs across decision services is not standardized.

o   Authors of decision services have the option of calling decision logic at runtime as a task or as a service, making clinical pathways less re-useable.

• Areas to Investigate

o   Having an abstract API to call decision services.

o   Request the BPM+ authoring group consider that decision logic be implement as a service in clinical pathways.

Orchestration Runtime Engine

• Concerns:

o   There was no known loosely coupling of Orchestration Runtime Engines to Process Designs. Process Design were implementable only within the vendors technology stack.

• Areas to Investigate

o   Mechanisms to test the ability of different orchestration engines to consume different artifacts produced by process design tools.

Data Servers

• Pros:

o   We were able to plug-and-play different implementations of FHIR servers.  This specific path is solid and of HIGH value.

• Areas to Investigate

o   Investigate the value proposition for inclusion of non-FHIR servers. Possible candidates are IHE implementations, OpenEHR implementations, HL7 V3 implementations, or an existing proprietary data server.

Adaptors and Abstract APIs.

• Data Adaptors

o   Pros:

§  MDMI was shown to be able to use ANF and FHIR data to transform it into a form that can be consumed by the Orchestration Runtime Engines and the Decision support runtime engines.

§  MDMI provides loose coupling and the necessary transformation services between the design and execution engines.

o   Areas to Investigate

§  See Data Logic Design above.

§  Investigate decision logic (rules) adaptors.

• API

o   Areas to Investigate

§  Investigate if there are existing approaches to providing abstract interfaces to Decision Services.