Centers for Disease Control and Prevention: Case Study

Leveraging Business Rules Techniques for Public Health Projects

Building Business Capability Conference Las Vegas, NV

Thursday, November 5, 4:50 pm

http://www.buildingbusinesscapability.com/agenda/2015_details/2193/

National Center for Immunization & Respiratory Diseases Immunization Information Systems Support Branch

Warren Williams, MPH David Lyalin, PhD

Stuart Myerburg, JD Eric Larson

Objectives •  Illustrate benefits of business rules for various types of

Public Health projects and project team members. •  Attendees will learn:

–  How business rules can benefit typical project team roles: manager, business analyst, and IT developer.

–  How business rules can be used in different types of public health projects to document institutional knowledge and policies and to develop decision-making logic.

–  Specific examples of applying business rules in a complex, decentralized community environment.

2

Presentation Outline •  Business rules in public health projects (MIROW and

CDSi projects overview) 10 min –  Warren

•  Project A: MIROW project 20 min –  David –  Business rules from perspectives of Business Analyst,

Project Manager, and IT Developer roles •  Project B: CDSi project 20 min

–  Stuart and Eric –  Business rules from perspectives of Business Analyst,

Project Manager, and IT Developer roles •  Q & A 10 min

3

Part 1: Business rules in public health projects

What is Public Health?

“Public health is the science of protecting and improving the health of families and communities through promotion of healthy lifestyles, research for disease and injury prevention and detection and control of infectious diseases.” CDC Foundation

5

The Centers for Disease Control and Prevention (CDC)

q  CDC is a federal agency of the U.S. Department of Health and Human Services

q  For over 60 years CDC has been dedicated to protecting health and promoting quality of life through the prevention and control of disease, injury, and disability.

q  CDC Mission: Collaborating to create the expertise, information, and tools that people and communities need to protect their health – through health promotion, prevention of disease, injury and disability, and preparedness for new health threats.

6

Immunization Information Systems (IIS)

q  Immunization information systems consolidate vaccination records for persons with multiple health care providers, support clinical decision making, generate reminder/recall notices, produce official vaccination records, and provide practice- and population-based vaccination coverage assessments.

q  Immunization information systems are independently run and operated within immunization programs of many U.S. jurisdictions/states

7

How we use business rules •  Used BRs since 1999, before it became a popular

technique •  Applied to various projects, first in cancer registration

and, since 2005 - in immunization registration area •  Developed nine best practices guides for various areas

of IIS operations; recommendations have been expressed with business rules

•  Developed clinical decision support guidelines for vaccination forecasting, i.e., assisting physicians to determine which vaccines a patient need based on immunization history and ACIP recommendations

8

Operational Best Practices Documented with Business Rules

9

Complete Guide – 100+ pages Mini-guide (brochure) – 4 to 8 pages

Best  prac*ces  documents  available  for  download  at: AIRA web site: http://www.immregistries.org/resources/aira-mirow CDC web site: http://www.cdc.gov/vaccines/programs/iis/activities/mirow.html

Clinical Decision Support Documented with Business Rules

q  More commonly referred to as vaccine forecasting and evaluation services by the immunization community.

q  Performed by many different computer systems: §  Electronic Health Record Systems (EHRs) §  Immunization Information Systems (IIS) §  Stand-alone applications – Web-based schedulers, smart phone

apps, etc.

q  In simplest terms, determines if a vaccine was administered correctly and recommends when the next dose is due.

10

Part 2: Project A - MIROW project: Operational Best Practices

Business rules from perspectives of Business Analyst, Project Manager, and IT Developer roles

David Lyalin, PhD

Business rules is a key analysis tool, but just one of the instruments in the “tool box” for a systematic analysis of operations, and processes.

Public HealthProgram

Syst

emat

ic A

naly

sis

Consensus Building

Facilitated Collaboration

Model of Operations and

Processes

Who?(People, Systems,

Organizations)

How?(Activities,

Rules) Where?(Locations)

When?(Time)

What?(Concepts,

Terms, Facts)

Why?(Goals)

reflected in includes

DecisionProcessEventDomain

Model types

12

Business Analyst’s Perspective •  “… demonstrates the ability and inclination to tolerate

