business requirements volume v1piim.newschool.edu/clients/tatrc/csify10/reports/fy10_q3/w81xw… ·...

Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012

Multi-Inclusion, Universal Client Electronic Health Record: Business Requirements Volume Chris Goranson, Jihoon Kang, Marine Koshkakaryan, PIIM, The New School Last Updated: June 14th, 2012

Quarterly Report: March 02, 2012 – June 01, 2012 of 20


Notes

Revision History

Date Notes Author 6/13/12 Document creation and formatting C. Goranson 6/13/12 Report on initial development status C. Goranson 6/14/12 Additional Notes and Summaries

Added C. Goranson

6/15/12 Additional content and format edit J. Kang

Business Requirements v1 of 20


INTRODUCTION

This is the Business Requirements Volume for the Multi-Inclusion, Universal Client

Electronic Health Record. The purpose of this volume is to organize and document findings

of the project; document the mission and objectives of the project with stakeholders; provide

a foundation for the initial usability metrics and design heuristics.

PROJECT STRATEGY We propose the following project strategy, occurring in three initial phases. This project

strategy is based off of feedback received from CDR Park and the larger Essentris team and has

been structured to provide the highest level of support while accommodating the current sprint

format for review, design and development of the Essentris system. We are presently completing

Phase I as noted below, and have begun initial steps of Phase II

PHASE I: BUSINESS REQUIREMENTS AND PREPARATION

Phase I consists of the following:

1) Define the EMR features (components/user activities) to research and redesign. E.g., patient

list, creating/receiving notes, orders, etc.

2) Establish the usability methods and metrics to evaluate the current EMR system

3) Establish the usability testing methods to evaluate the EMR features which PIIM later

delivers

4) Establish design and production methods

5) Complete the business plan consisting of:

a) WBS

b) Gantt Chart

c) Reporting methods (scheduling of iterative review meetings

d) Milestones and delivery dates

II. DEVELOPMENT CYCLE

1) Choose an EMR feature (component/user activity)

Peter has a specific list of features to be redesigned and we choose one at a time.



2) Study the feature

PIIM team will learn about the user’s goal(s), workflow, interface elements (e.g., objects,

actions) and so forth associated with the selected feature.

Dependency: CliniComp/Peter’s ER team should give PIIM access to Essentris ER Module.

3) Usability research

PIIM team will identify the UI elements which hinder or potentially hinder users’ workflow

and productivity. The team will also apply the severity level (e.g., moderate, critical, very

critical) to each element (usability violation), then make recommendations how it should be

improved.

Dependency: PIIM will have to report the findings to stakeholders and get their feedback.

4) Dividing items to redesign

PIIM team will carefully go through all items identified during “3. Usability research,” then

divide into two groups: Low-hanging Fruit (LHF), High-hanging Fruit (HHF)

Low-hanging Fruit (LHF): items that require relatively less development efforts and do not

drastically change the workflow and structure of the current Essentris ER Module

High-hanging Fruit (HHF): items that require more development efforts and may change the

user experience and system structure drastically. Such changes are not necessarily expected to

be implemented by the development (engineering) team for the time being; they can be

implemented in the future.

5) Design Set A — LHF

PIIM team will design the elements from LHF using the usability research and

recommendations. Each element will be documented with detailed design specs. The specs

will be sent to the development (engineering) team.

6) Design Set B — HHF

PIIM team will document these, but these won’t be implemented by the development

(engineering) team during this project period.



7) Implementation (LHF only)

CliniComp/Peter’s team will take the design specs into development.

Dependencies: CliniComp/Peter’s team must handle this process. They can, however, meet with the design

team (PIIM) regularly for additional support.

8) Usability test

Once the implementation (Step 6 above) is complete, PIIM and Peter’s team will take both

models (current feature from the ER Module and new model) for scientific usability testing

(e.g., GOMS, uFurT, etc.)

Dependency: CliniComp/Peter’s team should make the new model available for testing. We also need to

make sure they will do this. When we met Peter in Bethesda last November, he said he could. I remember!

9) Revision of design

Based upon the feedback and new findings from the usability testing (Step 7 above), PIIM

team will refine and revise the design. Updated design specs will be delivered to

CliniComp/Peter’s team.

10) Documentation

With the research, design, testing, refinement/revision above, PIIM will update the

following documents:

i) Detailed GUI Design Volume

ii) Usability Volume



Stakeholder Review

Gathering Requests/ Requirements

User Interface/ User Experience Analysis

Selecting Component

Implementation

Usability Test / Validation

Revision

Design Set A Low-hanging Fruits

Revision

