Business Intelligence Best Practices: A Strong Foundation ... · Other Categories (18) 42...

1

Business Intelligence Best Practices: A Strong Foundation for Organizational Success

WSB, February 19, 2017

Joseph C Nichols MD, Health Data Consulting

Thomas Harlan, Iatric Systems

2

Speaker IntroductionJoe Nichols, MD - Principal

Health Data Consulting Inc

• >35 years in the healthcare industry

• 15 years in private orthopedic practice

• 18 years healthcare IT

• National speaker, trainer and consultant for CMS, Vendors, Associations, Hospitals, Payers and Professional Practices. Over 200 presentations nationally on health data and coding

• AHIMA approved ICD-10 coding trainer

• Three service awards from WEDI (Workgroup for Electronic Data Interchange)

• Member; board of directors of the University of Washington Health Information Management masters degree program

• Member of the HIMSS Revenue Cycle Task Force

3

Conflict of Interest

Joseph Nichols, MD

Has no real or apparent conflicts of interest to report.

4

Agenda

The changing role of healthcare data and analytics in a value-based purchasing environment

Historical data quality challenges

The challenge of data aggregation

The impact of patient diagnostic data

Re-focusing analytic efforts toward value based purchasing

5

Learning Objectives

Describe the change in healthcare policy and payment focus that is driving new analytic requirements

Explain the current challenges related to data quality

Identify requirements for accurate and consistent data aggregation

Discuss what is needed to prepare the analytic environment to support value based purchasing

7

• US 41st in life expectancy

• Japan 1st in life expectancy

• US infant mortality is approximately 4 times Japan

• 28.5 million uninsured in US

*Source: OECD (Organization for Economic Co-operation and Development) 2015

8

The Public View of Value

Source: Health Data Consulting

9

Increasing Measures of Value


*Source:

10


Information Quality

Observations

Accurate

Complete

Consistent Documentation

Coded Data

Well-defined Standards

Accurate implementation

Robust Concept Support

Aggregation

Clear definition

Normalized

Accurate inclusion and exclusions

Analysis

Well defined

Logically valid

Consistently applied


Source: Health Data Consulting Inc.

11

1. Observation of all objective and subjective facts relevant to the patient condition

2. Documentation of all of the key medical concepts relevant to patient care

3. Coding that includes all of the key medical concepts supported by the coding standard and guidelines

Good Patient DataIt’s all about good patient care…


12

Big DataIs more garbage better?

13

Unstructured DataReally?

14



15

Medical ConceptsExpressing the patient condition in codes


Medical documentation scenario:

A [27 year old] [male] patient is seen in [follow-up] for a [Smith’s fracture] on the [right] that was exposed through an [open wound] with [minimal opening and minimal tissue damage]. The fracture has [not healed after 6 months].

Though not explicitly stated in this scenario certain expressions imply other concepts:

“Smith’s fracture” >> [fracture], [radius], [distal], [dorsal angulation], [extra-articular], [displaced]

“minimal opening and minimal tissue damage” >> [Gustilo classification I]

“not healed after 6 months” >> [nonunion]

16



17

Historical Distribution of ICD-9 Diagnosis Codes3 Years of Data - All claims - All lines of business - 1million Lives

0.0%

10.0%

20.0%

30.0%

40.0%

50.0%

60.0%

70.0%

80.0%

5% next5%

… … … … … … … … … … … … … … … … … …

Total Charges by Code3years - $10 Bill

Charge %


18

Coding SpecificityUnspecified (NOS), Other (NEC) or Symptom/Finding Codes


Code Type Claims Total Charges %Claims %Charges

All Professional Claims 15,352,056 $ 4,030,052,634 100% 100%

‘Unspecified’ (and not ‘Other’ or ‘Symptom

or Finding’)2,902,691 $ 709,765,341 19% 18%

‘Other’ 1,917,163 $ 509,694,935 12% 13%

‘Symptom or Finding’ 3,530,464 $ 675,662,073 23% 17%

Total 'Unspecified', 'Other' and 'Symptom or

Finding'8,350,318 $ 1,895,122,349 54% 47%


19

Coding SpecificityUnspecified (NOS), Other (NEC) or Symptom/Finding Codes


Code Description Total Charges Claims

78900 Abdominal pain, unspecified site $ 29,331,412 123,737

71946 Pain in joint, lower leg $ 22,973,230 96,786

7295 Pain in limb $ 13,668,722 78,505

78605 Shortness of breath $ 12,533,909 43,463

