Ruminations of an IT Business Analyst

Sunday, April 5, 2015

Clinical Practice Guidelines (CPG) are published by healthcare organizations to provide clinicians with recommended standards of high-quality care. Several studies have reported low rates of compliance with CPGs resulting in variations in care, medical errors, and even iatrogenic harm to patients. Clinical Decision Support (CDS) systems are software that translate medical knowledge into computer-executable knowledge in order to improve guideline adherence at the point of care. The sources of medical knowledge include CPGs, predictive analytics models, and other forms of scientific evidence such as findings from Genomics research. CDS systems are not designed to replace clinicians but instead provide cognitive support to clinicians in the form of treatment recommendations personalized for individual patients.

In this post, I discuss requirements elicitation for CDS systems. These systems are technologically complex but also interesting from a business analysis standpoint. I use the case of Colorectal cancer (CRC) because implementing CDS for CRC requires a seamless integration of clinical events, rules, processes, and predictive analytics models. I use the Decision Modeling Notation (DMN) to model the clinical decisions because it was defined exactly for that kind of purpose. First, I try to understand the business problems including prevalence in the population, medical errors in diagnosis, and the cost of medical malpractice claims.

Estimates of CRC Prevalence

In 2008, an estimated 1.24 millions new cases were diagnosed with CRC worldwide [1]. During the same year, an estimated 608,700 deaths were attributed to CRC. According to the Center for Disease Control and Prevention (CDC), CRC is the second leading cause of cancer-related deaths in the United States and the third most common cancer in men and in women [2]. In 2011, there were an estimated 1,162,426 people living with CRC in the United States. Based on 2009-2011 data, approximately 4.7% of men and women will be diagnosed with CRC at some point during their lifetime. In 2014, estimated new cases of CRC were 136,830 in the U.S., with 50,310 deaths [3].

CRC Cases in Medical Malpractice Claims

Misdiagnosis in CRC cases is among the most common type of cancer-related medical malpractice claims in the US. For example, misdiagnosis can occur when a primary care provider fails to comply with existing CRC screening guidelines or fails to order diagnostic testing even when a patient presents with symptoms like rectal bleeding or unexplained anemia.

Genetic Testing

Patients with a family history of CRC are at high-risk. Lynch syndrome (also known as hereditary nonpolyposis colorectal cancer or HNPCC) is a well-defined inherited syndrome and is the most common form of genetic susceptibility to CRC. Germline mutations in DNA mismatch repair (MMR) genes (MLH1, MSH2, MSH6, and PMS2) are detected in up to 70-80% of families with HNPCC [4]. The National Comprehensive Cancer Network (NCCN) provides guidelines for the prevention, detection, and treatment of CRC including genetic testing and counseling for patients with CRC [5].

Predictive Analytics

Current guidelines recommend urgent referral based on symptoms like rectal bleeding or unexplained anemia and factors such as the patient's age and family history. Studies have shown that multivariable predictive analytics model such as the QCancer model developed in the United Kingdom can provide better performance than screening guidelines based on individual symptoms [6]. QCancer (Colorectal) was developed and internally validated on a large cohort of 3.6 million patients in primary care. QCancer returns a risk score for identifying individuals with undiagnosed CRC. This model can be used for risk stratification to provide early screening and prevention to patients at high risk of CRC.

CRC Decision Modeling with the DMN

Using the DMN, clinical decisions are represented as rule tasks within clinical workflows. The latter can be represented as business processes using the Business Process Modeling Notation (BPMN). Care pathways are often represented as treatment algorithms or decision trees in practice guidelines. In the DMN, the decision requirements model itself is represented using a notation called the Decision Requirements Diagram (DRD). The following is a DRD for a CRC decision model (click to enlarge).

The DRD notation provides various constructs for modeling decisions.

These constructs include:

A Decision element denotes a clinical decision such as selecting a treatment option. The three primary treatment options are: surgery, chemotherapy, and radiation. The decision is made based on clinical input data and available clinical knowledge (referred to as Business Knowledge Models in the DMN).