Design Set B High-hanging Fruits

Documentation/ Delivery

Dividing Research Outcomes



III. POTENTIAL EMR FEATURES TO REDESIGN

1. ED Tracking Boards (ED Tracking, Triage Tracking, Tracking Compact, Tracking VS, etc.)

2. Notes (DOD ED Medical Record, Edit and Review modes, usability, template selection)

3. Order Entry (New Order, Standard Order Set, Order States, workflow, data considerations)

4. Flow Sheets (Charted order results and imports, one time orders, continuous orders)

5. Summary Screens

6. Dashboards/Reports

7. Web Links (ED Reports, access to resources, CPOE Transcriptions Dashboard, CHCS

transcriptions)

8. Nuance (Dragon) Integration

9. Patient Banner Redesign

10. Bed Transfer Task Execution Steps

11. Other Items (policies and procedures, training materials, patient aftercare content

capabilities, imaging capabilities, choice lists, Database Items or DBIs)

12. Calculation Based Dosing



APPENDIX A: MEETING NOTES MARCH 30TH, 2012: KICK-OFF MEETING RECAP Following a Skype call with CDR Park, PIIM and the Essentris team, we identified the

following high-level items that should be reviewed. Below is a summary of notes from CDR Park

and PIIM staff:

1. PIIM needs to secure access to Essentris, address training needs

2. Schedule site visit to the ED (NMCSD) and get a sense for how coverage within the

ED works:

a) Spread of coverage

(1) Parameter 1

(a) Weekdays

(b) Weekends

(2) Parameter 2

(a) Days

(b) Nights

(3) Parameter 3

(a) Shift Change

(b) End of Day Reporting

(4) Parameter 4

(a) ED

(b) FT

(c) Coding Environment

(5) Parameter 5: Setting

(a) Community Non Teaching (29 Palms)

(b) Family Practice Teaching MTFs (Travis)

(c) Tertiary Medical Centers (NMCSD, WRNMMC)

3. Review workflows with Sandy, Jeanine and Kathy

a) Review workflows already captured

b) Review methodology used

4. Visit template: based on spread coverage



a) Uses: Anthony, PIIM, NRL, Others

b) Peter to draft

MAY 2-4, 2012: ESSENTRIS ED CLINICAL CONTENT DESIGN On May 2-4, 2012 CliniComp hosted an Esssentris ED Clinical Content Design meeting. A

number of items were covered, including:

1. CPOE Preparations

a. Freq Orders in the ED Environment

b. Freq Groups of Orders

c. Most Common 200 CC’s Orders

d. Most Common 200 Dispositions Orders

2. EssED Road Map

3. Reports / Dashboard

4. CPOE – Orders

a. Review of OrderSets

b. Defining Missing Orders

c. Refining Orders

5. Guest Presentations

a. Dragon Integration

b. PIIM

6. Larger Discussion

In attendance: Michael Crowder (Travis); Sandy Mar (Clinical ED workflow); Jim Neil (CliniComp

since 2007); John Hughes (RN / IT); Chris Strotum; Paul Schirelli; Andrea Swinesuale; Annette

Moore (Ret AF); JF Lancelot; Peter Park

Dr. Park:

Early detection system of sepsis – led to the reduction of mortality – 30% higher.



Presenting high-value information first.

Refining the order sets. Creating and implementing a library mechanism for this. Early detection

algorithm – 5 common data elements pulled within 90 minutes. Septic protocol pathway and alert.

Detected in the ED (antibiotics started) and connect to inpatient to carryout.

Put in place a standard protocol across services and locations. Need system to support it.

Roadmap (Sprint 26 CPOE) – supporting Madigan and Wright-Patterson to the same level as

Balboa – some challenges remain. Still in beta.

CPOE, issuing change orders a big deal. Opportunity to optimize their processes. How can we

refresh in an enterprise setting?

Take MedSearch module and integrate. Rolling out updates to four different groups of regional

hospitals – a graduated release complete with training (methodology).

Region 1: Asia Yokosuka Okinawa Guam Bremerton Oak Harbor.

Region 2: Europe Naples Sigonella Rota Guantamano Bay Jacksonville

Region 3: CONUS West Lemoore 29 Palms Camp Pendleton San Diego

Region 4: CONUS East Bethesda Portsmouth Camp Lejeune Pensacola Beaufort

Every site is refreshed within 6 months of the initial release of the ‘band’, or cycle.

Regions grouped according to anticipated kick-back. Training sites are in CONUS. One release per

year is just as difficult as doing the roll-out across the region. Roll-out cost could be around $6M

