240 likes | 422 Views
Test Driving: Model Cases and EDIS Evaluation. Chief Medical Information Officer Caritas Christi Health Care System Attending Emergency Physician St. Elizabeth’s Medical Center, Boston Co-chair, Emergency Care Special Interest Group Health Level 7 Immediate Past Chair
E N D
Test Driving: Model Cases and EDIS Evaluation Chief Medical Information Officer Caritas Christi Health Care System Attending Emergency Physician St. Elizabeth’s Medical Center, Boston Co-chair, Emergency Care Special Interest Group Health Level 7 Immediate Past Chair Section of Emergency Medical Informatics American College of Emergency Medicine Todd Rothenhaus, MD FACEP
ED IT Adopters • “Well Tuned” Emergency Department • Disaster Area • Begging HIS to computerize • CPOE Victim • Reluctant Adopter • Homegrown Developer
EDIS Evaluation • Grid/RFP • KLAS Report • Use Case Scenarios • EHR Functionality Requirements and Conformance Criteria (CCHIT) • The EDIS Functional Profile project of HL7
Comprehensive EDIS • Tracking • Physician and Nurse Charting • Order Entry • Results Reporting • Discharge Instructions/Prescriptions • Billing
Tracking v. Charting • D/C Packages • Charting • Tracking • CPOE • Comprehensive EDIS
ED v. IT • Selection process is a collaborative process • ED is better at determining: • How system will integrate with workflow • Impact on efficiency and flow • IT is better at determining: • Vendor health • System design and maintainability • Long term costs • Consider consultancy to help with selection • Listen to each other
Enterprise v. Best of Breed • Single vendor strategy • Core vendor strategy • Integration versus interfaces
Simple No buy in Intuitive user interface Little or no training Flexible Ability to perform tasks out of order Elastic Able to meet demands during all events and occasions codes, traumas, MCIs Invisible Sub-second response No downtime Facilitates good workflow The Perfect EDIS
Misconceptions • Lack of interfaces • Duplicate entry • Lack of customizable views • “Active” Tracking
use case A use case is a technique for capturing functional requirements of systems and systems-of-systems. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems.
Use Cases: Actors An actor is someone or something that interacts with the system Roles in the EDIS should not be equivalent to roles in the ED Triage RN, Primary RN, Physician, Tech, Transport, etc.
loose coupling • Coupling is the dependency between interacting systems. This dependency can be decomposed into real and artificial dependency: • Real dependency is the set of features or services that a system consumes from another system. Real dependency always exists and cannot be reduced. • Artificial dependency is the set of factors that a system has to comply with in order to consume the features or services provided by other systems. Artificial dependency always exists, but it or its cost can be reduced. • Loose coupling describes the configuration in which artificial dependency has been reduced to the minimum.
Impact Analysis • During use cases, consider the time it takes to perform tasks compared to the existing process • Rapid turnover places see most severe impact • People and architecture • How many more staff • How much more space
Use Case #1 • Patient entry Orders sent • A 64 year old trauma patient on six medications and with extensive PMH presents to the ED. He needs plain x-rays, a full body CT, morphine, tetanus, and Ancef. • Preconditions: • Registration takes six minutes • Laboratory labels take 3 minutes after orders are sent
Use Case #2 • Patient “Heads-up” or “Expect” • A 19 year old girl is referred to the ED for evaluation of abdominal pain. The MD takes the call and enters the call-in into the system. The patient presents to triage and does not announce she was a call in. • Preconditions: there are seven patients who have been called in and are en-route to the ED
Use Case #3 • Admission workflow • A 63 year old man is seen for nausea, vomiting and HA. He is triaged, registered, brought back and seen by the MD. Everyone must document the entire encounter. • He is admitted through the EDIS. • He is found to have a positive troponin and his admission is changed to telemetry • Take this chart home with you to show your medical staff…
Use Case #4 • Patient lookup and chart evaluation • A patient’s primary care physician calls the ED looking to find out what happened to a patient seen yesterday. He wants no know what was done and where the patient was admitted
Use Case #5 • An attending physician who has worked with medical students and residents all day wants to finish her charts for the day: read the notes, finish her notes, sign the charts, and send the charts to billing (chart workflow).
Use Case #6 • Discharge Workflow • A Patient with pyelonephritis is discharge to home with instructions, prescriptions for compazine and ciprofloxacin, and follow-up with a primary care physician • The printer jams between prescriptions and the ciprofloxacin needs to be reprinted.
CPOE: Laboratory Workflow • Layer of abstraction between the names of tests ordered and the term used in the lab system
CPOE: Radiology Workflow • Aim for complete electronic transactions • Paperless • Answer as many questions as possible • Provide context to radiology through use of defaults. May need customizations • Negotiate to keep things simple early on
CPOE: Pharmacy Workflow • Ensure that physicians can see if medications are formulary, non-formulary and ED Stock. • Generic and Trade equivalents • RxNorm Clinical Drug in semantic normal form plus total dose. Unit is the physicians way of ordering drugs. What pharmacy wants should be translated by EDIS.
CPOE Tips • Embed quality interventions (JCAHCO, CMS) into order sets. • Intention orders are difficult to employ in CPOE “If the patient did not receive 325mg of aspirin by EMS, then give ASA PO STAT up to total dose of 325mg” • Lock system from multiple ways of doing things.Nursing documentation example from BMC. • Standardize on and train in views that providers will actually use and see. • Training need not be mandatory—especially in EDIS. This may seem a quality issue, but greatly increases efforts required after go-live.