Input data denotes data used as input to the clinical decision. In the case of CRC these data include all the data from the patient's electronic health record (EMR) that are predictor variables for the predictive analytics model as well as those that are required to make a clinical decision based on the treatment algorithms published by CRC guidelines. Examples include symptoms, demographics, body mass index, alcohol and smoking status, family history, genetic testing, and colonoscopy testing results. Note that the EHR should contain all clinical data about the patient. Other input data are shown in the diagram to emphasize specific clinical data need for CRC decision making.

A Business Knowledge Model denotes a function that encapsulates clinical knowledge. This can take the form of a clinical rule, a decision table, or a predictive analytics model such as the QCancer model. An example of clinical rule based on genetic testing would be: If Patient has HNPCC/Lynch Syndrome, then refer to Endoscopist to perform colonoscopy starting at age 20-25.

A Knowledge Source element denotes an authority for a Business Knowledge Model or Decision. In the case of CRC, the NCCN provides guidelines for the screening and treatment of CRC. A decision table has been derived from the treatment guidelines.

Decision logic defines the specific logic used to make decisions in the form of business rules (for example using a business rule management system) or executable analytic models. Decision logic can be modeled using the DMN-defined Friendly Enough Expression Language (FEEL), the predictive model markup language (PMML), or if/then/else logic in any programming language.

Sunday, December 28, 2014

In 2015, enterprises will continue to make significant investments in Analytics and Decision Management capabilities. The Business Analyst will play a key role in the development of software solutions that implement Business Processes, Business Rules, and Predictive Analytics.

The integration of Business Process Modeling and Decision Modeling

The Decision Modeling Notation (DMN) has finally been approved by the Object Management Group (OMG) in December 2014. The DMN will go mainstream in 2015. The DMN will be part of version 3 of the guide to the Business Analysis Body of Knowledge (BABOK Guide) of the International Institute of Business Analysis (IIBA). In addition, the update to the Business Intermediate Level of the OMG Certified Expert in BPM 2 (OCEB 2) certification now includes a module on the DMN.

Real world decision management scenarios typically include the integration of Business Process Modeling and Decision Modeling. An example is the implementation of Clinical Practice Guidelines (CPGs) and Care Pathways in Clinical Decision Support (CDS) systems. An integrated modeling approach ensures the seamless integration of clinical workflows and clinical rules and greater acceptance by clinicians.

Contributing to the Predictive Analytics Process

As companies continue to leverage their data assets to discover new knowledge through Predictive Analytics, the Business Analyst will collaborate closely with Data Scientists to facilitate the Analytics process. Specifically the Business Analyst will be responsible for the following:

Elicit business requirements for the Analytics process.

Analyze existing data sets to help the Data Scientist in understanding the data in the initial data exploration phase.

Serve as a liaison between business stakeholders and Data Scientists.

Analyze and document requirements for the effective integration of Analytics models with business processes, business rules, and business events.

Effectively communicate the results of the Analytics process to business stakeholders.

For example, Predictive Analytics models can be used for risk stratification allowing healthcare providers to determine patients with a high risk of emergency admission to hospital or 30-day readmission. The Business Analyst can work with clinicians to elicit requirements for how to effectively deploy these models within clinical workflows.

Continuous Learning

Business Analysts will continue to expand their knowledge and skills to support their organizations in the face of rapid change in technology and the marketplace. The Cloud, Software as a Service (SaaS), Big Data Analytics, and the Internet of Things are technology trends to watch in 2015.

As Peter Senge wrote in his book titled The Fifth Discipline: The Art and Practice of the The Learning Organization:

The only sustainable competitive advantage is an organization's ability to learn faster than the competition.

Sunday, September 7, 2014

In a Deloitte's 2013 CIO Survey, 42% of CIOs rated business analysis as the top technical skills gap in their organization.

This week, I aced the Certification of Competency in Business Analysis™ (CCBA®) exam of the International Institute of Business Analysis (IIBA). The exam preparation was structured around mastering the six knowledge areas of A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). The current official release of the BABOK® Guide is version 2.0 and contains a detailed description of generally accepted practices in the field of business analysis.

.

Looking forward to version 3 of the BABOK® Guide

