Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Can Clinicians Create High-Quality Databases?

377 views

Published on

Published in: Health & Medicine, Technology
  • Be the first to comment

  • Be the first to like this

Can Clinicians Create High-Quality Databases?

  1. 1. RITU KHARE, YUAN AN, IL -YEOL SONG, XIAOHUA HU THE ISCHOOL AT DREXEL DREXEL UNIVERSITY P H I L A D E L P H I A , P A , U S A Can Clinicians Create High-Quality Databases? A Study on A Flexible Electronic Health Record (fEHR) System
  2. 2. Presentation Part 1 2 1. Motivation:  Inflexible Design of Existing HITs 2. Solution 3. Evaluation 4. Conclusion
  3. 3. Motivation 3  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. 4. We propose… 4  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. 5. Presentation Part 2 5 1. Motivation:  Inflexible Design of Existing HITs 2. Solution:  A Flexible Electronic Health Record (fEHR) System 3. Evaluation 4. Conclusion
  6. 6. 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 Interface Tree Generation 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. 7. The flexible EHR System- Example Scenario 7 I want to collect patient’s information, personal and vital signs, etc Database The fEHR System Form Design Interface Tree Generation Database Design Algorithm Clinician 1 2 3
  8. 8. Simple Form Advanced Form 8 1. Form Design Interface Title Category Field Format Subcategory Supporting Text Unit Extended Checkbox Condition Subfield SIMPLE! Features(form patterns) Terminology (intuitive)
  9. 9. 1. Form Design Interface 9 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. 10. 2. Tree Generation 10 Input: Form Output: Form Tree
  11. 11. 3. Database Design Algorithm 11  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
  12. 12. 3. Database Design Algorithm - Examples 12 Example 1 Example 2 Textbox pattern Sibling categories pattern Radiobutton pattern Checkbox pattern Category-subcat. pattern Textbox pattern
  13. 13. Presentation Part 3 13 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. 14. Participants and Tasks User Study Settings  5 nurse professionals.  No knowledge of database  Moderate computer users  Familiar with Paper-based Forms  2 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 14 Usability Evaluation Implementation using: MySQL, JAVA, JSP, JavaScript, HTML, CSS, Lucene Indexing Package, yFiles Package
  15. 15. 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. 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 . 16 Findings 1
  17. 17. Findings 2 17  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. 18. Presentation Part 4 18 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. 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. 19
  20. 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 20 Future Work
  21. 21. A C K N O W L E D G E M E N T S : T O T H E R E V I E W E R S O F I H I 2 0 1 0 R E F E R E N C E S : [ 1 ] T O [ 2 3 ] ( I N F U L L T E X T ) . 21 Thank you

×