Lessons Learned So Far...

Owned by Sean Muir
Last updated: Jul 24, 2020 by Ken Lord
2 min read

 

The following are meant to be a laundry list of lessons learned from experiences applying computable clinical pathway methodologies and technologies. The list is not meant to be exhaustive but to capture/document issues so appropriate steps can be taken to mitigate the issues in the future. The list is not ordered. These experiences are the author and do not represent official comments from logica etc

 

BPM+ Tooling Compatibility (or in compatibility)

Vendor lock in is always a concern. It does not serve the industry well if you can not share artifacts across tooling stacks. Our experiences is that current the tools are about 100% incompatible - the advice from vendor is the target the artifact is to not import but remodel using their tools. The reasons are numerous and some are valid as the standard has been stagnant for some time and no approved extension approach was defined.

If shared artifacts are a real goal - then a set of test and certifications for import/export need to be defined and executed.

 

BPM+ and CDS Hooks

One of the more popular extensible frameworks is CDS Hooks which is defined as follows

This specification describes a "hook"-based pattern for invoking decision support from within a clinician's workflow. The API supports:

  • Synchronous, workflow-triggered CDS calls returning information and suggestions

  • Launching a user-facing SMART app when CDS requires additional interaction

The structure of the hook is not compatible with asynchronous/background applications but the same decisions would be beneficial to asynchronous processes.

The responses from CDS hooks have not been standardized limiting plug and play of CDS hook implementations

TODOS

  • Introduce and improve support for CDS hooks in BPM+ and similar environments

  • Standardize and externalize “hook” definitions and semantics

  • Define profiles for cards to support computable execution of results

  • improve data required response

Clinical Pathway Rigor

In attempting to automate several documented clinical pathways/best practices - all we have seen do not have enough rigor to be implemented with out some level projection on meanings and inputs.

For instance the following is an exemplar of a portion of a documented pathway modified to illustrate the issues of lack of rigor

if last A1C was high prescribe recommended starting dose of insulin

In the above

A1C observation - how is that located - what codes Loinc etc should be used

What is considered High - while this might be well known by physicians - implementer will not

What is considered starting does ?

A bit more subtle - what does the prescription look like - what recommendations/instructions/cautions should be included

Interactions between Services

Our experiences is Interactions between Services can result in many issues. One simple example highlights multiple interactions: A task called a decision service that required data in order to execute. Issues arose because the data required by the service was not available in the server which then required input from the point of care healthcare professional. The challenge is to come up with a repeatable design for this pattern, and other patterns, based on standards standard interfaces, semantics, and adaptors.