chaos, ambiguity, and lack of knowledge and to function effectively in spite of them" –  Position description for Senior Analyst/Designer at a major software

company –  This quotation has been contributed by Steve Farrell, Advanced

Strategies, Inc. •  Addressing Complexity: Business rules give Business

Analysts a powerful analysis instrument that separates decision logic from process consideration, making analysis of various components easier.

•  Addressing Chaos: Additional benefits can be gained by using a hierarchical organization of business rules: High-level principles at the top that provide guidance for development of specific business rules.

13

Separation of Business Rules from Processes

q  Separation of process concerns from decision-making is a fundamental principle of business re-engineering

q  It allows for a public health knowledge to be documented and managed by public health people, not IT people

q  It also results in streamlined processes that are easier to implement (code) and maintain – “thin” processes

q  Without such separation, institutional knowledge ends up hidden in the software code

14

Imm

uniz

atio

n tr

acki

ng e

xam

ple

q  See http://www.cdc.gov/vaccines/programs/iis/interop-proj/downloads/logic-spec-acip-rec.pdf for the CDSi rules

q  See http://www.immregistries.org/AIRA-MIROW_IIS-VFC_Best_Practice_Guide_04-14-2011.pdf for the eligibility rules 15

Business Rules for a State/Event diagram Patient Active/Inactive Status

16

Inactive

Inactive - MOGE

Inactive - Lost to follow-up

Inactive - Unspecified

Inactive - Permanently

Inactive - MOGE

Inactive - Lost to follow-up

Inactive - Unspecified

Inactive - Permanently

Start

UnknownActive BR10

BR10

BR10

BR11

BR15

BR12

BR15 BR15 BR15

BR17 BR17

BR17 BR14

BR15

BR13 BR10

BR13 BR10

BR14 BR36 BR16

Start

Active Unknown

Inactive

Inactive - Lost to follow-up

Inactive - MOGE

Inactive - Permanently

Inactive - Lost to follow-up

Inactive - MOGE

Inactive - Permanently

BR25 BR26

BR22 BR23

BR15 BR15 BR15 BR15

BR25 BR25

BR27

BR27 BR27 BR14

BR24

Provider level Geographic Jurisdiction level

Note: MOGE = Moved or Gone Elsewhere

Hierarchical Organization of rules Book “Business Rules Concepts” and other works by R. Ross and G. Lam  

Our custom of using Business Rules for operational best practices for immunization programs  

La

w/P

olic

y

Leve

l

Governing rules – laws, acts, statutes, regulations, contracts, legal determinations, and so on.

A principle (P) is the high level of institutional knowledge at the operational level. It is a high-level direction that helps to guide the development of the more specific business rules. Principles provide a link between Governing rules and Practicable rules.

Bus

ines

s/O

pera

tiona

l

Le

vel

Practicable Business Rules - interpretations of governing rules.

Business rules (BR) represent specific guidance and decision-making logic for various aspects of IIS operations and processes

17

Principles are the most important part of the Business Rule model

•  Knowledge of some principles easily compensates the lack of knowledge of many facts. – Claude Helvetius

•  When resources are limited (they are always limited), getting principles (high-level direction) right is more important than perfecting vocabulary and facts model.

18

Principles and Business Rules Hierarchy

Ø  The world of operational knowledge is not flat. Ø  A principle (P) is the high level of institutional knowledge at

the operational level. It is a high-level direction that helps to guide the development of the more specific business rules. ü  For example, completeness principle: The information submitted to

an IIS must contain the minimum/mandatory set of data items in order to be accepted by the IIS.

Ø  Business rules (BR) represent specific requirements and decision-making logic for various aspects of IIS processes. ü  For example: The vaccine lot number must be reported for every

vaccination event.

19

Example: Principle and related business rules

•  Principle: Priority should be given to Recall Notifications for children 0–24 months of age. (Reflects limited resources)

•  BR1: In the event that we can do only one Recall for children 0–24 months of age it should be between 19 and 21 months.

•  BR2: In the event that we can do two Recalls for children 0–24 months of age it should be at 19–21 months and 7 months.

•  BR3: In the event that we can do three Recalls for children 0–24 months of age it should be at 19–21 months, 7 months and 3 months.

20

Manager’s Perspective