9597 Knee, leg, ankle, and foot injury $ 9,979,457 41,707

7862 Cough $ 9,250,724 77,430

7851 Palpitations $ 8,181,439 28,228

7820 Disturbance of skin sensation $ 6,531,675 18,238

78060 Fever, unspecified $ 5,269,369 32,603

7823 Edema $ 2,772,549 16,450


20

Coding PatternsBreast Cancer


21

Aggregation

The Heart of Policies, Rules Edits and Analytics


22


Information Quality

Observations

Accurate

Complete

Consistent Documentation

Coded Data

Well-defined Standards

Accurate implementation

Robust Concept Support

Aggregation

Clear definition

Normalized

Accurate inclusion and exclusions

Analysis

Well defined

Logically valid

Consistently applied



23

Aggregating Data - ChallengesSame concept in many places:

Condition Tabular Category Number of Codes

Hypertension Hypertensive Disease 14

Other Categories (14) 115

Pneumonia Influenza and Pneumonia 38


Genitourinary Disorders Diseases of the Genitourinary System 587



Current categorization in the ICD-10 tabular index

Because of the ‘combination’ nature of ICD-10 codes, they

may not be located in the category the user is expecting

24

Aggregating Data - ChallengesSame concept described many ways:

25


26


27


28


29


30

Quality measures

Resource use (cost) measures

Adjustments for risk, severity and complexity– Quality measures

– Outcomes, complication, potentially preventable re-admissions

– Efficiency / utilization measures

Current and evolving payment models dependent on conditions and outcomes of care

Diagnosis impacts?


31

Coding Patterns

0.00%

5.00%

10.00%

15.00%

20.00%

25.00%

30.00%

35.00%

40.00%

% of Claims

42731 Atrial fibrillation

7851 Palpitations

42789 Other specified cardiacdysrhythmias

7850 Tachycardia, unspecified

4279 Cardiac dysrhythmia,unspecified

4270 Paroxysmal supraventriculartachycardia

42769 Other premature beats

42781 Sinoatrial node dysfunction

42732 Atrial flutter


32

Coding PatternsDysrhythmias

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

% of Claims

N/A Cardiac dysrhythmia, unspecified

42731 Atrial fibrillation

42781 Sinoatrial node dysfunction

42732 Atrial flutter

4260 Atrioventricular block, complete

42761 Supraventricular premature beats

4267 Anomalous atrioventricular excitation

4264 Right bundle branch block

4263 Other left bundle branch block

42611 First degree atrioventricular block


33 3333

Hospital Payment Impacts


34

Current Distribution of ICD-9 diagnosis codesHistorical Diabetes Coding – 760,556 Claims


35 3535

Hospital Payment Impacts

Health Data Consulting ©

2014


36

Concept Based AnalysisDiabetic Retinopathy



Condition Parameter Per person charges* Ratio to Average**

Diabetes $35,341 2.90

Diabetes + Retinopathy $69,424 5.69

Diabetes + Retinopathy + Proliferative $118,654 9.73

* Average total of all claim charges for a person with any claim in this diagnostic category

** Ratio of the average total of all claim charges for a person with any claim in this diagnostic category compared to the average for all persons for all claim charges ($12,200)


37

Concept Based Analysis

3737

CMS-HCCs


MDMeta © 2016Source: Health Data Consulting Inc.Source: Health Data Consulting Inc.

38

Concept Based Analysis

3838

CMS-HCCs


MDMeta © 2016Source: Health Data Consulting Inc.Source: Health Data Consulting Inc.

39


40

It starts at the source and extends to all stakeholders

Establish the value proposition for data gatherers and coders

– Detail– Standards– Profile comparisons– Connection to clinical care– Empower education with incentives

Focus on accurately representing the precise nature, risk, severity and complexity of the patient condition

Education


41

Define data quality measures and reporting

Data Governance– Empowered from the top– Participation of all stakeholders and contributors

Use data quality measures in a continuous quality improvement process

Tie data quality to value across the organization

Data Quality


42

Assure the right resources are established:– Clinical experts– Financial experts– Coding experts– Data experts– Technical experts– Compliance experts

Clearly define the intended content of all categories of analysis

Aggregation Quality


43

Define the clinical concepts that meet the definition of the category

– What concepts should be included or excluded based on the definition?

Define the code set that:– Includes all codes that should be included– Excludes all codes that should be excluded

QA and share

Ongoing QA, and monitoring in production

Update as standards change and QA requires

Aggregation Quality


44

Healthcare is changing rapidly to an environment that is “value-based”.