I had a chance few months ago to participate in the pubic review of version 3 of the BABOK® Guide. The public review is now closed. Version 3 introduces the Business Analysis Framework (aka Turtle because of the shape of the diagram representing the framework) which describes the relationships between stakeholders, value, contexts, solutions, changes, and needs (see diagram below).

Monday, May 26, 2014

In my previous post titled Modeling Care Pathways with BPMN, I explained the benefits of using BPMN constructs such as events, tasks, gateways, and data objects to model standardized care processes. An example of task in BPMN is the business rule task which can be executed by a business rule engine at run-time. For illustration purposes, I used a treatment algorithm titled Management of substance use disorder, Module C: General Health Care from the VA/DoD Clinical Practice Guideline (CPG) for the treatment of substance use disorders.

In this post, I discussed the Decision Model and Notation (DMN) specification recently published by the Object Management Group (OMG). While the BPMN is designed specifically for modeling business processes, the DMN provides a notation for modeling decision requirements and decision logic.

The DMN specifies the use of Decision Requirements Diagrams (DRG) for representing decision requirements and decision tables for expressing the decision logic.
The latter can be expressed in a language called FEEL (Friendly
Enough Expression Language) which is also specified in the DMN. The
diagram below from the DMN specification (click to enlarge) describes
the relationship between the BPMN and the DMN and the Decision
Requirements and Decision Logic levels of the DMN.

In the substance use disorder treatment algorithm in my previous post, there is a decision node with the question: Are Treatment goals achieved?. This decision node can be modeled in BPMN as a business rule task. We can then use the DMN to model the detailed requirements for the decision logic for determining whether treatment goals have been achieved or not. In mental health treatment, the Clinical Global Impression - Improvement scale (CGI-I) is a validated 7-point scale of health status improvement. According to Wikipedia:

The CGI-I requires the clinician to assess how much the patient's illness has improved or worsened relative to a baseline state at the beginning of the intervention. It is rated as: 1, very much improved; 2, much improved; 3, minimally improved; 4, no change; 5, minimally worse; 6, much worse; or 7, very much worse.

For illustrative purposes, we consider that treatment goals are achieved if the CGI-I at 6 and 12 months from intake is 1, 2, or 3. Ideally, it would be nice to also include patient-reported outcome measures in determining the achievement of treatment goals. These rules can be executed by a production rule engine like Drools.

In addition to production rules, the decision logic can be modeled as a predictive analytics model in Predictive Model Markup Language (PMML) format. As an example, a logistic regression model represented in PMML can predict (based on the analysis of historical clinical data) which treatment options are more likely to lead to outcome improvement given the clinical profile of a specific patient.

The DMN fills an important gap in modeling complex business rules in a standardized way and will be an important tool in the Business Analyst's toolkit. The DMN has been added as a new technique in the public review release of version 3 of the Business Analysis Body of Knowledge (BABOK) of the International Institute of Business Analysis (IIBA).

Saturday, March 8, 2014

The optimization of healthcare delivery can be achieved through the standardization of care pathways and treatment protocols based on the latest scientific evidence. The following are some of the benefits of the standardization of care pathways:

Improvement in patient outcomes in the context of a shift from a fee-for-service to a value-based healthcare delivery model

Reduction in the variability in care quality

Facilitating the dissemination and adoption of evidence-based practice (EBP).

Different formalisms have been proposed over the years for
representing the medical knowledge in clinical guidelines. Examples
include GLIF (Guideline Interchange Format), Asbru, and PROforma. However, these formalisms have been largely confined to academia.

In this post, I discuss the use of the Business Process Modeling Notation (BPMN) for modeling and representing existing Clinical Practice Guidelines (CPGs) and Care Pathways (CPs). Once represented in BPMN, these guidelines can be translated into computer executable guidelines in the form of Clinical Decision Support (CDS).

As an example, let's review the algorithm below titled Management of substance use disorder, Module C: General Health Care which has been extracted from the VA/DoD Clinical Practice Guideline (CPG) for the treatment of substance use disorders.

The advantage of using BPMN is that it is widely used across industries and implemented by several commercial and open source tools. The algorithm above is not represented in BPMN notation. However, it is relatively easy to create a BPMN representation of the same diagram and doing so can actually help elaborate and clarify its use within a specific healthcare organization.