per year. Making the argument to stand up a full implementations team. 14 mobile trainers

Lea / Lisa on the innovation side.

* Branding of the various releases of Essentris ED modules (instead of build numbers, use catchy

names, phrases, etc.)

Workflow: Basecamp on-line questions submitted; reviewed during weekly calls; questions moved

into sprints, and sprints are defined into ‘themes’.



* Why isn’t it used at the patient’s bed side? Don’t want to turn back on patients; difficult to extract

information; computer isn’t always on. Workflow at the bedside (CAG card enabled increases

system start-up wait time) – what should the implementation look like? How do we chart against

the orders? Peter wants this integrated into our write-up.

What should the standard kiosk look like? In a room, where should they be configured in the bed?

Not at the feet of the patient, for example. Docking station for tablets? Jaco inspectors want to

clean / inspect the tablets.

Question: Tablet and wireless? CITRIX on android. Dell Streaks 5, 7 (10 inch), some locations no

Steak 5. Essentris usability not tested on tablets.

Could we make the computers a kiosk? Only three programs on the kiosks? What programs should

be on the kiosk (AHLTA, CHCS, Essentris)? We need a configuration guide.

What are DISA guidelines? More TMIA staff

EUD configuration – how do you log in. 20 – 30 minutes to login. Want to look at the kiosk. Card

readers are problematic.

CHCS meant to be a report machine. Does not include write-back functionality. Workflow

involves signing into multiple programs using card readers. Wireless functionality does exist on

devices that include the card reader built in, but will log you out after 10 minutes. Users cannot

place orders from within Essentris; have to log into CHCS to place orders, due to no writeback

functionality. CHCS is from the 70’s continues to devolve. 110K outpatient visits a month.

Essentris can pull information out of CHCS but cannot write it back.

Lab flowsheet to the patient.

* Do we want a concentrated working group on design-related content?

Call-back mechanism. Critical value follow-up mechanism should use notes, reports, or flowsheets?

Follow-up logs with value for urgency level.



Reviewing the charts via Essentris – read only? Example shown is for radiology. Until user clicks

on ‘completed’ – the information is not updated in the system. Staff checks the call log – patient call

back follow-up. Perfect spot for a personal mailbox? Messaging capabilities? Needs some kind of

messaging support – prompts you to come back. STICKY NOTES on the screen – how about on

the application? Clinicians need some way to flag comments. A JACO requirement makes you

document what you receive. Essentris does have a critical values note.

HOW DO WE VISUALIZE THE TRAIL OF THE WORKFLOW?

DHIMS is 10 minutes logoff on Essentris. Some groups set it so the computer won’t time out.

Wright-Patterson has a script that runs in the background that shakes the mouse to keep the screen

active and user logged in.

RFID technology?

Visual representations appear to be more of a table with colored in squares that are representing the

things that need to be addressed.

Travis AFB – built their own bucket and workflow. Do user-generated improvements flow up?

IN the PIT at the ED (just one example): Two monitors set to CORE, two set to TRIAGE in the

ED department. Shows how users are using the interfaces.

Transcoding allergies into Allergy Markers.

MINIMUM ALLERGY: TYPE, NAME AND SYMPTOM FIELDS. This is a medispan

requirement. Melder support of the allergies – so the fields update themselves?

SPEED is essential in the ED – initial first glance can be a first run at allergies, later fleshed out by

the other care providers later (the ones that have the time to review in detail).

Could CHCS autopop the allergies fields? Right now, the CHCS



TMA has slapped Peter’s hands on ICE. Political – something was getting done. Want more

money (rice bowls and money). CIO’s have been difficult as well.

Can assist JF with discussing the changes necessary for EssED (the ergonomic changes).

LOGIC OF THE LIGHT SWITCHES – further discussion with JF and Peter. Can open additional

options based off of selections made à computational logic

PETER: I only care about how long they’ve been in the ED.

Way to launch the PACS from within Essentris, call up the patient via SSN to address “HL7

resulting from PACS to Essentris”. Challenge is to get credit for the radiology diagnosis. Wet read

can go into Essentris, but wouldn’t be fed back into PACS.

Challenge: Different workflows, different systems. Only the final interpretation of the radiology

comes from CHCS (not the wet read). Dr’s still taking notes based on the call on the wet read (note

taking is still a key concern – where do the notes go, and how are they recorded?)

Logic:

99281 – can bill for someone visiting who left before being seen but have been triaged. Avg cost is

$130. But someone could be seen by a nurse, but leaving before triage may not be billable?

Reference document for RADIOLOGY WORKFLOW: see the