The analytic requirements in this new environment will be more focused on the precise nature of the patient condition.

Data quality and aggregation quality are critical to providing reliable, accurate and actionable information to support this new environment.

Summary


45

Getting there will require a data governance

structure and data contributors that are:

– Educated

– Continuously informed

– Incentivized

– Empowered

– Committed

Summary


46


47

Questions

Contact information:• Joseph Nichols MD• [email protected]• 206-478-8227

Thank you !* Please remember to complete your online session evaluations.

mailto:[email protected]

48

Speaker Introduction

Thomas HarlanTechnical Team Lead — Reporting ServicesIatric Systems, Inc.

>20 years in healthcare IT

Business Intelligence lead in Epic, MEDITECH, Lawson, and Banner

49

Thomas Harlan

Has no real or apparent conflicts of interest to report.

Conflict of Interest

50

• The BI Mental Model – Efficient Delivery of Actionable Data

– Break around 10:15am

• Best Practices for Data Request Triage

• Best Practices for Report Development

– Lunch at 12:30pm

• Best Practices for ETL Development

– Break around 3pm

• Best Practices for Data Quality Lifecycle

• Summary and Closing remarks

Agenda

51

Recognize the importance of having an enterprise BI architecture

Outline the structure of a BI team and the BI life cycle from data request to data delivery

Define BI best practices

Describe how to minimize the cost of maintaining BI

Learning Objectives

52

An architecture for Delivering Actionable Business Intelligence

Based on standard workflow, standard templates and battle-tested best practices

You are doing some, none, or all of the things we will talk about

Use what you will – or not

All improvement is incremental improvement

Welcome!

53

The Old Approach:

“New request = new printed report”

Reports auto-printed to printers

Reports munged into Excel to feed unknown workflows

Thousands of reports to update

Thousands of reports you’re not sure anyone uses…

= Extraordinary waste

Session I – The BI Mental Model

54

What is the User Story > Action?

Requests for data are expanded to workflow

Requests for data have resulting actions defined

Request triage is conducted

Existing tools are used before implementing new ones

Workflows include data quality (DQ) metrics

We waste as little effort as possible

BI Mental Model – The New Approach

55

Every request is documented via the ticketing system

Focus on the action the end user wishes to take

Do not discuss specific technical tools!

Request is refined by the analyst

Specification of data and source

Can it be done?

Should it be done?

What does the user do next?

BI Mental Model – Request Management

56

BI Mental Model – Request Triage

Follow a standard workflow

Match the intended action to the right tool and system

Communicate status consistently

Hold ticket open until the work is completely done

57

Confirm the data is not already available from the identified

system via a standard output tool

Before building new, see if existing tool(s) can be extended

Avoid duplicating data into parallel systems, if you can

When you have confirmed new is needed, follow best practices for

quick development

Pre-validate the new output before the end-user sees it

BI Mental Model – Reuse First

58

Use the tools you have to the fullest

Follow best practice for each output tool

Establish standard work for development

Set a performance metric

Use a version control system

Pre-plan for updates and upgrades

BI Mental Model – Development

59

During specification build, call out any known data issues

Are they being reported by the DQ process?

During validation, watch for missing data / poor capture workflow

Loop in informatics and add to DQ process

Same goes for end-user validation…

DO NOT fix the data issues in the report code!

Keep your end-users out of Excel, if you can

BI Mental Model – Data Quality

60

Plan and communicate an expectation that all BI staff will, in time…

Follow standard work for all development

Be able to use all available tools

Be able to address any request

Be able to meet the performance metric

This means a comprehensive training and role rotation plan.

BI Mental Model – Training Staff

61

How long does it take to be comfortable with a system?

Define your process of turning User Story > Action

Reinforce the use of standard work

Define what tools are in use

Implement training and role rotation

Mentoring

Implement a technical career path

Burgers must be flipped, but there must also be new cheese

BI Mental Model – Retaining Staff

62

BI Mental Model – Discussion

63

Be back in 15 minutes

Break!

64

Best Practice – Data Request Management

Starting from a ticket, we:

Define the User Story

Refine the data specification

Triage the request to available tools

Develop (if necessary):

- New coding

- Valid cycle

Closeout

65

Define the User Story

Who is the user, and what workflow are they trying to improve?

What data do they need to act upon?

How does that data need to be presented?

Which system should it come from?

What actions are they going to take, based on that data?

What are the next steps, beyond initial actions?

How do we identify data quality issues?


66

Refine the Data Specification

