Continuing with blogs from Building Business Capability I am self-blogging the session I co-presented with David Herring, who leads the Process Transformation and Decision Management Program at a leading Northern California Healthcare organization, on “Pioneering Decision Services with Decision Modeling”.
David works at a large not-for-profit health plan that does everything from inpatient, to home health, hospitals, hospice, pharmacy, and insurance. 10M+ members, 17,000 doctors and nearly 200,000 total employees. They have been on a decision management journey. Beginning with SOA infrastructure they first added Business Process Management before adding in-context Decision Management to automate decisions. More recently they have begun to focus on predictive analytics, on cognitive services and on event-awareness and event processing. Their messaging bus now handles 2B messages a month and 500 web services are connected, supporting BPM, Decision Management, advanced analytics and performance management.
Decision Management Solutions has been working with them on its adoption of decision management and, in particular, its adoption of decision modeling. Decision Management relies on a clear understanding of the decisions involved and increasingly therefore on decision modeling. Decision modeling supports the whole lifecycle – giving an unambiguous definition at the beginning, scoping and specifying the interfaces of decision services and providing a framework for monitoring and improvement. Decision models with the Decision Model and Notation standard (DMN) clearly express requirements by documenting decisions and sub-decisions, showing a precise structure for the decision-making, showing what information is consumed by the decision (and precisely where it is consumed) and identifying all the sources of knowledge – policies, regulations or expertise – that define the decision-making approach. Decisions in a decision model can also be connected to business processes, to goals and performance metrics, to organizational structures and to enterprise data.
Decision models in DMN have two layers – a decision requirements layer showing the structure and a decision logic layer expressing how each piece of decision-making executes. DMN decision requirements models can also be integrated with the business rules that implement them in a BRMS. The DMN standard is increasingly widely used, has broad industry support and is managed by the Object Management Group, a well established standards body. The standard is intended to “… provide a common notation that is readily understandable by all business users… a standardized bridge for the gap between the business decision design and decision implementation.”
DMN has many use cases
- Human Decision-making such as documenting human decision-making, improving human decision-making with analytics or training human decision-makers
- Requirements for automated Decision-making including business rules discovery and analysis, framing predictive analytics or even dashboard design
- Implementing automated Decision-making by completely specifying business rules, acting as a BRMS front-end or orchestrating complex decisioning technology
One of the projects that applied the approach is The Heart Failure Project. This arose because cardiologists have a need for a system to evaluate patients, using a simple set of conditions, to determine if patient needs to be referred to a heart failure specialist. 
For this project, the methodology applied was:
- Run discovery workshops
These involved actual business owners – heart surgeons and heart transplant specialists – as well as analysts and IT resources. Elicitation techniques were used to describe the specific decisions involved, identify the metrics/KPIs impacted by these decisions and understand where the decisions fit in the overall system and process context. - Model and identify suitable decisions for automation in IBM’s Operational Decision Manager (ODM) BRMS
Decisions were modeled and refined using DMN in DecisionsFirst Modeler. The initial decisions were decomposed to show the more granular and reusable decisions within them as well as the input data and knowledge sources involved. This used a mix of material from the workshops and ongoing Q&A with the experts. - Transform decision models into executable decision tables
Initial decision tables had been sketched in Excel and linked to the model. As the model stabilized these decision tables were “normalized”. These tables were then added to IBM’s ODM and complete logic was specified, taking advantage of the web-based editor in ODM. Each table was linked to a specific decision in the decision model and the two platforms are integrated to make navigation easy. - Deploy decision tables in an ODM Decision Service
A few additional elements, like a Rule Flow, were added to ODM and this allowed the logic in the tables to be deployed as a service that could be called from processes or from a UI such as that used by the Doctors.
At the heart of this approach is iterative business-centric development. An initial high level model with a few decisions and “obvious” input data is developed. In each iteration a part of the model is developed into a more detailed clinical model and a set of decision tables identified for each element of this more detailed model. This allows for a highly iterative and agile approach while ensuring that each new iteration can clearly be put in context and ensuring that reuse is managed across the iterations (because decisions are reused between the diagrams through a shared underlying repository).
One of the key drivers for the project was that this one decision involved many documents. The current approach is to writer a lot of clinical guideline documents. This results in information overload as well as significant regional variation. It can be hard to ensure that the authors of these documents are practicing specialists and the documents are hard to maintain/rarely updated. The decision model combines all the available guidelines and documents into a single model. Each document is identified as a knowledge source and influences some parts of the overall decision-making.
Key benefits of this approach are consistency and consumability. Today all the various guidelines and some additional toolkits are shared through a library. Different regions leverage these to create local implementations reflecting the systems and processes they use. However this is largely cut-and-paste reuse. With the new approach, all the studies and research could be combined into a single decision model. This could then be used to deploy some standard decision services, available on the enterprise infrastructure, to make decisions whenever and wherever needed. Regional implementations could still reflect local systems and processes but could reach out to a shared decision service – ensuring that the clinical guidance was consistently applied.
When working with experts it is often hard to decide what should be automated and what should be left to experts. It is easy to overfit – building a system that does too much or tries to be too precise. In this example there was a key decision that should be made by a medical professional – a four quadrant decision known as the patient’s hemodynamic status. This was required by key decisions in the model. This should not be automated or made more complex as this describes exactly what a physician does. It can’t be generated from stored data nor is there any value in a more granular scale. The decision model allows this to be identified, described and then left outside the automation – but still in the model for clarity and management.
This approach works well for managing automation boundaries. Teams can develop a decision model for the whole decision and then use it to identify the scope of automation. This may leave “master” decisions to be made by people but more often identifies “feeder” decisions that should be left as manual. In fact the model supports automated, automated but overridable and completely manual decisions equally well, allowing the model to be used BEFORE these automation decisions have been made.
Final summary and recommendations:
- Decision Modeling Workshops
- Engage Business Owners
- Reveal Automation Boundaries
- Integrate Multiple Perspectives and Documents
- Decision Modeling
- Supports Iterative Development
- Focuses BRMS Development
- Avoids Overfitting
- Decision Services
- Improve Processes
- Supports SOA Best Practices
You can learn more about the integration between DecisionsFirst Modeler and IBM ODM here and my new book on DMN – Real-World Decision Modeling with DMN – is available