Rads%20Over%20Reads,%20Started%20Feb%206%202013.pdf document.

Visual C / C++ on a UNIX DB Backend accessed from Oracle

UNIX / Proprietary DB à Oracle à Visual C / C++

Nurses cannot write a prescription.



PETER: Wiki for sharing and organizing information. One for order sets, etc. SHOULD WE

START A WIKI FOR AN IEHR? What would it look like? How do we manage this knowledge?

Should wikispaces be used? Sounds like it already is being used, but needs to be revisited. Creating

a “best-practices” – could you involve NIST? Simple descriptions of what the modules do, etc.

Could be something that we do as part of our the outreach to the MHS functional community for

expert and end-user feedback.

PIIM has an opportunity to help CliniComp think through what the next generation of these reports

should look like.

Team has to (a) identify the use cases; and (b) the users can generate the reports. On-demand report

generation using Crystal Reports is not feasible. What about a HTML-generated live report? Have

to work within the boundaries of what we have.

SAIC was given 10M to redevelop some CHCS functionality – has not performed well.

CCI reports are HTML web pages that periodically get updated. But the reports are not really

editable or dynamic – these are static pages. Cannot click on the report and go into Essentris. Why

not using something like Fusion Tables, etc? Other sites have developed some innovation. Are

non-transmittable between sites. San Diego is one example. Could that be another place where the

reports wiki would be helpful?

Standardized notes and standard data architecture with standard tags can lead to the standardization

of reports.

Cyclic schedule will be only two times per year – should find out when these cycles will occur.

Perhaps we could coordinate our implementation of usability testing around the same times.

Reports are very simple web links, opens an HTML-generated page. Automation is key to these

reports working correctly.

Clinical tools and Productivity tools – lists of patients who checked in by hour, then day of the

month. Data in the reports is



HOW TO DEAL WITH UNSIGNED ED ORDERS – this can be a big deal as it can lead to a

recoupment of funds. One button signing all orders at the same time.

DATA ANALYTICS ON THE REPORTS IS IMPORTANT. What does the flowsheet look like?

MD field becomes the unique ID?

Orders and order sets.

Global change –

HIGHLIGHT DOCTOR PROVIDER PAGE

REPORT NEEDS:

Animal Bites – reporting form (requirements vary depending on state)

Total Throughput time by provider

Occupational Health Injuries

Triage Times

Times to Rooms

Average wait time per day, per shift

Patients per provider (really looking for a data exploration tool)

Deaths in the ED

Query Names?

Line of Duty Determinations

MVA

Injury Report (& related documentation, command information)

Needle stick

POCT

Recent discharges and arrival report

Nurses annotation

MedRep completed

Asthma surveillance

Sedation Cases – come off notes



Restraint Cases – come off notes

New universal protocol notes

Unplanned Bounce-back report (returns within 72 hours)

Provider-centric reports

Syndromic Surveillance is already captured.

Public Health Depts grab STD reports straight from CHCS. LWAB charts – left without being

seen.

TEMPLATES: Could be something for the wikispaces wiki. They are also sold by TSy and AAEM.

Sounds like a GREAT OS project. Worth looking to see if there are any good OS templates that are

out there. Redesign template creation/selection. Jihoon suggested T1- template (based on chief

complaint), T2 – observation sections,…. Maybe T3 – default state of each field within section.

Personalize and save templates. Offered mock-up.

Within Essentris system, tag seems to be the identifier of the report.

Probably need to figure out how difficult it would be for Essentris engineers to deploy a new skin

on top of existing code. We have to be careful with our assumptions.

Most popular templates:

TRAVIS AFB

Narrative (no template) 96% / Adult URI / (less than 2%)

Balboa – 86% / AV URI / ADULT URI (these are less than 2%)

There’s no way to collapse the text boxes around the narrative. As static fields are selected, and the

changing conditional is highlighted, the narrative is pre-populated by what was selected. From a DB

perspective, the text is just being loaded in based on what’s checked on the screen. STATE

CHANGE OF THE DEPENDENT FIELDS BASED ON WHAT’S SELECTED.

User Interface / quickly as possible, maximum legal trail.

Flag Flag Flag



Need a hierarchical list of findings (kind of like SnoMed, but different). All three specialty leaders

want a quicker way to get stuff inserted.

[]

Multi-Inclusion, Universal Client Electronic Health Record: Business Requirements Volume PIIM, The New School Last Update: June 13th, 2012

©2012 PIIM, THE NEW SCHOOL