Even reports have a data specification… but it is essential for extracts

Use a standard template to document the spec

Let the template do some of your work for you

Encourage the requestor to define the specification

Store the filled-in template with the code, in version control

Send the specification to development, with the ticket or task


67

Triage the request to available tools

Once the specification is set (which may be quite simple)…

Is there a tool (report or extract or dashboard or…) which will provide

the user with the data they need to act?

If there is, note this in the ticket and re-route to the user.

If not…

Use the appropriate system triage map to determine what tool to

develop in (see next slide):


68


69

Develop (if necessary): New Coding

Assign a Data Request Number (DRN) to the new development

Define or modify a version control project to include your new code

Leverage existing code where possible – infrastructure objects!

Build in a consistent way, using the best practice templates

Update your ticket or task to reference the setup

For extracts, a wiki or knowledge-base article is critical


70

Develop (if necessary): Validation Cycle

Never send data via a tool to a user, unless it has been pre-validated

If an analyst has done the specification prep, they hand off to the developer

The developer works directly with the end-user on:

Validating the data

Identifying data quality scenarios


71


72

Closeout

Check code into version control

Publish the report, or schedule the extract

Update the Data Request Number in tracking

Update the ticket or task

Have the beverage of your choice!

All of this is standard work for your BI team. Checklist it, and

do it every time.


73


Discussion

74

Be back in 15 minutes

Break!

75

Foundation Concepts

Correct data … Fast to run

Correct data … Well presented

Correct data … Easy to maintain

Best Practice – Report Development

76

Reporting Architecture

Drive reports from stored procedures

Deploy reports via the web

Work to a performance metric

Parameterize with data-driven lists

Establish and match a site style guide


77

Component Naming

Reports will be composed of at least two components (query and layout)

Use your Data Request Number (DRN) in the name of each component

Include the DRN on the report layout as well

Remember you have Infrastructure Numbers for common objects


78


Server Environment

DATASERVER

Production data repository database

RPTSERVER

Web server providing viewable / scheduled reports

FILESERVER

Offline copy of all report components

79

Report Deployment

On the RPTSERVER, take care to arrange your reports into a clean folder structure and…

Only assign access permissions by groups at the folder level

Report server groups should link to AD groups

Where possible, use short-cuts or linked reports from a hidden

“main” folder


80

When picking the right reporting tool, we need to consider:

What latency is suitable for our end-user using the report?

Where does the report need to be visible?

Is the data reportable?

Do we need to click-through to the chart or account?

Does the output need to be scheduled?

Do we have to go back quarters or years for data?

Report Development – Tool Selection

81

Report Development – Tool Selection

82

Developing in TEST is almost always a waste of time

…Unless the build you’re reporting against is only in TEST

Use a DEV instance instead

DEV has many advantages

Report Development – Live vs. Test

83

1. Create (or re-use) a stored procedure, from a standard template

2. Stored procedure is always parameterized

3. Parameters are driven by re-usable stored procedures

4. Code header is in standard format

5. Output is validated before report layout build

6. For a new report layout, start from a standard template

Report Development – Step by Step

84

7. Format the report attractively

8. Use dynamic features wisely

9. Publish report to \TEST folder for end-user validation

10.Once validated, move to \LIVE folder for general use

Report Development – Step by Step

85

Lookup lists should be driven by stored procedures as well.

Do not embed code in the reports

Use an Infrastructure DRN number

Maintain them in version control

When an update comes, you want to easily identify and manage

changes to lists used by hundreds or thousands of reports.

Report Development – Lookup Lists

86

In every stored procedure you build, be mindful of the future.

Start from a template

Parameterize for facility, start date, end date, department(s) and so on

Template code can process parameters

Comment out what you don’t need

Report Development – Core Query Setup

87

In every report layout you design, be mindful of the future.

Start from a template

Include a URL driven logo

Parameters are data-driven and provided by the template

Standard header, footer, fonts and colors – style sheet!

Report Development – Common Layout

88

Meet your performance metric!

Don’t use DISTINCT in the report

Avoid sub-reports processed per row

Don’t filter data in the report

Split the data-processing into the stored procedure, save the report

layout for formatting and interactive layout.

Report Development – Common Problems

89

Use an enterprise-wide style sheet for data output

Output must be attractively presented, or it may be wasted

Assume your report will be printed, and presented to the Board

Report Development – Layout Appearance

90

Codes are lovely, but most of the time they’re not easy to understand

Name [ Mnemonic ]

Report Development – Mnemonic Display