Clinicians often complain that CDS systems are not well integrated with clinical workflows. One benefit of using BPMN for modeling CPGs is that it facilitates the integration of business rules and business processes. As can be seen from the algorithm above, CPGs are typically represented as a network of tasks some of which are decision tasks. For example, in the diagram, there is a decision node with the question: Are Treatment goals achieved?. This decision task can be modeled in BPMN as a business rule task and executed by a business rule engine at run time. There are business process management (BPM) and business rule management systems (BRMS) tools that provide this integration out-of-the box.

At a high level, BPMN represents business processes using events, activities, data objects, gateways, tasks, and grouping elements. Gateways control the splitting and merging of sequence flows in a business process. The different types of gateways include: Parallel gateway, Exclusive gateway, Inclusive gateway, and Complex gateway. Gateways can also be implemented by a business rule engine. Data objects allow interaction with clinical data sources such as as Electronic Medical Record (EMR) systems.

Grouping elements like pools and lanes are used to delineate the responsibilities and roles of individual clinicians or organization in the process. For example, while the algorithm above is for the management of substance use disorder in general (primary) care, there is a note specifying that patients may be offered referral to addiction specialty care at anytime. This separation of roles can be captured with lanes.

In addition to business rule tasks, BPMN also supports abstract tasks, service task, user task, and script tasks. A user task represents a human task and can support the creation of task-oriented user interfaces in CDS systems. A separate specification called the Web Services Human Task (WS-HT) specification provides an application programming interface (API) and a coordination protocol for interacting with human tasks in a service-oriented manner. The state diagram for human tasks below extracted from the WS-HT specification shows the different states of a human task and the transitions between them. The WS-HT also support notifications which can be used for alerts and reminders in clinical decision support.

Sunday, January 5, 2014

Business rules are used to capture complex operational decision logic
typically found in corporate policies, government regulations, and
industry guidelines. For example, in the healthcare industry, clinicians
must adhere to clinical practice guidelines (CPGs) and other
evidence-based care recommendations. Clinical Decision Support (CDS) systems which provide care recommendations to clinicians are usually designed with a business rule engine.

In the area of Big Data,
operational decisions can also be derived from the analysis of
operational data using predictive analytics. In the healthcare domain, the analysis of patients'
clinical data in electronic medical record (EMR) systems can inform clinical decisions as well.

Benefits of Business Rules

The following are some benefits of designing business rules applications:

The business logic of the application can be externalized in the form of declarative business rules. This contrasts with an approach where business rules are embedded in procedural code.

Business Analysts (BA) and Subject Matter Experts (SMEs) can help create, test, and maintain the business rules. Some business rule management systems (BRMS) provide the ability for BAs and SMEs to use tools like a spreadsheet, a domain specific language (DSL), or an intuitive user interface for creating and testing business rules. Examples of BRMS include JBoss Drools and IBM ILOG.

There is often a requirement to integrate business rules and business processes. For example, clinical decision support (CDS) systems based on business rule engines should be well integrated with clinical workflows which are essentially business processes that can be modeled using the business process modeling notation (BPMN). There are different patterns for integrating business rules and business processes. A business process like a clinical workflow has decision points that are implemented by business rules.

The ability to perform simulations and what-if analysis during development.

Business rules enable consistent and repeatable decisions. In the healthcare domain, this can be used to achieve evidence-based care standardization among clinicians.

Business rules allow the organization to improve the quality and speed of operational decisions as determined by metrics like key performance indicators (KPI). In the healthcare domain, this can help meet clinical quality measures and improved patient-centered outcomes.

The effectiveness of the application can improve over time by logging and monitoring the executions of the business rules in an operational environment.

The Agile Business Rule Development (ABRD) methodology

Originally created by IBM and donated to the Eclipse Foundation, the ABRD provides an agile and iterative approach for designing, developing, testing, and deploying business rule applications. The diagram below represents a high level overview of the ABRD process (click to enlarge).

The ABRD process is divided into the following five phases:

Harvesting

Prototyping

Building

Integrating

Governance