•  Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. –  Project Management Institute, PMBOK® Guide, Fifth Edition

•  Business rules give managers a well-organized, logically-structured, and technology-neutral knowledge, process, and requirements-supporting product.

•  Business rules helps a project manager's to manage and balance stakeholder expectations, as well as to play a natural role of a “bridge” between a client and the development team.

•  Business rules provide useful metrics to gauge progress of the implementation team.

21

From Policy to Technology

Policy Operations Technology

Principles, i.e., business strategies, high-level business rules

Detailed business rules

Business rule engines

22

IT Developer’s Perspective

•  Implementers, including IT developers, benefited from well-structured and easy-to-interpret requirements that facilitate robust communication with the public health community.

•  Recommended operational best practices, rigorously expressed with Business Rules, help Immunization Information System vendors to produce uniform solutions for clients in multiple state health departments.

•  Business rules, in concert with use cases, provide a robust and clear basis for developing test cases to validate technical implementations. –  Example follows

23

BR testing via typical and challenging scenarios •  Scenario: Patient moved out of state, but uses in-state

provider organization •  Resolution for patient status:

–  Patient status at the geographic level (state) should be set to “Inactive: Outside jurisdiction”

–  Patient status at the provider organization level should be set to “Active” with that in-state provider organization

•  Consequences: –  Patient should be excluded from the geographic jurisdiction

(state) reminder-recalls and assessments –  Patient should be included in the provider organization reminder-

recalls and assessments

•  Decision guidance: –  Principle P310, Business rules BR413, BR402A and BR402B,

Decision tables DT6 and DT7.

24

Take Home Points •  Business rules give Business Analysts a powerful

analysis instrument to address complexity via separation of decision logic from process consideration, making analysis of various components easier.

•  Additional benefits can be gained by using a hierarchical organization of business rules: High-level principles at the top that provide guidance for development of specific business rules.

•  Principles are the most important part of the business rule model. When resources are limited, getting principles (high-level direction) right is more important than perfecting vocabulary and facts model.

•  Business rules, in concert with use cases, provide a robust and clear basis for developing test cases to validate technical implementations.

25

Part 3: Project B - CDSi project Business rules from perspectives of Business Analyst,

Project Manager, and IT Developer roles

Stuart Myerburg, JD Eric Larson

Project Background

•  The immunization schedule and recommendations are communicated through scientific language by ACIP.

•  Recommendations were interpreted and integrated by

technical and clinical subject matter experts (SMEs) in the immunization community. •  The schedule is complex. •  The schedule changes frequently. •  The language used can be ambiguous.

27

Project Background

•  The schedule has to be integrated into computer systems.

•  These systems are decentralized and do not share a common technology or logic framework: •  Integration occurred mostly independently. •  Implementation was often specific to a given application. •  Translation into technical logic could be time-consuming and

open to interpretation by local SMEs and/or programmers, resulting in variance.

28

Sources of Knowledge

29

Goals of the Project

Bridge the gap between the scientific ACIP recommendations and the people and systems that need to interpret them:

•  Promotes consistent interpretation of ACIP recommendations. •  Helps ensure a patient’s immunization status is current,

accurate, and consistent regardless of where the provider is located in the US.

30

Requirements

•  Diverse audience – Not just IT, but had to be structured sufficiently for software developers

•  Implementation-neutral: •  Designed to work in a wide variety of computer systems using

ACIP logic •  Not dependent on a particular technology

•  Not developing an application as part of the project

31

The Solution

Business Rules

32

Business Rules in CDSi

•  Provided an implementation-neutral solution that was structured enough for developers but understandable by program managers and staff

•  Helped the project team have common goals and language

•  Allowed for a common framework for resource development, making project evolution easier

33

Business Rules in CDSi

100%

88%

94%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Logic Specification (n=11)

Supporting Data (n=17)

Test Cases (n=17)

Of those who have used the CDSi resources, do you plan to use them in the future?

34

A BA and a Developer Walk Into an Office…

•  Known limitations: –  They don’t speak the same language

•  BA: Plain English (e.g.: not quite as structured as a developer would like)

•  Developer: Patterns and more patterns (e.g.: everything seems to be some form of an abstract widget or process model)

•  The problem –  Confusion in communication