91

Identifying a patient properly is key to almost every clinical workflow:

This is not enough:

Doe, John [ 00456 ]

This is best:

Name [ MRN ] (Gender/Age) AccountNumber

Report Development – Positive Patient ID

92

Report Development – Discussion

93

LUNCH!

Be back at 1:30PM

94

SQL Server Integration Services

Correct Data… Automated

Correct Data… Monitored

Correct Data… Reported

Follow the BI Mental Model to define the User Story data specification

before coding!

Best Practice ETL – Overview

95

1. Automate and schedule entire process

2. Provide run-on-demand

3. Set alerts for failure

4. Data Flow tasks driven by stored procedures

5. New db objects stored in a custom catalog

6. Stored procedures are parameterized

7. EXEC command generated by a control variable

Best Practice ETL – Common Components

96

8. Package sends files securely

9. Tab-delimited files are preferred

10.Meet the performance metric!

11.Notify the customer of work done

Best Practice ETL – Common Components

97

Three Servers?

Data Repository database server

SQL Agent with Integration Services

Off-line copy of extract code

Three File Storage Locations:

Production location of scheduled jobs

Offline copy of projects and documentation

Output files to send, and archive of sent files

Best Practice ETL – SSIS Environment

98

Track ETL requests with a Data Request Number.

Use the DRN as a common identifier:

C0200-PressGaney.sln

C0200-PressGaney.dtsx

C0200-PressGaney-SP.sql

Best Practice ETL – Data Request Tracking

99

Custom Database objects go into:

zcus

Work against:

DEV, if you have it, or LIVE otherwise

Best Practice ETL – LIVE vs. TEST vs. DEV

100

Stored procedure per file format

SP result-set matches column-for-column to the

specification

SP results match file specification for type and

length per column

SP’s collect by date range and facility id

Best Practice ETL – Source Data

101

Best Practice ETL – Discussion

102

One DTSX package

Control variables

Data Flow task per file

End to end automation

Best Practice ETL – Extract Components

103

One DTSX per process

Control variables

Load to staging

Delete matching keys

Insert from staging

Best Practice ETL – Datamart Components

104

One DTSX per process

Global control variables

Load to Staging

Delete Matching Keys

Insert to reporting tables

Best Practice ETL – Loader Components

105

A Bad Scene…

107

Central shared storage of projects:

\\FILESERVER\ETL\Live

Using DRN-prefixed folders:

\\FILESERVER\ETL\Live\C0200-Press-Ganey

Best Practice ETL – Managing Projects

108

Project Standard Structure:

– \Documentation

– \SSIS

– \SQL

– \Utilities

Match to version control project structure.

Best Practice ETL – Managing Projects

109

When creating a new project:

Use a short folder path, with short file names

EncryptSensitiveWithPassword

Don’t work on your drive C:!

Use a template DTSX file

Best Practice ETL – Project Creation

110

Before the first Data Flow task:

Create control variables for the extract path, start/end

dates, facility id(s), database server name, etc.

Create two or three variables per file being generated:

Filename, Query, Rowcount

SSIS 2012 + Package variables can be overridden by

package parameters

Best Practice ETL – Package Control

111

For each database connection:

Set Packet Size

Set Commit Size

Set Batch Size

Best Practice ETL – Configuring Connection(s)

112

For each task:

A meaningful name

Has an OLE/DB source

Captures a row count

Has a destination

Use the control variables!

Best Practice ETL – Working Tasks

113

Generate all file names:

Start from an @cExtractPath variable

Create custom @cFileName(s)

Override the ConnectionString property

Best Practice ETL – File Management

114

Start SSIS stored procedures with:

SET NOCOUNT ON ;

SET ANSI_WARNINGS OFF ;

Add to your template!

Best Practice ETL – SQL Setup

115

#temp tables in stored procedures called by SSIS packages generate an error like:

"Invalid object name '##Payment'.".

Best Practice ETL – Temp Tables

116

You fix this one of two ways:

Pre-SSIS 2012, use a result-set “template” in your code

Post-SSIS 2012, use WITH RESULT SETS clause

Best Practice ETL – Temp Tables

117


118

Users like job notification emails:

File names created, with rowcounts

Folder or destination the file went to

Time spent processing the extract

Best Practice ETL – Job Success Emails

119

On all SQL Agent jobs, configure failure notifications:

Email alert when the job fails

What was the error?

Best Practice ETL – Job Failure Emails

120

In a production environment, there are a lot of job emails!

