PROBLEM
Each time a medic cares for a patient at the scene, they generate a Patient Care Report (PCR) to provide critical trend data to state and national agencies, known as NEMSIS. Medics and EMS agencies also care passionately about patient outcomes. Documenting the care provided to a patient, then tracking how that patient did over time, becomes critical to providing better care down the road. Due to the large amounts of data to collect, most medics don't document care on-scene; instead, they document after they complete care of a patient
With so much data required for reporting, many agencies submitted incomplete or inaccurate PCRs, creating less accurate trending and outcome information.
SOLUTION
Develop a user-friendly online PCR documentation tool to collect and validate the 27 data set sections of NEMSIS data–which includes 574 mandatory and optional fields–and help the medic document a patient's care on scene.The tool needed to integrate seamlessly between the iOS app used to quickly capture patient vitals and timeline, and the fully functional incident reporting system used to track patient records and bill post-event.
By merging an incident's timeline–the sequence of events a medic goes through on scene, which are fairly consistent–with the NEMSIS data set, it created a logical and intuitive tool for gathering patient information at time of incident that was fully NEMSIS compliant. It helps a medic recall as much about the scene and the patient's care as possible.
Additionally, by using some key factors like patient demographics, disposition, and protocols, we could auto-populate or remove sets of data that weren't required. This reduced the cognitive load on the medic, and left them more capable of recalling more critical patient information.
PROCESS
1. Research data and usage needs; review the types of data the NEMSIS set needed to collect, and evaluate where there were similarities and differences between the reporting needs and the concept of a global patient timeline.
2. Evaluate how a medic proceeds through an incident to understand the mindset of medics document and recall patient care post-incident.
3. Explore content patterns — specifically the major buckets that worked for both a timeline and NEMSIS data collection concept.
4. Outline the current NEMSIS framework, to understand the data's structure; doing this helps visualize larger patterns in the data set, along with smaller patterns in how fields and content can be ordered similarity to create familiarity over time.
5. Draft first round of revised data architecture on a whiteboard to outline proof-of-concept to stakeholders, including development leads and the product owner.
6. Make adjustments and generate high-fidelity diagram to outline detailed concept to a larger group of stakeholders, including the development team, NEMSIS expert, and medical director.
7. Draft user stories and acceptance criteria, and include artifacts for planning session with development team. Work with the QA engineer to outline how it would be tested, documented and internally verified.
ORIGINAL NAVIGATION TREE: Documenting the existing system helped look for patterns and data duplication, and figure out how to consolidate similar bodies of information.
ASSESSING DATA INPUT GROUPS: To avoid duplication in the screens, we looked for hierarchical and relational data types to form the foundation for patterns and modules in the UI. For example, patient demographics were entered in sequential order, and could be interrupted by repeating tasks like collecting vitals, which would have a many to one relationship to events within a patient's record.
UPDATED WORKFLOW: The concept of sequential documentation, and a need to help a medic walk through a medical event timeline led to a workflow process for documenting the patient and scene, with triggers based on timing to collect vitals and assessments at regular intervals.
INTEGRATION INTO PRODUCT: The medical data gathered on scene was integrated into the documentation and billing processes for ambulance companies. If companies gathered information on scene completely and correctly, that information can be transferred to hospitals to provide better continuity of care, along with meeting requirements for insurance payout so ambulance services could be paid.
APP UI: The system had an iOS app that fed data into the full system, and allowed for quick collection of scene snapshot data. Since many locations lacked cell reception, the app had an offline mode so that data could be kept until connectivity was restored.
Back to Top