Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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 Redhat 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

  • No labels