Capturing StudentPatient Encounters Using an e Logbook David

Capturing Student/Patient Encounters Using an e. Logbook David L. Kriegel II, MD; George Nixon, MD; Joseph Hobbs, MD Department of Family Medicine Medical College of Georgia Regents University Augusta

Conflict of Interest The presenters have no conflict of interest to declare.

Objectives Ø Review background and rationale for development of an electronic logbook for clerkship student documentation of patient encounters Ø Share process and experiences encountered in development of electronic logbook Ø Explore future potential of electronic logbook

Background Ø The Family Medicine Clerkship at the Medical College of Georgia, Georgia Regents University Augusta has over 100 faculty involved in the Family Medicine Clerkship Ø 5 Residency sites Ø 1 Federal: Fort Gordon, Georgia Ø 2 Community, unopposed: Albany & Rome, Georgia Ø 1 Community, opposed: Savannah, Georgia Ø 1 University based: main campus, Augusta, Georgia Ø Remainder are distributed in urban, suburban & rural settings with majority being small group practices with no multi-specialty groups and 1 FQHC

What is the problem? Ø Per the LCME Educational Objective ED-8*, “The curriculum of a medical education program must include comparable educational experiences and equivalent methods of assessment across all instructional sites within a given discipline. ” Ø Our Clerkship has a requirement of 120 patient encounters documented in the students logbook Ø Types & frequency of problems or conditions may vary Ø Core experiences must be identified to achieve clerkship objectives Ø Ensure students receive sufficient exposure Ø Additional documentation requirements of the clerkship Ø Observed components of physical exam (i. e. ENT, MSK) Ø Specialty assigned “procedure” documentation (i. e. three fingerstick glucose checks, writing a prescription) *Functions and Structure of a Medical School, LCME, June 2013

New Problems Ø The Medical College of Georgia has mandated 100% documentation of patient encounters across all clerkships effective 2013 -2014 academic year Ø School tracks this data using One 45© Ø Clerkship has several decades of student clinical experience data in Fox. Pro database Ø Final release version of Fox. Pro was 2. 6 a in 1994! Ø How to maintain decades of data in a manner that can be utilized in a comparable manner with current technology?

Problems as we see it… Ø Maintaining fidelity of data from paper logbook without adding additional documentation burden to the student Ø Monitoring of experiences occurs ex post facto Ø Aggregate data from logbook entries to guide curriculum changes Ø ED-8 also directs “course and clerkship…leadership [to] review medical students’ evaluation of their experiences at all instructional sites to identify any persistent variations in education experiences…” Ø Sharing of student clinical experience to geographically dispersed faculty Ø This typically occurs annually at Departmental Faculty Development retreat

Advantages Ø Real time reporting of compliance Ø Reduced data entry? Ø Utilizes integrated voice recognition of platform Ø ~0. 5 FTE utilized for back end data entry currently Ø Use by faculty for student feedback DURING clerkship

Design Ø Web-based application with i. OS shell interface Ø Technical details: Ø Ø Ø Windows Server 2000 running as a virtual server (on Linux server) PHP (markup scripting language for server side operations) HTML 5 for website scripting Javascript for the front end My. SQL database on the back end Ø Security: End-to-end encryption (SSL) Ø PHI de-identified but reduces security risk (e. g. spoofing attack) Ø i. Pad mini form factor & speech-to-text native application Ø Google Voice also used in early testing

Funding & Resources Ø In-house dedicated IT support Ø This project was supported by the Predoctoral Training in Primary Care grant number D 56 HP 23266 from the Health Resources and Services Administration (HRSA)* Ø Cost: Ø Salary support for Information Technology specialist: $27, 377. 28 Ø Supply costs: $3691. 00 Ø Total: ~$32, 000 Ø With development complete could be done for supply costs & server support *The content is solely the responsibility of the authors and does not necessarily represent the official view of HRSA

How does it work? Ø Version 0. 5 Ø Users able to connect & authenticate account on server Ø Forms submitted and tracked by users in a retrievable way Ø Easy retrieval of submitted data in readable format Form Entered Stored in My. SQL Database Daily PDF Generated Read into Legacy Database

Experience to date Ø During alpha testing several crashes on server side due to cookie blocking Ø Suggestions: Ø Form reset button (coded but not yet implemented) Ø “Digital odometer” for age entry ØHow is this recorded (e. g. 9 month old as fraction of a year? ) Ø Feedback: Ø Data entry on back-end was easier (i. e. legible) Ø Voice recognition worked well for entry on front-end

Ø Versions Ø Version 2. 0 Ø Plain text reader with close monitoring Ø Automated checklist Ø Expanded checklist Ø Version 3. 0 Ø Plain text reader fully implemented Ø Enhanced Dashboard with adhoc reporting tools Ø Version 4. 0 Ø Reporting system Ø “Polish” front-end Ø Projects?

Questions?

Acknowledgements Ø Richard Shurling, Education Software Specialist II Ø Denise Hodo, MPH, Research Associate Ø Alison Tammany, MCG Class of 2015 Ø Patrick Hatch, Information Analyst II (AKA Über-tech guy)