Dragon / Nuance demonstration. Might make good interaction with mental health issues (nlp). Are partnered with IBM / Watson stuff. Could this technology behave I WANT THE GUY WHO HATES COMPUTERS How can we integrate the How can we reimagine the EDTR-HLD training – transfer from patients to the destination (within Patient Control). Multiple choices required before anything can be done. Need to refine tabbing structures, etc. Following presentat ion to CliniComp, Int l . Key Modules: Status Board – make more delicious. Optimize easy changes on the settings Order Entry Beds Transfer – too many steps Labs Look at the date on the banner – is it used well? The entire banner needs help. Flowsheets Summary Screen – standard column placement Do we need plotting / graphing / administration tools? Per Dr. Chris Strode approximately 90% of provider workflow is: Select Pt -> E (Note) -> Orders (D) ->Discharge (F)

Internal design suggestion (Marine): 1) A provider centric view to flip through all the notes for a list of my patients.

Skip the steps: selecting and exiting each pt chart and entering into the note section. Notes have access (link) to orders.

2) A view to flip through a list of orders for my current patients same as above but for orders. Provider may enter and/or review results from here.

3) A view where I can go through and discharge patients from my list. JF:

1) Putting lipstick on the pig 2) Making full recommendations on the EssED 3) Identifying and putting out usability fires (like the beds transfer) Status board

[]



Summary screen – the summary screen requests are made by the users and given to their site admins. Site admins make the request to CliniComp Need a good summary screen on the ED environment. Can it be embedded in a workflow? Screen names in the clinical summary need to be revised. There is a sample starting point provided by Peter on basecamp at SumScreen: DOD ED Clinical Summary. Order sets: Many buttons across the top of the interface. Choice lists should be the same across all CPOE – Computer based order entry. Abdominal pain – sets or bundles of orders. Order sets created based on Travis AFB. Goal is to come up with universal sets that can be used across the DoD. Order sets may change across – summary screens are shown that lets the doctor choose the order sets and the course of action. Choice list in Essentris was probably imported from CHCS. Getting a list of diagnostic procedures out of CHCS – get input into ALHTA, CHCS, etc. Users are No mouse-overs on the buttons on top of the order set.

Orders placed in Essentris have to be re-entered into CHCS by the nurse, etc. Discrete, quick-order sets might be popular? Saves chance of entry being wrong? CPOE Checklist:

1. What is being ordered? 2. What is in our order sets? How can we make the sets better (what is missing)? 3. What sets do we need? If you can press the keys on the keyboard, you can automate it with Dragon. DoD flags things that are available at all sites, other ones can be created and stored on a case-by-case basis. Allergy note at the top is only populated if entered in certain fields throughout Essentris / DBI / CHCS. This information will populate the header bar, but if the allergy marker is filled in from one of these fields.

[]



IS THERE SOMETHING THAT DOCUMENTS WHERE THE FIELDS POPULATE FROM? WHICH SYSTEM? Essentris? CHCS? ICE? Can the allergy fields auto populate into other fields? Nurses use buttons E (Note – ‘DoD ED Medical Record’) and B (DoD ED Flowsheet) a lot.

Following is a list of items from the general discussion on Friday that we may want to contribute to (especially 1-4):

1. JF mentioned that they have a 'smart patient list', something similar to provider portal notification functionality (at 90% completion per JF).

2. Signing and routing notes to other users, a mailbox type of functionality/work flow needs to be planned out.

3. A personalized order entry sheet with check-boxes, max 50 orders. Orders from anywhere, the ability to place orders from anywhere in the system, such as notes.

4. Number of steps to save single order vs. order sets is inconsistent; it is causing loss of orders.

5. The system does not have a good role awareness capability. User type based entry points to system.

6. Ability to view previous notes, a preview with DOS and ICD9 to aid in selection. This item may already be in progress.

7. Currently a nurse annotates an order when it has been transcribed into CHCS from Essentris. This annotation indicates the ‘transcribed’ state. An action item was taken to make this state change part of the other order entry status/state.

8. Action item to build a coder summary screen. 9. Action item to build in real time reporting of missing data.

Some low hanging fruit might be found in:

1. Better label and instruction wording in Notes and all over the system. 2. Status Board(s) color scheme.

Chat with Leah at CliniComp after the conference on Friday. She showed me some work that a previous design team did. They no longer have access to these designers. She is working on some new windows/forms that may be added to the system; she was wondering if we can help with that. I said I believe it is within the scope of the project, but I would have to check with you guys. I told her I would get in touch with her to set-up a call to discuss. Go to next SA training.

business requirements volume v1piim.newschool.edu/clients/tatrc/csify10/reports/fy10_q3/w81xw… ·...

Documents