RITU KHARE, YUAN AN, IL-YEOL SONG, XIAOHUA HU

THE ISCHOOL AT DREXELDREXEL UNIVERSITY

P H I L A D E L P H I A , PA , U S A

Can Clinicians Create High-Quality Databases? A Study on

A Flexible Electronic Health Record (fEHR) System

2

Presentation Part 1

1. Motivation: Inflexible Design of Existing HITs

2. Solution3. Evaluation4. Conclusion

3

Motivation

Clinicians rely on health information technologies (HIT) in clinical data collection related to patients, diseases, treatments, etc.

Current HITs are vendor or IT professional designed systems inconsistent

with the data collection needs of the clinicians (Gurses et al. ,2009).

inflexible in that it is either impossible or time-consuming to evolve them

according to clinicians' current and changing needs (Gurses et al. 2009, An et

al. 2009). unintended consequences (Ash et al. 2004)

creation of more work for the clinicians (Lee 2007) – inefficient workflow HIT failures (Harrison et al. 2007).

4

We propose…

A flexible design of HITs that would allow the clinicians to easily and quickly modify the system based on their needs (Gurses et al. ,2009).

Focusing on a specific implementation of HIT, the electronic health record(EHR) (Linder et al. 2007,

DesRoches et al. 2008), we propose a flexible EHR (fEHR) system to enable the clinicians to modify and extend the

underlying database based on their data collection needs

While ensuring that the extended database retains high-quality.

5

Presentation Part 2

1. Motivation: Inflexible Design of Existing HITs

2. Solution: A Flexible Electronic Health Record (fEHR) System

3. Evaluation 4. Conclusion

Form-based approach 3 components

clinicians' high familiarity quotient on forms

rich information embedded in forms to guide DB design.

6

The fEHR system

The fEHR System

Form Design Interfac

e

Tree Generatio

n

Database Design

Algorithm

1 2 3

Enables clinicians to build forms

Generates a tree structure

corresponding to the form

Designs database based on the tree

semantics

6

7

The flexible EHR System- Example Scenario

I want to collect patient’s information, personal and vital signs, etc

Database

The fEHR System

Form Design Interfac

e

Tree Generatio

n

Database Design

Algorithm

Clinician

1 2 3

8

Simple Form Advanced Form

1. Form Design Interface

Title

Category

Field

Format

Subcategory

Supporting Text

Unit

Extended Checkbox

Condition

Subfield

SIMPLE!Features(form

patterns) Terminology

(intuitive)

9

1. Form Design Interface

Input: User actions (based on

data collection needs)

Output: Form

1. Enter the Title “Patient Encounter Form”

2. Enter the category “Patient”

3. Enter the field “Name”

4. Pick a format “textbox”

5. Enter the field “Age”

6. …

10

2. Tree GenerationInput: Form

Output: Form Tree

11

3. Database Design Algorithm

Goal: High-quality database (normalization) Traverses the form tree in depth first order

Input: Form Tree

Output: Database

Textbox Pattern Radiobutton Pattern Checkbox Pattern

Category/subcategory Pattern

Sibling categories Pattern

We consider 5 more patterns (not presented here)

mj.ID -> mj.m

M:1

123. Database Design Algorithm - Examples

Example 1

Example 2

Textbox pattern

Sibling categories pattern

Radiobutton pattern

Checkbox pattern

Category-subcat. pattern

Textbox pattern

13

Presentation Part 3

1. Motivation: Inflexible Design of Existing HITs

2. Solution: A Flexible Electronic Health Record (fEHR) System

3. Evaluation: User Study with Health Professionals

4. Conclusion:

14

Participants and Tasks User Study Settings

5 nurse professionals. No knowledge of database Moderate computer users Familiar with Paper-based

Forms2 Tasks

Build task Replicate a paper-based form

on the system Model and build task

Model and build a given need (in natural language) into a form using the system interface.

2 rounds (form scale = no. of steps to design a form) Round 1: Small scale needs

Avg. form scale = 17 Avg. Database Scale

4.2 tables 5.8 non-key attributes 1.8 values 3.2 foreign key references

Round 2: Large scale needs Avg. form scale 47.4 Avg. Database Scale

6.2 tables 13.8 attributes 10.4 values 4.6 foreign key references

Usability EvaluationImplementation using: MySQL, JAVA, JSP, JavaScript, HTML, CSS, Lucene Indexing Package, yFiles Package

15

Measurements

Duration Ratio = Time(in min)/

Form Scale(#of steps to build form)

Assistance Ratio =# of assistances sought/

Form Scale(#of steps to build form)

Outlier: P5: had difficulty in form terminology

(needed more assistance)

Outlier: P3: considered design alternatives

(high duration ratio)

16

Effectiveness Efficiency

In 19/20 cases, participants finished the tasks with 100% effectiveness. Exception: a building

error committed by a participant who skipped a component while building forms.

Duration ranged from 1 to 9 minutes for simple small-scale needs, and 7 to 19 minutes for advanced longer needs. Exception: A participant

who considered several design alternatives .

Findings 1

17

Findings 2

System Adoption Efficiency : consistently improved from round 1 to

round 2. Confidence:

Very confident for specifying small-scale needs for both the tasks.

Improved from round 1 to round 2 for the build task. Did not improve for model-and-build task from round 1

to 2. Understanding: improved greatly in round 2.

They started synthesizing their knowledge of form concepts and domain knowledge to consider different design alternatives.

18

Presentation Part 4

1. Motivation: Inflexible Design of Existing HITs

2. Solution: A Flexible Electronic Health Record (fEHR) System

3. Evaluation: User Study with Health Professionals

4. Conclusion: Contribution and Future Work

19

Contributions

User study with the form design interface Potential to reduce the current problems of HITs, particularly, the

inefficiency faced by clinicians, and the inconsistency between clinician's needs and databases. Participants showed high-performance in terms of effectiveness and

efficiency. Adoptive: helps the clinicians to learn and improve their need modeling

and form building skills. Improvement in participants’ efficiency, confidence, and understanding in

using the system.

Database Design Algorithm Comparable to any vendor or expert designed Healthcare databases.

High-Quality Principles Normalized Database with respect to the clinician's needs Correctness, completeness, & compactness.

20

Immediate Long Term

User Study More Participants Broad section of healthcare

professionals Form Design Interface

Design Recommendation More Form Features

Database Design Algorithm More Patterns Merging Component Scalability Experiments

Form Filling Component Handle Record Conflict Data Recommendation

(domain/range checks) User Study

Tree Generation Handle elsewhere

designed forms

Future Work

21

ACKNOWLEDGEMENTS: TO THE REVIEWERS OF IHI 2010

REFERENCES: [1] TO [23] ( IN FULL TEXT) .

Thank you