DATABASES AT THE HUB NOW YOU CAN CREATE THEM YOURSELF! Ann Christine Catlin HUBbub 2013.
Can Clinicians Create High-Quality Databases?
-
Upload
ritu-khare -
Category
Health & Medicine
-
view
303 -
download
0
Transcript of Can Clinicians Create High-Quality Databases?
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