A complete description can be found on the ABRD page. The site also contain various tools and templates for using the ABRD. I also found these two books interesting for learning about business rule applications:

Monday, December 23, 2013

The following are examples of patient safety incidents that can occur
when using an electronic medical record (EMR), a Computerized Physician
Order Entry (CPOE), or a clinical decision support (CDS) system:

Incorrect identification of a patient resulting in the administration of the wrong drug.

Incorrect medication dosage due to a miscalculation of body weight resulting from a mix-up of kilograms and pounds.

Missing data or incorrect data entry into a patient's medical record.

Misreading of patient's medical record due to a font size that is too small on a computer screen.

Errors in medication dosing frequency due to a non-intuitive menu.

Incorrect test ordered due to a clinician clicking on the wrong test.

In this first blog post, I suggest a usability driven approach to gathering software functional requirements and designing the user interface of health IT systems. The goals of this approach are the following:

Increased patient safety.

Increased productivity of healthcare staff through a user-friendly, predictable, and intuitive interface backed by scientific research and validation.

Reduced need for staff training due to a consistent look and feel across clinical applications.

The NHS Common User Interface (CUI) Program

Since November 2004, the British National Health Service (NHS) Common User Interface (CUI) Program
in collaboration with Microsoft has been creating standards and guidance in support of the usability of
clinical applications with inputs from user interface design
specialists, usability experts, and hundreds of clinicians with a
diversity of background in using health information technology.

The
program is based on a rigorous development process which includes:
research, design, prototyping, review, usability testing, and patient
safety assessment by clinicians. The NHS CUI standards and guidance have
been tested in production through the NHS Summary Record Application
(SRA) project. The Guidance Catalog covers the following
subjects with high impact on patient safety:

Patient Identification

Consistent Navigation

Accessibility

Abbreviations and Acronyms

Clinical Noting and Terminology

Decision Support

Handover

Information Entry and Display

Medications Management.

Usability in the Design and Development Phase

As a best practice, formal usability testing should be conducted early in the design and development phase as opposed to doing usability
assessments only after the application has already been developed and deployed into a production environment.
In my experience as a Health IT Business Analyst, creating a mockup for
new Health IT software applications is a very efficient way of capturing
functional requirements. Mockups are very useful in helping to communicate the vision of
the Product Owner and can also be very helpful to the other project
stakeholders like end users, testers, and developers. I use Balsamiq to create mockups that comply with CUI guidelines. Usability testing can be performed against these mockups to ensure CUI compliance and also to obtain early feedback from potential users of the system. I perform Usability Testing of the mockups with end users using a proven methodology like the System Usability Scale (SUS).

Twitter Boostrap Components in Support of CUI Guidelines

Twitter Boostrap is a very popular and powerful mobile-first front end development framework that supports the Responsive Web Design (RWD) approach to achieving cross-browser and cross-device capabilities. There are emerging tools that can assist in converting a Balsamiq mockup into Twitter Boostrap Templates. An example of such a tool is Napkee.

Microsoft has published a set of UI controls that implement CUI guidelines using Silverlight, a now defunct front-end framework. Twitter Boostrap on the other hand is based on open web standards and framework like HTML5, CSS3, and JQuery (a JavaScript library) and is supported by a very large community of web developers. The availability of open source Twitter Boostrap UI components that implement health IT usability guidelines could result in significant cost savings and increased patient safety.

Blog Archive

About Me

Business Analyst, Enterprise Architect, and Project Manager with broad experience in all aspects of the software requirements analysis and software development management life cycle. Familiar with Agile and Lean software development methodologies. I was trained as a Computer Network Systems Administrator. I also hold a Certification of Competency in Business Analysis (CCBA) from the International Institute of Business Analysis (IIBA), a Project Management Professional (PMP) certificate from the Project Management Institute (PMI), a Certified Scrum Master (CSM) certificate from the Scrum Alliance, the ITIL V3 Foundation certification, and the TOGAF Enterprise Architect certification.

I am also a Python Programmer.

I have hands-on experience in performing requirements analysis and managing projects for Mobile Health applications, Electronic Health Record (EHR) systems, and Clinical Decision Support (CDS) systems.