My Favorite BA Techniques

Business analysis covers a wide range of tasks. In any organization where these tasks are not well understood, sponsors and stakeholders don’t perceive, recognize, accept, and realize all the work that goes into creating a requirements document.

Many techniques are used by business analysts (BAs) during the elicitation process for on-going project. Here is an example: let’s say, as a BA, you are working on a new healthcare software application project. The choice of the best techniques is critical for the following:

• Assessing the goals of the project
• Gathering the requirements
• Making sure the finished product answers customers’ needs and fill any gap on the market
• Creating and delivering a good requirements document to sponsors, stakeholders, and the development team.

The following steps can be followed during the elicitation process:

• Planning the work
• Elicitation of the requirements 
• Analysis of the requirements
• Communication of the elicitation result to sponsors and stakeholders.

The approval of the elicitation results and the prioritization of the requirements can be hard to achieve in organizations that lack a good understanding of the function and role of business analysis.  So based on my experience, the following techniques can help:

• Diagrams (e.g., BPMN, DMN, UML)
• Prototypes (e.g., mockup, wireframe).   

These techniques will help you achieve your elicitation’s goal in most circumstances. They also help  stakeholders, sponsors, and the development team understand how requirement changes will impact the project in the long run.

Eliciting Requirements for Clinical Decision Support (CDS) Systems: A Case Study in Colorectal Cancer Care

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.

References

[1] Jemal A, Bray F, Center MM, et al. Global cancer statistics. CA Cancer J Clin 2011; 61:69.

[2] Center for Disease Control and Prevention. Colorectal Cancer Statistics. http://www.cdc.gov/cancer/colorectal/statistics/. Accessed April 5, 2015.

[3] National Cancer Institute (NCI). SEER Stat Fact Sheets: Colon and Rectum Cancer. http://seer.cancer.gov/statfacts/html/colorect.html. Accessed April 5, 2015.

[4] Peltomaki P. Role of DNA mismatch repair defects in the pathogenesis of human cancer. J Clin Oncol. 2003;21:1174–9.

[5] NCCN Clinical Practice Guidelines in Oncology (NCCN Guidelines®). http://www.nccn.org/professionals/physician_gls/f_guidelines.ass. Accessed April 5, 2015

[6] Collins GS, Altman DG. Identifying patients with undetected colorectal cancer: an independent validation of QCancer (Colorectal) Br J Cancer. 2012;107(2):260–265. doi: 10.1038/bjc.2012.266

Three Priorities for the Business Analyst in 2015

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.

Industry Credentials in Business Analysis

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).

Version 3 includes the following perspectives:

• Agile
• Business Architecture
• Business Process Management
• Business Intelligence.

The CCBA exam based on version 3 of the BABOK® Guide will become available only sometime in 2015. It is an expanded version of version 2 and includes new techniques like the Decision Modeling Notation (DMN). See my previous post titled Modeling Clinical Rules with the Decision Modeling and Notation (DMN) Specification.

Modeling Clinical Rules with the Decision Modeling and Notation (DMN) Specification

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).

Modeling Care Pathways with BPMN

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.

An agile approach to analyzing business rules

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:

• Jérôme Boyer, and Hafedh Mili. Agile business rule development process, architecture, and JRules examples. Springer, Berlin; Heidelberg; New York, 2011.
• Taylor, James. Decision Management Systems: A Practical Guide to Using Business Rules and Predictive Analytics. IBM Press, 2011.