I listened to a podcast by Setrag Khoshafian of Pegasystems in which he talked about "Smart Case Management and CRM." It struck me that case management has potential to improve continuity of service, efficiency and reliability in a number of contexts that may not be considered case management.
I like the following definition of case management presented by Singularity in a white paper entitled "Case Management: Combining Knowledge with Process: "
"Case management is the management of long-lived collaborative processes that require co-ordination of knowledge, content, correspondence and resources to achieve a goal or objective. The path of execution cannot be pre-defined. Human judgment is required in determining how to proceed and the state of a case can be affected by external events."
The goal of case management technology is to provide computer support for managing these ad hoc processes. Henk de Man of Cordys provides an extensive review of past approaches to case management modeling in his BP Trends article Case Management: A Review of Modeling Approaches.
In Setrag's discussion of smart case management, he describes using case management to manage a customer support interaction through participation of various organizations that otherwise might each provide their contribution within the scope of their own silo. Case management can provide a unified view of the customer, the problem to be solved and the cumulative knowledge about that problem without each silo starting their analysis from scratch. This also provides some opportunity to personalize the customer relationship as the solution is developed. However, I see a greater opportunity that, I think, goes beyond Setrag's solution.
I see the opportunity for case management to provide continuity and personalization of service for the on-going customer relationship-an on-going case. This is more like a primary physician's patient care that retains a patient history and incorporates knowledge of, not only the patient's current malady, but a complete file of the patient's problems, treatments and responses potentially over years.
This opens up many more possible applications of case management. Look again at the Singularity definition. Isn't this what managers do? The difference is that unlike the common perception of business processes, management processes go on and on. A manager has a collection of documents pertaining to his or her responsibility and the state of the organization, as well as a history of problems solved and initiatives completed-a manager's case file. He or she manages various problems and initiatives to fulfill that responsibility, engaging the participation of others. The focus of the manager's case is the functional capability of the organization. The manager collaborates with others, applies business knowledge and experience, and performs ad hoc planning and decision-making in pursuit of his or her business goals. At the same time, the manager engages other employees and services, applies business policies and regulations, and must respond to various events both external events and those that arise in the operation of the organization.
Couldn't we approach any business responsibility in a similar manner? It seems that this characterizes the job of a quality assurance manager, an information security manager, a vendor relationship manager, a strategic planning facilitator, the chair of a task force and many other on-going business responsibilities involving cross-enterprise collaboration.
The Object Management Group (OMG) has issued a Request for Proposals (RFP) for a Case Management Process Modeling specification. Work on this specification is in the early stages. I don't know if we can address this case-management-for-managers capability, but I think it's worth considering.
In the January 2010 IEEE Computer magazine there is an article Fulfilling the Vision of Autonomic Computing (unfortunately only the abstract is available for free). This articles looks at the progress that's been made since 2001 when IBM published an article on the need to automate computer management.
This new article discusses how in 2001 there were many unfilled jobs in the IT space and that at the rate things were targeted to grow, we'd never keep up and how clearly in 2010 that is not the case. There are many ways that we manage computers. We use virtualization techniques on the small scale today, things that were only done on the largest scales in 2001. It isn't the same autonomic approach that IBM proposed but it was "good enough".
On the other hand, we do have much more power and data that can be applied, and if it can be applied to the computing environment it can be applied to the enterprise as a whole. When we overcome the relatively arbitrary distinction between the business and the IT departments and address the problems from an "and not or" perspective, it is inevitable.
The IEEE article talks about a couple of examples where autonomic techniques are gaining traction:
"The main cost for the operator of a data center is power, thus provisioning of systems to match the workloads and service-level obligations becomes a critical business success factor. Because workload demands change minute by minute, no human operator can provision services with sufficient efficiency"
"Applications like environmental sensing cause the network to meet the real world in ways that preclude direct human management. The viability of environmental sensing - essential for efficient science and policymaking - therefore depends on sensor systems' ability to self-manage in the face of a changing environment"
If you change the first example to "plant floor" instead of "data center" and "enterprise" instead of "network" in the second example, it is equally valid. As we increase our abilities in IT to use these techniques, the real high value return will be to apply them for the enterprise as a whole.
Granted we'll not eat the elephant whole, but I'm sure there will be more autonomous progress for the enterprise in this decade than there was for computing in the last.
The Object Management Group (OMG) has issued a Request for Proposals (RFP) for a Case Management Process Modeling specification. This RFP will require the integration of process models, data models and rules to provide guidance and record the history of processes that adapt as a result of particular circumstances, events and human judgment.
This is the result of efforts I discussed in July under Knowledge-Driven Processes for Healthcare. The RFP refers to these adaptive processes as case management rather than knowledge-driven because case management is a more widely recognized characterization and focuses on the business objective.
Case management processes may be initiated by conventional, prescribed business processes as specified in BPMN (Business Process Modeling and Notation) and they may engage prescribed business processes to perform desired actions. In addition, a case management process model may be refined over time to become more prescribed. Consequently, a case management process model should integrate with BPMN process models, and it should be represented with notation and operational semantics that are consistent with BPMN so that processes can evolve from ad hoc to prescribed as practices become more refined and predictable.
The focus of a case management process is a case. A case is a situation to be managed. It may be related to a person to be helped, a problem to be resolved, a repair to be performed, a solution to be defined, a lawsuit to be resolved, a claim to be settled or a variety of similar situations. In a case management process, the case is represented by a case file containing records that contain data on the history of the case and the current situation.
The case file will be updated by the case management process to record the current situation, new information, decisions and actions performed. However, many case file records are obtained from other sources. Consequently, the content and format of these records will be defined outside the case management process model. From an OMG modeling perspective, these records should be defined in an IMM model (Information Management Metamodel). IMM provides logical data modeling and transformations to different data formats such as object-oriented, hierarchical, relational and XML. It is currently under development. At the same time, case management guidance and constraints will depend on the content of these records, so the fields must be accessible by rules.
The application of rules to define process guidance and constraints is a primary contribution of the case management process modeling specification. The case management process will be refined over time by the addition of rules that make the process more predictable and reliable. Rules will provide guidance by suggesting actions that may be appropriate under current circumstances. Rules will define events of interest—changes of state reflected in the case file, that may result in alerts or initiation of immediate action. Rules will define constraints on actions that could be detrimental such as administration of a medication to an allergic patient. Rules may also define process constraints reflecting policies or regulations.
Rules must be written with reference to the case file data and the related actions. There are several OMG specifications for modeling rules, and it would be undesirable to define yet another rule language for case management. Semantics of Business Vocabulary and Rules (SBVR) models the semantics of business vocabulary and provides expression of rules in a natural-language-like form using a defined vocabulary. Object Constraint Language (OCL) is the constraint language of the Unified Modeling Language (UML). Production Rule Representation (PRR) defines rules for rules engines. Business Process Modeling and Notation (BPMN 2.0) also includes some rule modeling. The RFP requires the reuse of existing rule specifications. It will be up to submitters to determine which is most suitable.
As OMG develops a more complete set of modeling specifications, the compatibility and integration of models has become an increasingly important challenge. The Case Management Process Modeling specification is a good example. Efforts are under way in OMG to define a general approach and supporting technology.
Henk de Man of Cordys and I are preparing a draft RFP for issue by the Object Management Group (OMG) calling for a Knowledge Driven Process Modeling (KDPM) specification. This generalizes the requirements of case management modeling previously discussed as a draft OMG RFP (see Case Management: The Missing Link in BPM). There are many potential applications for knowledge-driven processes. In health care, a knowledge-driven process capability could support more effective management and innovation in treatment of medical conditions resulting in reduced costs and improved patient value.
The long-term remedies for rising health care costs in the US are innovation and economies of scale. In the book, Redefining Healthcare: Creating Value-Based Competition on Results ( Harvard Business School Press, 2006), Michael Porter and Elizabeth Olmsted Teisberg describes the need for specialization focused on treatment of medical conditions, and scale that supports development of expertise and optimization of processes. The focus on medical conditions supports performance measurement and billing based on results rather than procedures. This provides incentives for improvement. The emphasis on scale supports, collaboration and specialization for deeper understanding of the medical conditions, and innovation in treatment approaches. The processes by which medical conditions are treated must evolve from decisions and procedures by experts, to prescribed best practices and automation. Knowledge-driven process automation will support this evolution.
Clayton Christensen, in his book, Innovator’s Prescription: A Disruptive Solution for Health Care (McGraw-Hill, 2009), the propose is that disruptive innovation is essential for the advancement of health care both for reduced cost and improved quality. Disruptive innovation involves a change in the business model. The current emphasis on funding for procedures emphasizes cutting costs of doing the same procedures. It also creates an incentive for doing more procedures. A focus on outcomes and funding for treatment of medical conditions emphasizes quality improvement and business savings from new, more repeatable treatment approaches.
Christensen notes further that significant changes come from a transformation of treatment from “intuitive to precision medicine.” Insights, experiences, and technology should be incorporated into practices over time to reduce the level of skill required and improve cost and quality. Disruptive innovations imply significant changes to provider practices. For example, laboratory costs have been eliminated for routine monitoring of diabetic conditions as a result of technology that enables patients to perform their own blood tests.
In Andrew Corn's blog “Healthcare: Innovation Is Necessary But Not Cheap,” he considers disruptive innovation as proposed by Christensen, but observes that there has been reluctance for investment in new medical technology. He sees some improvement in investment as a result of economic recovery and the low acquisition cost of struggling start ups. However, I think he has missed the point.
Both of the above books describe barriers to change and a failure of competition to drive change. The costs and risks associated with new technology and innovation would be much smaller barriers if it were not so difficult to gain adoption. For example, laboratories do not have incentives to develop or adopt technology that allows patients to do it themselves. However, the cost and outcomes of treatment of diabetes is significantly improved because patients can monitor themselves and adapt to their eating habits. Often regulations or standards of care that are reinforced by clinicians are barriers to improvements. A focus on treatment of medical conditions enables innovation in the specific practices and circumvents in some of the barriers. Business savings and patient value from improved treatment of medical conditions will provide needed incentives for adoption.
This is where knowledge-driven processes fit in. Knowledge-driven processes for treatment of medical conditions will support intuitive medicine with improved tracking and record-keeping while supporting performance measurement and encoding of insights to improve and streamline practices. Specifications of activities can easily be changed to introduce new technology or to provide guidance in the use of certain procedures or medications. More precise processes can be incorporated using conventional business process modeling technology, but processes can still be adjusted to deal with unforeseen circumstances. Both intuitive and precise processes can be interwoven and evolved as improved techniques that are discovered or developed.
The draft RFP for a Knowledge Driven Process Modeling specification will be considered at the OMG meeting in September.
I had an experience that resonated with me personally about some of the elements I've been discussing in this blog. Since scenarios can many times convey information better than just facts and supposition, here goes...
A few months back, I had to have eye surgery to correct a torn retina. Actually it was two procedures, since the first one was not sufficient. Before I had the second MUCH more intrusive repair, they gave me an EKG. The EKG machine recognized a pattern in my heart rhythm that indicated WPW - a type of irregular heart beat and notified the nurse. They delayed my surgery for about one and a half hours until it could be verified by a specialist that there was little risk.
The next day after the surgery, my primary care physician looked at the EKG and said "I don't see it, but let's be safe." So I got an appointment with a cardiologist. After a few weeks and numerous tests, on Friday I got a clear bill of health, "No problems and your fine - for someone your age'" and the usual admonishment to loose some weight, watch your cholesterol and continue to exercise.
I feel much better about the whole thing now, even if my insurance company probably does not.
This all started because an automated agent sitting on the edge of the healthcare industry recognized a pattern that may indicate a problem – a unique situation. Since it was rather important (at least to me), I was able to rally the human resources available to provide their expertise and make a decision about if it was worth addressing. It focused the attention of the humans involved on the situation.
This scenario is an indication of what will happen in business in the near future, as we shift our focus and implement a more model driven business.
By the way my eye is slowly getting better as well.