Learn how AngelTrack solves the difficulty of patient-centric reporting for multi-unit / multi-responder situations
Introduction
Three common emergent-response situations create documentation and compliance challenges:
- A first responder makes patient contact, followed by transport in a different unit.
- A BLS responder performs a patient transport with an ALS intercept provided by a different unit.
- A BLS responder makes patient contact, but summons a different transport unit owing to special equipment requirements.
In each of the aforementioned situations, state trauma registries wish to receive two separate reports -- one for each responder.
The challenges of doing that are:
- Synchronization of common data (PMHx, billing, origin and destination) between all responders;
- Collection and separation of per-responder data (arrival times, crew IDs, vehicle data, disposition); and
- Linking of the two reports so that the state back-end can easily understand they are responses to the same incident
The NEMSIS Specification
The NEMSIS specification makes allowance for this situation, via these fields:
- eResponse.03: The unique incident number, to which all units are responding; and
- eResponse.04: A separate identifier for each responding unit.
For example, suppose we send two BLS units to an incident number 12345. One unit's upload might therefore say:
- eResponse.03 = 12345
- eResponse.04 = 12345-Medic2
...and the other unit's upload might say:
- eResponse.03 = 12345
- eResponse.04 = 12345-Medic17
The state's data back-end can therefore see that both responses (Medic2 and Medic17) are for the same incident (12345), with all the obvious benefits of understanding the reports to be two views of the same situation.
The aforementioned are mockups for the purpose of illustration. Actual values for eResponse.04 emitted by AngelTrack look like this:
D4444S1111
...for a response by shift ID 1111 to an incident whose dispatch ID is 4444.
Common Fields Versus Unit-Specific Fields
The various datafields throughout the NEMSIS spec can be divided into two categories:
- Fields that are common to all responders, such as the patient's name and DOB; and
- Fields that pertain to a unit's particular activities, for example its crew composition, its vehicle callsign, its arrival time, and so on.
Each field's categorization is explicated in the field's definition within the NEMSIS spec, however a few fields are ambiguous and thus are left to the PCR application to decide.
A completed NEMSIS XML document for a multi-responder situation can therefore look like this:
/EMSDataSet
/Header
/PatientCareReport
/eResponse
/eResponse.03 = 12345
/eResponse.04 = 12345-Medic2
...other data...
/PatientCareReport
/eResponse
/eResponse.03 = 12345
/eResponse.04 = 12345-Medic17
...other data...
Do you see how the spec allows multiple PatientCareReport nodes? There is one for each response, even though they both pertain to the same incident number.
Traditional Approaches
Before the advent of cloud applications like AngelTrack, crews were stuck with the traditional approaches to charting. Each responding unit had to prepare their own report, but will need data possessed by the other unit.
For example, the transport unit will need to copy a lot of data prepared by the first responder, and then add to it... but then the first responder needs to copy some of the transport unit's data, because only the transport unit knows what happened during the transport, and where the patient was taken, and how it turned out.
The two units would afterward have to copy data back and forth until each one had a report adequately fleshed-out to pass state data validation (aka schematron).
This is especially difficult when transport occurs, because the advent of transport triggers a great many schematron rules, and the first responder's report probably will not have enough data to satisfy those rules -- not until he copies the necessary information from the transport unit.
Copying data back and forth from a traditional PCR application running on separate devices is a big hassle... and some data, like signatures or document scans, is quite tedious to copy across.
Furthermore, both units must sync up their eResponse.03 identifier, so that the state's database can know that the two reports pertain to the same incident.
AngelTrack Multi-Responder Capability
Modern PCR applications like AngelTrack are entirely in the cloud, which allows all responders to simultaneously contribute data to a single unified report. This is called "patient-centric reporting," in contrast to the "unit-centric reporting" of old-fashioned PCR apps.
It does not matter which devices the crews are using, or which kinds of computer, laptop, tablet, or smartphone they prefer; they all access AngelTrack from their web browser and they all jointly create PCR data. Each crew member contributes whatever information he knows, and whatever signatures and documents he collects.
AngelTrack supports an unlimited number of simultaneous responders to a single incident, and an unlimited number of crew members all accessing the PCR at the same time.
Each responding vehicle has certain datafields that pertain only to it:
- /eTimes
- /eCrew
- /eResponse
- /eDisposition
All other PCR data pertains to the patient or to the incident, and thus is common among all responders. For example, there is only ever one patient date-of-birth, no matter how many units respond.
To learn more about AngelTrack's multi-responder capability, please refer to the Multiple Responders Guide.
State Upload of Split Report
When the crews finish charting, and the time comes to upload it, AngelTrack generates a single NEMSIS XML containing one PatientCareReport node for the transport unit plus an additional PatientCareReport node for each responder who has at least first-responder capabilities*.
The combined report looks like this:
/EMSDataSet
/Header
/PatientCareReport (transporting unit)
/eRecord - common data
/eResponse - data unique to this unit
/eDispatch - common data
/eCrew - data unique to this unit
/eTimes - both common and unit-specific data
/ePatient - common data
/ePayment - common data
/eScene - common data
/eSituation - common data
/eInjury - common data
/eArrest - common data
/eHistory - common data
/eNarrative - common data
/eVitals - common data, differentiated by patch number
/eLabs - common data, differentiated by patch number
/eExam - common data
/eProtocols - common data
/eMedications - common data, differentiated by patch number
/eProcedures - common data, differentiated by patch number
/eAirway - common data
/eDevice - common data
/eDisposition - both common and unit-specific data
/eOutcome - common data
/eCustomResults - common data
/eOther - common data
/PatientCareReport (secondary responder)
/eRecord - common data
/eResponse - data unique to this unit
/eDispatch - common data
/eCrew - crew list from this unit
/eTimes - both common and unit-specific data
/ePatient - common data
/ePayment - common data
/eScene - common data
/eSituation - common data
/eInjury - common data
/eArrest - common data
/eHistory - common data
/eNarrative - common data
/eVitals - common data, differentiated by patch number
/eLabs - common data, differentiated by patch number
/eExam - common data
/eProtocols - common data
/eMedications - common data, differentiated by patch number
/eProcedures - common data, differentiated by patch number
/eAirway - common data
/eDevice - common data
/eDisposition - both common and unit-specific data
/eOutcome - common data
/eCustomResults - common data
/eOther - common data
*The phrase "first responder capabilities" means: Any vehicle who has at least one crew member onboard who has at least a "First responder" level patch. Thus a wheelchair van qualifies as a first responder when driven by an EMT, but not when driven by a wheelchair driver. To learn how AngelTrack calculates the service capabilities of shifts, please visit the Service Levels Guide.
On that subject: Responses from wheelchair vans providing lift assist are not included as PatientCareReport nodes, owing to the barriers in passing a wheelchair van response through state schematrons.
The crew members need not take any special actions or effort to assemble this multi-fork report, AngelTrack does it automatically in any emergent BLS+ multi-responder situation.
For these particular NEMSIS nodes in all reports for all responders:
- /eVitals
- /eLabs
- /eExam
- /eMedications
- /eProcedures
- /eAirway
- /eDevice
...AngelTrack sends every action performed by every responding unit, organized by date/time performed and by the patch number of the individual who performed it. This way, each PCR can stand alone, providing a complete and unified picture of patient care with all events in proper time order... even the report from a first responder who did not go aboard for the transport and therefore does not know what happened at the destination.
Furthermore, the /eVitals, /eLabs, /eMedications, and /eProcedures nodes are auto-adjusted so that each record's "Is Performed Before This EMS Unit's Care" datafield reflects the particular unit. For example, a set of vital signs taken by the first responder will have "No" in this field, because the vital signs were taken after the first responder began care, however the exact same set of vital signs will also be included in the transporting unit's chart, but with this field marked "Yes" because the vital signs were taken before the transporting unit began care.
We believe this best balances the three competing goals of EMS charting:
- Conformity to the letter and spirit of the NEMSIS spec;
- Desire of state trauma registries to receive a full and complete record of each response; and
- Requirement to pass schematron validation even for first-responder or ALS-intercept responses whose vehicles are not transport-capable.
If the state trauma registry back-end chooses to unify the two responses under their shared incident ID (in eResponse.03), it will see identical data in both calls for all fields in common, and it will see different data only for unit-specific fields such as callsign and arrival time.
Or, if the back-end does not unify the two responses, then each report can stand lone, containing all data necessary to understand everything done to and for the patient.
Schematron Validation
Your state's data validation rules apply normally to AngelTrack's multi-responder split reports. Likewise the national data validation rules. Under the hood, every schematron rule applies to every responder report (i.e. every node) present in the NEMSIS XML, so you will see rules flagging for one or both or all three responders.
Like regular reports, multi-responder split reports are subject to the four schematron validation points in AngelTrack's workflow, discussed in the State Uploads Guide.
Schematron bugs
Not all schematrons are compatible with reports from secondary responders, because it is difficult for schematron authors to anticipate all the possible permutations that can occur in a multi-responder situation.
Indeed, it may be impossible to satisfy every schematron rule, short of sending deliberately incorrect data. In extreme cases you might need to seek permission from your state trauma registry to disable AngelTrack's split-reporting feature and just use the single-combined report, discussed below.
UUID
After obtaining an opinion from the NEMSIS TAC on this topic, we have implemented a separate UUID for each PatientCareReport node in the payload. That is to say: Each responder who completes a reportable chart will be stamped with a distinct UUID when uploaded to the trauma registry.
Off By Default / Compatibility
This feature is off by default. To take advantage of it, you must switch it on, from the "State uploads" section of your Preference page, under Settings.
But before enabling it, please verify compatibility with your state trauma registry or other downstream consumer (such as a country or regional registry). You can send them this KB article and get their blessing to upload your multi-response trips in this manner.
When this feature is off, then AngelTrack uses single-combined reporting for any BLS+ emergent multi-responder call, same as it does for non-emergent and wheelchair calls, discussed below.
You can entirely opt out of combined- and split-reporting by ignoring AngelTrack's multi-response dispatcher UI, instead booking each additional responder as a separate dispatch.
Whether or not you activate this feature, AngelTrack's trauma registry uploads are guaranteed to pass XSD validation, and thus are valid according to the letter of the spec. AngelTrack is also NEMSIS certified as compliant. However, there is presently no certification of multi-responder split-report payloads -- neither for PCR vendors nor for trauma registry vendors. Ergo, your state's trauma registry might not support this feature, and is not required to. Your mileage may vary.
We think your trauma registry will be thrilled by the richness of the data AngelTrack sends for secondary responders, but their software platform may not like it and they may not have the power to change that.
Non-Emergent, Wheelchair, Gurney Van, and Car Calls
The multi-responder split-report feature does not activate for these call types:
- BLS non-emergent / interfacility
- Wheelchair van
- Gurney van (aka non-medical stretcher transport)
- Car service
- On-scene labs
- Telemedicine
For these call types, the participation of secondary responders is low significance -- usually just lift assist or customer service -- and so AngelTrack combines all PCR data for all responders into a single large report (i.e. a single /PatientCareReport node) whose /eCrew node lists all crew members from all responding vehicles.
That means the following data about the secondary (non-transport) responders is omitted from the single combined XML:
- /eTimes unit-specific datafields
- /eResponse unit-specific datafields
- /eDisposition unit-specific datafields
Note: Your AngelTrack server is configured by default to consider wheelchair van, gurney van, car service, on-scene labs, and telemedicine calls as "not reportable" to your state, but someone may have switched them on, requiring AngelTrack to upload them to your state, in which case it uses the single-combined-report format.