Use your email rules to sort and re-prioritize the messages:

SUCCESS goes to an \Archive folder

FAILURE promote to High Priority and flag in your inbox

Best Practice ETL – Managing Job Emails

121

With many extracts running each day:

Have them run without contention

Be self-documented

Be easy to manage

Configure job streams, with packages running in sequence.

Best Practice ETL – Scheduling

122

Log job run history to custom table

Use this history table to:

Trigger alerts

Best Practice ETL – Job History Tracking

123

Here is a daily job stream w/ four scheduled jobs:

Schedule Name Step Package Run Time

Daily – 0700 - Multistep 1 M0251-Studer Group Export.dtsx At 0700

2 M0999-Safety Surveillor RX.dtsx

3 M0001-15 Minute Census Snapshot.dtsx

4 M300-EmCare Billing Analysis.dtsx

Best Practice ETL – Scheduling Example

124

SQL Agent Jobs are only listed by name. Make that name useful:

(Recurrence) - (Time Pattern) - (Package Name or "Multistep")

Best Practice ETL – Schedule Names

125

When scheduling jobs in SQL Agent:

Use an SSIS Proxy Account

Use Windows authentication

Run in 64-bit mode

Reuse existing schedules

Best Practice ETL – Schedule Setup

126

Listing of all ETL jobs

With links to documentation

With dependency information

The Job Book lets us recreate the scheduled job

environment if we lose the SSIS server.

Best Practice ETL – The Job Book

127

Is your reporting database recovery model set to

SIMPLE?

If set to FULL, and you are doing large extracts, this

may cause disk space issues.

If this occurs, change recovery to SIMPLE or BULK

LOGGED for the duration of the process.

Best Practice ETL – Transaction Log Growth

128

Data Request Number entry

Extract Wiki/KB Article

FILESERVER ETL Folder

Use SCHEDSERVER Catalog or Pkg Folder

Use SCHEDSERVER Extract and Archive Folder(s)

Update your Job Book

Update the CMDB CI (if you have a CMDB)

Best Practice ETL – Closeout

129


130

Be back in 15 Minutes

BREAK!

131

Work queues

Standard reports

Custom reports

Can you take action directly from the report?

Can you measure DQ progress and attribution?

Best Practice Data Quality - Overview

132

Incorrect data exists in the system

It goes out to a vendor via an ETL file

A vendor error report comes back

Your staff fix the bad data in the vendor system

And… repeat the next month

Best Practice DQ – Common Workflow

133

The Patient Record

Test patients

Visits without assigned facility or service area

Patients who have expired on the visit, but not on

the patient

No MRN

ADT

Too many census records

Best Practice Data Quality – Common Issues

134

Clinic Workflow

Checking out patients

Hospital Billing

CPT Codes from external LAB interface

Recurring visits not attached to recur. accounts

LOS via bed charges vs. admit-discharge days

DRG not populating from grouper interface


135

Hospital Billing, Continued.

State-specific DRG and CPT Codes

Placeholder provider IDs

Account discharged before admitted?

Accounts discharged in the future

Accounts discharged without Discharge Disposition


136

Providers

Provider group data management (membership, phone, address)

Provider records with shared/duplicated DEA or NPI Numbers

Data from Lab System

Collector User ID instead of freetext name

Discrete or component results


137

On some systems …

Reports can click-through to the account / visit if

properly configured

Which is fantastic… but:

No Metrics about DQ errors and resolutions

We don’t know who did what, when or if it

recurred

Best Practice Data Quality – What to do?

138

We want an architecture:

Runs daily

Captures metrics of DQ events

Generates action reports

Batches to data owners via email

Provides area-specific dashboard

End-user Reports include a “bad data” link


139

Identify data owners

Categorize sources of truth as you find them

Identify their top 1 issue

Define DQ workflow, using 1 issue

Deploy DQ report, metrics, etc. for 1 issue

Wait for tickets requesting new DQ items


140

Best Practice Data Quality – Discussion

141

Contact Information

Thomas Harlan

[email protected]

1-978-674-8330 (PST)

Remember to complete your online session evaluations!

Questions:

mailto:[email protected]

Please use blank slide if more space is required for charts, graphs, etc.

To remove background graphics, right click on selected slide,

choose “Format Background” and check “Hide background graphics”.

Remember to delete this slide, if not needed.

Business Intelligence Best Practices: A Strong Foundation ... · Other Categories (18) 42...

Documents

Transcript of Business Intelligence Best Practices: A Strong Foundation ... · Other Categories (18) 42...