•  The challenge –  Develop a common structure both can use and understand

effectively

35

Key Components for CDSi

•  Domain Model and Vocabulary

•  Decisions

•  Business Rules

•  Processes

36

Domain Model and Vocabulary Purpose

•  The purpose is to: –  Document business concepts and their relationships to each

other –  Document agreed-upon terms and definitions for the project –  Facilitate discussions of the terms and definitions among project

participants and provide tools to capture outcomes of these discussions

–  Establish a foundation and a reference source (common vocabulary) for other project materials (e.g.: business rules, decision tables, process models)

•  The purpose is not to: –  Depict storage of information (e.g.: data model or Entity

Relationship Diagram) –  Depict workflow or sequence of steps –  Define a technical specification

37

Domain Model and Vocabulary Example

•  What is a dose? 1. The stuff that’s in the vial. 2. A shot that was administered to a patient. 3. A specific recommendation by ACIP (e.g.: 1st dose of MMR or 3rd

dose of Polio). 4. The amount or volume of vaccine contained in a shot.

A vaccine is a specific instance of the medicine given during a vaccination event. A vaccine dose administered is the record of the vaccination event. A target dose is a specific recommendation of the ACIP.

38

Decisions, Not Processes act AC 2.1.1 ev aluate age dates

ActivityInitial

ReturnAgeStatusand reason

AC 0.1 Get age dates

(from AC 0.0 Activity toolbox)

do we need a max acceptable age date too?

AgeStatus not valid

reason too young

AgeStatus valid

AgeStatus acceptable

reason acceptable age

AgeStatus not valid

reason too old

[otherwise]

[vaccination date >=min valid age date]

[otherwise][vaccination date >=min acceptable agedate]

[vaccination date <max valid age date]

[otherwise]

Condi&on   Age  Status   Reason  vaccina*on  date  <  absolute  minimum  age  date   Not  Valid   Too  Young  absolute  minimum  age  date  <=  vaccina*on  date  <  minimum  age  date   Valid   Grace  Period  minimum  age  date  <=  vaccina*on  date  <  maximum  age  date   Valid      vaccina*on  date  >  max  valid  age  date   Extraneous   Too  Old  

•  Process Model & Decision Table yield same result

•  Process Model has several limitations •  Does not resonate with a BA •  It is difficult and costly to maintain •  It is very syntax heavy given limited space for

terms based in vocabulary

•  Decision Table has several advantages •  Easy for anyone to read and engage •  Easy to maintain •  Room for terms based in vocabulary •  Supported by BRM Tooling

39

Business Rules

•  CDSi Uses SBVR –  provides necessary structure for BA’s and developers alike –  Can be validated/measured/improved with BRM tooling

•  Used in CDSi for rules where decisions tables wouldn’t be useful •  Can be grouped together into Rule Groups

40

Processes are still necessary

•  Process becomes a way to link decisions and/or rule groups •  Short, direct, and simple •  “Thin” process models are consumable by all

41

Take home points: Main benefits of adapting business rules

•  Business analysts gain a powerful analysis instrument that separates decision logic from process consideration, making analysis of various components easier.

•  Managers get a well-organized, logically-structured, and technology-neutral process and product.

•  Implementers, including IT developers, benefit from well-structured and easy-to-interpret requirements that facilitate robust communication with the public health community

•  Contributing to better operational manuals and guides. •  Advancing understanding and synergy between public health

and IT professionals.

42

For more information please contact Centers for Disease Control and Prevention 1600 Clifton Road NE, Atlanta, GA 30333 Telephone: 1-800-CDC-INFO (232-4636)/TTY: 1-888-232-6348 E-mail: cdcinfo@cdc.gov Web: http://www.cdc.gov The findings and conclusions in this report are those of the authors and do not necessarily represent the official position of the Centers for Disease Control and Prevention.

National Center for Immunization & Respiratory Diseases Immunization Information Systems Support Branch

Contact Information: Warren Williams, wxw4@cdc.gov, 404.639.8867

David Lyalin, dil8@cdc.gov, 404.718.4594 Stuart Myerburg, jyz0@cdc.gov, 404.639.1813

Eric Larson, vev5@cdc.gov, 608.385.8535

Questions?