AngelTrack has a friendly and graceful CAD API, for third-party CAD applications to push calls into the system using the NEMSIS XML format
Configuration Checklist
To use this API with a third-party CAD, login to AngelTrack with 'Administrator' privileges and then perform the following configuration steps:
- Select or create an employee account in AngelTrack to act as the proxy for requests sent by the third-party CAD. This can be the user account of the person who operates the third-party CAD, or it can be a pseudo-person as discussed in the Authentication section.
- Go to Settings and select the API Configuration item. There is already a built-in API key for CAD API access. You can modify it or issue a new API key if you wish, to specify the proxy employee account you created above.
- After the API key is ready, copy the API key and the API URL(s), as you will need to input them into your third-party CAD application. For further reading about AngelTrack API keys, refer to the API Keys Guide.
- If the third-party CAD is also responsible for assigning vehicles and crews to the calls, then AngelTrack will be auto-creating the necessary shift records to accomplish this. To allow AngelTrack to then automatically close those shifts out after they finish, and also to allow your crews to close out their own calls (since your dispatchers are not using AngelTrack's dispatch board), you must activate AngelTrack's unattended mode, and keep it always active. If you have no dispatch office at all, then activate AngelTrack's Self-Dispatch PCR mode. Either mode can be activated by browsing to Settings and selecting the Preferences item.
- Configure your third-party CAD application with the API URL(s) and the API key. If the third-party CAD application allows, send a test request to verify that the URL and API key are correct.
- AngelTrack automatically applies all default tags to each new trip created via this API. If you want AngelTrack to also apply a special tag indicating that the trip was pushed in by an external CAD, then create a tag in the system named "External API". More about this below.
- For EMS work (BLS+ services), make sure that AngelTrack has already got your state's facility list installed, and make sure this list matches the one in the third-party CAD application, because these facility IDs are needed when the trip reports are later uploaded to the state trauma registry. (This API has a /Configuration URL by which your third-party CAD can retrieve the current facility list, if needed; details below.)
- If the third-party CAD will also be assigning crews and telling AngelTrack about the assignments, then review the "Assigning a Responder" section below.
Supports Both v340 and v350
The CAD API accepts data in NEMSIS v3.4.0 or v3.5.0 format.
AngelTrack is natively v3.5.0, so any data sent in v3.4.0 will be automatically up-converted.
We know that the NEMSIS spec is daunting. Don't worry, AngelTrack's CAD API performs no XSD enforcement, so you can send an abbreviated NEMSIS payload with most of the fields omitted. Just send whichever fields you have data for; AngelTrack will back-fill everything else with default values.
Scroll down to the bottom of this document to see a couple of sample XML files.
URLs
AngelTrack's CAD-NEMSIS API is RESTful, using simple GET and POST requests.
To learn the API URLs for your AngelTrack server, log in to AngelTrack with 'Administrator' privileges, go to Settings, and click the CAD API item.
The API is available 24/7, subject to AngelTrack's weekly maintenance windows.
All API GET requests must include a header field named "Accept" set to one of these two options, depending on how you prefer your reply data to be serialized:
application/xml; charset=utf-8
application/json; charset=utf-8
Likewise all API POST requests must include a header field named "Content-Type" set to one of the two aforementioned values, to describe the body of your request.
More about this below.
Authentication
In addition to the aforementioned content-type header, every API request must include a header field named "Authorization", containing an authentication payload which looks like this:
Bearer [API key]
The "API key" is an API key which you can issue and retrieve from AngelTrack's UI under Settings. It is a UUID. Include the dash characters but do not include any curly braces or whitespace. Here is an example of a completed Authorization header:
Bearer F0BBC854-9222-486F-A76B-658FCF9E06AA
The provider has the power to change or revoke an API key whenever they wish, so your API key might stop working if they choose to disconnect you from the API.
Testing the API
To test the API and your key, send a GET request to the /Nemsis URL for trip ID zero, like this:
GET https://your_server_name.angeltrack.com/the_api_url_for_your_server/0
Your GET request must include the "Authorization" header as discussed above.
The reply will be the standard data structure as discussed in the "Reply Data" section below, with its TripXML property set NULL because zero is never a valid dispatch ID.
Do you need a sandbox for testing?
If you are implementing this API but are not partnered with a specific AngelTrack customer with whom you can run tests, please contact AngelTrack headquarters, so that we can set you up with a sandbox server.
Reply Data
You will always receive back an HTTP status code 200 unless something went seriously wrong.
All lesser errors, such as parsing failures or complaints about missing values, will still return HTTP status code 200, with diagnostic information returned inside the reply body.
The reply body from any GET or POST to the /Nemsis URL is always a serialization of this C# structure:
using System;
using System.ComponentModel.DataAnnotations;
namespace AngelTrack.Data.CAD
{
public class NemsisReplyData
{
/// <summary>
/// Contains the AngelTrack build number of the answering server, for use in the
/// future for deciding whether certain API functions are available.
/// </summary>
public int AngelTrackBuildNumber { get; set; } = 0;
/// <summary>
/// Contains the unique integer ID of the dispatch record in AngelTrack that was created or updated.
/// Contains zero if there was any error.
/// </summary>
public int DispatchID { get; set; } = 0;
/// <summary>
/// Contains the external record ID originally sent by the client in eRecord.01, which becomes correllated
/// inside AngelTrack with the dispatch record that was created.
/// Contains an empty string if there was any error.
/// </summary>
public String ExternalRecordID { get; set; } = String.Empty;
/// <summary>
/// Contains the NEMSIS UUID of the dispatch record in AngelTrack that was created or updated.
/// This value never changes, and allows you to track a trip all the way through to the NEMSIS TAC national repository.
/// Contains the value Guid.Empty if there was any error.
/// </summary>
public System.Guid DispatchUUID { get; set; } = System.Guid.Empty;
/// <summary>
/// Contains 200 upon success, in which case there will be at least one message in the StatusMessages
/// property. There might be a message in the ErrorMessages property if a tolerable error occurred,
/// such as if you send a trip which is to be assigned to a vehicle callsign that AngelTrack does not
/// recognize.
/// The API never returns any HTTP code in the range 201-299.
/// Contains an HTTP status code between 300 and 599 to indicate a serious error that wholly prevents
/// the processing of the request.
/// </summary>
[Range(200, 599)]
public int EquivalentHttpStatusCode { get; set; } = 200;
/// <summary>
/// When EquivalentHttpStatusCode == 200, this will contain one or more more informational messages
/// about the processing of the request:
/// On a POST to create or update a trip, this message will be "Trip created" or "Trip updated" or similar.
/// On a GET for trip status where NOT specifying the ?Verbose=1 parameter in the query string,
/// then this will also contain the trip status message, such as "Transporting for 15 minutes".
/// When EquivalentHttpStatusCode >= 300, this may be empty, or it may contain some informational messages
/// subordinate to the error(s) reported in the ErrorMessages property.
/// </summary>
public System.Collections.Generic.List<String> StatusMessages { get; set; } = new System.Collections.Generic.List<String>();
/// <summary>
/// When EquivalentHttpStatusCode >= 300, this will contain at least one explanation.
/// When EqiuvalentHttpStatusCode == 200, this may be empty, or it may contain reports of tolerable
/// errors, such as a failure to assign the trip to the specified unit due to an inability to
/// match the vehicle's callsign or the crew members' patch numbers against AngelTrack's records.
/// </summary>
public System.Collections.Generic.List<String> ErrorMessages { get; set; } = new System.Collections.Generic.List<String>();
/// <summary>
/// On a GET for trip status where you DO specify the ?Verbose=1 parameter in the query string,
/// then this property will be returned with the contents in NEMSIS v3.5.0 format.
/// It will not be a fully valid NEMSIS document, because
/// about half the top-level nodes (such as eVitals) will be omitted for brevity.
/// If you need to retrieve a full and complete NEMSIS document for the trip,
/// then use AngelTrack's billing API instead.
/// </summary>
public String TripXML { get; set; } = null;
}
}
Whether the reply data is serialized in XML or JSON depends on what you sent in the content-type header (be it "Accept" or "Content-Type"). You can choose either one to suit your application.
Any items in the ErrorMessages property ought to be displayed to the CAD user, to let them know that the request failed or could not be fully processed as expected. Whereas the contents of the StatusMessages property are informational and can be discarded once you are satisfied that your integration is debugged.
Upon success, the DispatchID field contains an integer greater than zero. Dispatch IDs in AngelTrack never change, and will always be correlated to your own record ID that you sent in the eRecord.01 field (discussed below). You will also get back the trip's UUID in the DispatchUUID field; this data can be used to track the trip after AngelTrack sends it to the trauma registry, and from there to the national repository.
Submitting a New or Updated Trip
To create or update a trip, send a POST message to the /Nemsis URL whose body contains a single NEMSIS XML document, in either v3.4.0 or v3.5.0 format. The XML document must be smaller than 1MB, and its namespace must be "http://www.nemsis.org". If the document contains more than one /PatientCareReport node, only the first will be processed; all others will be ignored.
There is normally no query-string needed for this POST, as all necessary data must be in the NEMSIS XML that comprises the request body. However, there are some query-string options discussed below that control the auto-match and auto-creation of crew and vehicle records; see the sections on eCrew.01 and eResponse.14 for details.
AngelTrack will scrape and import your XML into a dispatch record. The following XML nodes are imported, all other data will be ignored:
- /eRecord
- /eResponse
- /eDispatch
- /eCrew
- /eTimes
- /ePatient
- /ePayment (including PCS form if any)
- /eScene
- /eHistory
- /eNarrative
- /eVitals
- /eExam
- /eDisposition
- /eDevice
- /eOther
- /eCustomResults (AngelTrack custom fields only)
At the bottom of this help document, there is a sample XML file showing what a populated request looks like.
Date/Time Fields
All date/time fields in the NEMSIS spec include a timezone offset, so you can send UTC times if you like:
2023-12-27T11:15:42+00:00
...or you can send a non-zero timezone offset, but either way, AngelTrack will convert all date/time data to the provider's local time.
Critical Fields for Trip Submissions
The following XML nodes in the POST payload are used to control the assignment, execution, and disposition of the trip.
/eRecord/eRecord.01
This field must contain the unique record ID of the trip in your (external) CAD system. AngelTrack will store it as a cross-reference to its own dispatch ID, so that you can later send updates to the same trip.
Your record ID must be printable ASCII (i.e. character codes between 33 and 127 inclusive), and can be up to 20 characters long.
Take care never to send unintentional duplicate values in this field. Furthermore, your trip IDs must be unique across all CAD applications that are using AngelTrack's CAD API, so best practice is to prefix your trip IDs with the abbreviated name of your app, like this if your app is named SuperCAD and your trip ID is 123456:
<eRecord.01>SuperCAD-123456</eRecord.01>
You cannot send updates for a trip that you did not submit via this API.
/ePayment/ePayment.50 and eDisposition/eDisposition.16
These two fields are used by AngelTrack to infer the service being requested... but only if there is no eCustomResults.ResultsGroup node where eCustomResults.02 = "ATServiceLevel" and eCustomResults.01 specifies a recognizable AngelTrack service level descriptor; see below for details.
For all BLS+ services, use ePayment.50.
If ePayment.50 is empty or missing, then AngelTrack checks eDisposition.16 instead. To book a call for car service, specify 4216011 in eDisposition.16. To book a call for wheelchair van service, specify 4216015. To book a call for gurney-van service, specify 4216013.
For services other than transports, you must pass an eCustomResults.ResultsGroup node to specify the service being requested; see below for details.
If all three of the aforementioned fields are empty or missing, then AngelTrack assumes you are requesting BLS service.
If you push a request for a service that the provider does not offer (per the Service Levels Configuration under Settings), then the API will refuse to book the call, and instead will return an error message.
/eResponse/eResponse.14
This field must contain the name or call-sign of the vehicle to which AngelTrack should automatically assign the call.
If this field is empty, then the trip will still be imported but will be left unassigned (if the trip has no time-completed) or will be marked as a cancellation (if the trip has a time-completed).
If eResponse.14 contains a callsign that AngelTrack cannot match to an active vehicle record, then it will auto-create a vehicle record matching the capabilities reported in the NEMSIS XML. To disable vehicle auto-creation, and instead receive a "Vehicle not found" error reply from your trip submission, then include this query-string in the API URL:
?ProceedIfNoCrewMatch=0
Assuming that AngelTrack can match the vehicle name or call-sign, or can auto-create it, AngelTrack will attempt to assign the call to an existing shift record that matches the specified vehicle and crew members. If no such shift is available, then it will auto-create one specifically for the trip, which will auto-end when the trip completes*.
Any auto-created shift record will be marked as posting at whichever station its vehicle is based at. If the vehicle is marked "float", then the auto-created shift record will be marked as posting at the first station found to fall within the same zone as the trip's pickup address.
*Automatic closure of shift records requires AngelTrack to be in Unattended Mode. Please refer to the configuration checklist at the bottom of this document.
/eCrew/eCrew.CrewGroup/eCrew.01
This field must contain the patch number -- i.e. the certificate number of the crew member's EMS patch or fire rating -- or else the "Provider-issued ID number" (as configured in their employee record), of each crew member onboard the vehicle to which the trip is to be assigned.
If AngelTrack cannot match the patch number to the aforementioned datafields, then it will check for the presence of ImageTrend-style eCustomResults nodes with IDs "itCrew.01" and "itCrew.02" in your NEMSIS XML submission. These eCustomResults nodes contain each crew member's first and last names, linked to the @CorrelationID in the /eCrew/eCrew.CrewGroup nodes. If a first name and a last name are present, then AngelTrack will auto-create an employee record and issue it an EMS certificate for the privileges mentioned in eCrew.02.
If AngelTrack cannot match or auto-create at least one employee record for the crew members in /eCrew, then AngelTrack will still import the trip, but it won't get auto-assigned to the responder you wanted. If the trip has no time-completed, it will be left active and unassigned; else it will be closed and marked cancelled.
If you are pushing wheelchair or gurney-van calls via the API and also assigning them to drivers who don't have EMS patch numbers, then you can use their driver's license numbers instead... as long as they've input their driver's licenses into their certificate lists in AngelTrack.
If you want AngelTrack to fail the import if it can't match a requested crew patch and cannot auto-create a matching employee record, and instead you want to get an error message returned to you, then include this query-string in the URL:
?ProceedIfNoCrewMatch=0
/eDisposition/eDisposition.IncidentDispositionGroup/eDisposition.27
If submitting data in NEMSIS v3.5.0 format, AngelTrack checks this optional field to see if the responding unit (as specified in eResponse.14/eCrew.01) has been unassigned. If you send the value 4227005 ("Cancelled prior to arrival on-scene") in this field, then AngelTrack will use eResponse.14 and eCrew.01 to find the responding unit in question, and unassign it. Any other responding units will remain assigned. See below for further discussion of assigning and unassigning responders.
Any other value in this field is ignored, because AngelTrack expects to collect organic disposition information from the crews. If you want to completely close out the call (whether or not any units have responded to it), use eTimes.16 as discussed below.
/eDisposition/eDisposition.12
If submitting data in NEMSIS v3.4.0 format, AngelTrack checks this optional field to see if the responding unit has been unassigned. If you send the value 4212007 ("Cancelled prior to arrival on-scene") in this field, then AngelTrack will use eResponse.14 and eCrew.01 to find the responding unit in question, and unassign it. Any other responding units will remain assigned. See below for further discussion of assigning and unassigning responders.
Any other value in this field is ignored, because AngelTrack expects to collect organic disposition information from the crews. If you want to completely close out the call (whether or not any units have responded to it), use eTimes.16 as discussed below.
/eTimes/eTimes.02
This mandatory field contains the date/time at which the call entered your (third-party) CAD system. AngelTrack will store this as the trip's activation time. You can send trips which activated in the past or which will activate up to seven days in the future.
If sending a dispatch which activated longer than 7 days ago, then it must be already closed, i.e. you are pushing in retroactive call data, including an eTimes.16 value, and therefore are not expecting AngelTrack to activate the call and find a crew to run it.
You do not need to send the date/time at which you pushed the data into AngelTrack.
To mark a trip as "Will Call", set eTimes.02 to at least six hours in the past.
/eTimes/eTimes.03
If this optional field contains a date/time, then AngelTrack will use it to search for a matching shift record of the crew who ran/will run the call. This can differ from eTimes.02 so that you can send a call that did not assign its crew until it had already been waiting for a period of time.
This date/time cannot be more than six hours in the future; i.e. you cannot assign a call to a unit if the call's activation time is more than six hours away.
AngelTrack will also use this date/time to find or create a shift record that matches the vehicle and crew specified in eCrew.01 and eResponse.14.
/eTimes/eTimes.06
This optional field would normally specify the time at which the unit arrived on-scene. You cannot send such data to AngelTrack, because AngelTrack intends to collect that data organically from the crews. Instead, you can send eTimes.06 to specify the scheduled pick-up time, if any.
/eTimes/eTimes.11
This optional field would normally specify the time at which the unit arrived at destination. You cannot send such data to AngelTrack, because AngelTrack intends to collect that data organically from the crews. Instead, you can send eTimes.11 to specify the scheduled drop-off time, if any.
/eTimes/eTimes.16
If this optional field contains a date/time, then AngelTrack will close the dispatch, marking it "Completed, As Ordered" if a crew was assigned, else marking it "Cancelled, No Postprocess". Otherwise, the dispatch will be left open; it will be the responsibility of the crew or AngelTrack dispatcher to close the dispatch when appropriate. If it is always the crew's responsibility to close dispatches upon returning to service, i.e. if there is no dispatcher on duty, then be sure to activate AngelTrack's unattended mode.
Closed dispatches cannot be re-opened; to re-open one, you must send a new trip record with a different eRecord.01 value.
Trip-aggregator platforms who do not assign units and monitor their progress do not need ever to send this field; leave it to the provider's dispatcher or crews to close out the call when appropriate.
Another warning: If you push an assigned call but AngelTrack couldn't match a vehicle and at least one crew member, then the call will stay unassigned in AngelTrack. If you then close that call, AngelTrack will mark it as a cancellation rather than as a completion, since it doesn't have a shift record for the crew who ran it.
/ePayment/ePayment.01
This optional field specifies the trip's bill-to settings.
If you specify 2601015 or 2601017, then AngelTrack will mark the call as billable to the origin or destination facility -- whichever one could be matched to an existing facility record.
If you omit this field, then AngelTrack will choose the bill-to settings automatically, by comparing the requested service level against the billing defaults in the Service Levels Configuration and against the contract settings of the origin and/or destination facility record (if any could be matched to the pickup/dropoff address).
/ePayment/ePayment.53
This optional field specifies the prior authorization number issued by the patient's insurance carrier.
/eScene/eScene.10
This optional field contains the state facility ID, if any, of the origin address, so that AngelTrack can link that facility record to the trip. State facility IDs are issued by the state trauma registry, and AngelTrack will already have that list onboard.
If this field is blank, then AngelTrack will still try to match a facility record to the trip's origin address fields.
State facility IDs for the pickup point are important when validating against certain state schematrons, so you must send this field if at all possible.
To retrieve a list of available state facility IDs, use the /Configuration GET method provided by the CAD API.
/eScene/eScene.17
This optional field specifies the origin city. In the NEMSIS spec this field must contain a GNIS code; however, AngelTrack will also allow you to pass the city's plaintext name instead, if you like.
/eScene/eScene.18
This optional field specifies the origin state. In the NEMSIS spec this field must contain an ANSI two-letter state code; however, AngelTrack will also allow you to pass the state's abbreviation or name instead. For example, for Texas you can pass "48", "TX", or "Texas", whichever is easier for you.
/eScene/eScene.21, /ePatient.ePatient.07, and /eDisposition/eDispositionGroup/eDisposition.06
Please include county codes if you already know them, otherwise AngelTrack will try to identify the county using the city and state which is not 100% accurate.
You can send a three-digit FIPS county code, or you can send the full five-digit state code + FIPS county code as suggested by the NEMSIS spec, either is fine.
/eSituation/eSituation.19
This optional field, available only in NEMSIS v3.5.0, specifies the dispatcher comments, which will be shown to the crew. Use the field to give the crew a heads-up about what they can expect on-scene.
/ePayment/ePayment.45
This optional field, available only in NEMSIS v3.5.0, specifies the dispatcher comments, which will be shown to the crew. Use the field to give the crew a heads-up about what they can expect on-scene.
/eDisposition/eDisposition.DestinationGroup/eDisposition.02
This optional field contains the state facility ID, if any, of the destination address, so that AngelTrack can link that facility record to the trip. These IDs are issued by the state trauma registry, and AngelTrack will already have the trauma registry's facility list onboard.
If this field is blank, then AngelTrack will still try to match a facility record to the trip's destination address fields.
State facility IDs for the destination are very important when validating against most state schematrons, so you must send this field if at all possible.
To retrieve a list of available state facility IDs, use the /Configuration GET method provided by the CAD API.
/eDisposition/eDisposition.DestinationGroup/eDisposition.04
This optional field specifies the destination city. In the NEMSIS spec this field must contain a GNIS code; however, AngelTrack will also allow you to pass the city's plaintext name instead, if you like.
/eDisposition/eDisposition.DestinationGroup/eDisposition.05
This optional field specifies the destination state. In the NEMSIS spec this field must contain an ANSI two-letter state code; however, AngelTrack will also allow you to pass the state's abbreviation or name instead. For example, for Texas you can pass "48", "TX", or "Texas", whichever is easier for you.
/ePatient/ePatient.01
This optional field should contain the patient record ID in the third-party CAD, if any; else, leave it empty.
If this field contains 8 or more characters, then AngelTrack will place that information into the "Bar-code" field in the patient's record in AngelTrack. It will then be used to match and link to an existing patient record. Thus you can send several calls for the same patient, and AngelTrack will link them all together using this record ID, which is stronger record matching than traditional name+DOB match.
Take care never to send unintentional duplicate values in this field.
/ePatient/ePatient.06
This optional field specifies the patient's home city. In the NEMSIS spec this field must contain a GNIS code; however, AngelTrack will also allow you to pass the city's plaintext name instead, if you like.
/ePatient/ePatient.08
This optional field specifies the patient's home state. In the NEMSIS spec this field must contain an ANSI two-letter state code; however, AngelTrack will also allow you to pass the state's abbreviation or name instead. For example, for Texas you can pass "48", "TX", or "Texas", whichever is easier for you.
/eCustomResults/eCustomResults.ResultsGroup/eCustomResults.01[../eCustomResults.02 = 'ATPriceQuote']
This optional field contains the price quoted to the customer, if any, as a decimal number. If omitted, then AngelTrack will leave the price quote blank, which means the trip will be auto-priced later, after QA has determined the service and mileage provided.
This field must be part of an eCustomResults/eCustomResults.ResultsGroup parent node which also contains an eCustomResults.02 child node whose value is set to "ATPriceQuote". There is an example of this shown below, in the sample XMLs.
If you wish to later remove a price quote, causing AngelTrack to revert to auto-pricing, then send an update with a zero value in this node.
/eCustomResults/eCustomResults.ResultsGroup/eCustomResults.01[../eCustomResults.02 = 'ATWaitAndReturn']
In this optional field send "9923003" (which is the NEMSIS value for "Yes") to mark the trip as a wait-and-return. If the trip already has a return trip paired with it, then the return trip will also be marked as a wait-and-return.
If you wish to later remove the wait-and-return designation, then send an update with "9923001" ("No") in this field, or omit the field completely.
/eCustomResults/eCustomResults.ResultsGroup/eCustomResults.01[../eCustomResults.02 = 'ATBillingNotes']
This optional field contains up to 4000 characters to be placed in the "Billing Notes" field, which is shown to dispatchers and to billers but not to crew members.
This field must be part of an eCustomResults/eCustomResults.ResultsGroup parent node which also contains an eCustomResults.02 child node whose value is set to "ATBillingNotes". There is an example of this shown below, in the sample XMLs.
You can set this field when you first create a trip, but you cannot later modify it or clear it during updates sent via the API.
Booking Non-Transport Services
As noted above, AngelTrack will infer the EMS-related service level being requested by looking at ePayment.50 and eDisposition.16. These two fields are sufficient for all transports, including car service, gurney van, wheelchair van, and BLS+. See above for details.
If, however, you wish to book a fire response, or an on-scene labs visit, you must instead send an eCustomResults.ResultsGroup node like this:
<eCustomResults.ResultsGroup>
<eCustomResults.01>Fire</eCustomResults.01>
<eCustomResults.02>ATServiceLevel</eCustomResults.02>
</eCustomResults.ResultsGroup>
In the eCustomResults.01 field, you can specify any of these text values (case sensitive):
- Fire
- Extricate
- Rescue
- Hazmat
- Inspection
- Good-intent
- Labs
- Car
- WC
- Gurney
- BLS
- ALS
- MICU
If AngelTrack sees this eCustomResults.01 field, then it will book the requested service, and ignore anything sent in ePayment.50 or in eDisposition.16.
Note that if you book a call for a service which the provider does not currently offer (per the Service Levels Configuration under Settings), AngelTrack will rebuff the request with an error message.
Also note, the various non-transport service levels (fire, labs, inspection) do not have destination addresses, so AngelTrack will ignore anything you send in /eDisposition/eDisposition.DestinationGroup.
Assigning a Responder
As noted above, if you want AngelTrack to assign the trip to a responder, you must specify that unit's identifiers in eResponse.14 and eCrew.01. AngelTrack must be able to find a vehicle record in its database whose name or call-sign matches eResponse.14, and it must be able to find at least one crew member for whom eCrew.01 matches one of the following:
- Provider-issued ID number
- EMS patch number
- Fire, fire officer, rescue, or hazmat patch number
- Driver's license number
If there are any duplicates among the above fields between your crew members, such that AngelTrack might match the wrong employee, then set the "Provider-issued ID number" for all affected employees, because AngelTrack checks that field for a match before it checks any patch numbers. See notes above for more help with eCrew.01.
As noted already, you can send an active call which activated up to seven days in the past, or which will activate up to seven days in the future. If the call's activation time is more than six hours in the future, then you cannot yet assign a responder to it. To get full and flexible preassignment functionality, you must use AngelTrack's UI.
If you want AngelTrack to fail the import if it can't match the requested vehicle call-sign and crew patch number(s), and return an error message to you, then include this query-string in the URL:
ProceedIfNoCrewMatch=0
Unassigning a Responder
To unassign a trip from one particular responder to which it is currently assigned, send the XML payload with the responding unit's identifiers in eResponse.14/eCrew.01 and with the cancellation value in eDisposition.12/eDisposition.27 (as discussed above).
To unassign a trip from all responders to which it is currently assigned, send the XML payload with the eResponse.14 node empty.
These actions will entirely remove the unit(s) from the call's list of responders, so do not do this for units who've arrived on-scene and then handed off, because their responses should remain in AngelTrack's records. For further reading on how AngelTrack handles multiple responders on-scene, read the Multiple Responders Guide.
In any case, unassignment actions will not close out the call, except under one circumstance: If you unassign the final active responder, and if other responders were also active but have since returned to service, then AngelTrack will auto-close the call, on the understanding that other responder(s) provided the service and you are removing an assisting unit.
Once a call has closed, you cannot unassign or reassign responders; you must use AngelTrack's UI for that.
Multiple Responders
It is easy to assign multiple responders to a call; simply send the XML payload once for each responding unit, with the necessary vehicle identifier in eResponse.14 and the necessary crew identifiers in eCrew.01. Any time that AngelTrack receives an XML and is able to match those identifiers to a vehicle and at least one crew member, it will create a shift record for them (if not already existing) and then add them as a responder to the call.
There is no need for a special value in eResponse.04; that field is ignored.
Just follow the instructions above for assigning and unassigning responders. You can add and remove responders freely, until such time as you close the call (eTimes.16) or an AngelTrack dispatcher or a crew member closes the call.
Be sure you review the Multiple Responders Guide to understand how AngelTrack handles multi-responder situations.
Split EMS+Fire Responses
Each dispatch in AngelTrack can have only one service level. Therefore, an incident requiring both an EMS response (NEMSIS reportable) and a fire response (NFIRS reportable) requires two separate dispatch records... even if they have the same timestamp and street address.
If the third-party CAD handles these situations as a single incident record in its own database, then append some extra characters to eRecord.01 when sending it to AngelTrack. For example, if the third-party CAD's native record ID for the incident is 142004, then send a request to AngelTrack for an ALS response with eRecord.01 set to "142004-ALS", and then send a second request to AngelTrack for a fire response with eRecord.01 set to "142004-Fire".
You will get back two separate AngelTrack dispatch IDs, but you don't need to keep track of those, because AngelTrack remembers the values you sent in eRecord.01 and so can always match up any updates you send later to the records that were created earlier.
You can assign the same crews or different crews to the two calls, via eCrew.01 and eResponse.14, in the usual way. AngelTrack will know that the calls are linked, owing to the same street address and same timeframe, but this linkage does not affect the assignment of responders or of attached patient records. That is to say, if the third-party CAD also assigns responders, then you must manage the responder(s) for the EMS dispatch separately from those of the fire dispatch.
Patient Records
The following fields control how AngelTrack matches or creates a patient record for the trip:
- /ePatient/ePatient.01 (barcode)
- /ePatient/ePatient.PatientNameGroup/ePatient.02 (last name; "UNKNOWN" is ignored)
- /ePatient/ePatient.PatientNameGroup/ePatient.03 (first name; "UNKNOWN" is ignored)
- /ePatient/ePatient.17 (date of birth)
- /ePatient/ePatient.12 (SSN; known fake SSNs are ignored)
To prevent clashes between the patient identity in the third-party CAD versus patient identifiers recorded by crew members on scene, AngelTrack has different rules for when the API is creating a new trip versus for subsequent requests where the API is updating an existing trip...
Patient record match/create during trip creation
When creating a new trip via this API, if you send a patient barcode, or if you send an SSN, or if you send a last name plus date of birth, then AngelTrack will try to locate an existing patient record, and attach it if found.
Whereas if you send only a last name or a first name or both, AngelTrack will not search for an existing record, due to the high probability of false positives. Instead, AngelTrack will create a brand new patient record. Note that this can cause duplicate patient records, if you send several trips for the same patient and don't include DOB, SSN, or barcode. To prevent this, the third-party CAD should assign a unique ID to the patient, and then send that ID to AngelTrack as the patient barcode (ePatient.01) for each of their trips.
Patient record match/create during trip update
If you send an update to an existing trip and specify any of the following for the patient:
- a different barcode than before
- a different last name than before ("UNKNOWN" is ignored) and you include a DOB
- a different DOB than before and you include a last name ("UNKNOWN" is ignored)
- a different SSN (known fake SSNs are ignored)
...AngelTrack will detach any existing patient record, and then find or create a new one and attach it.
Otherwise, AngelTrack will leave in place any patient record already attached to the trip... even if the last name or first name no longer matches due to a change in the third-party CAD or a change made by crews in the field. This means that a third-party CAD who wishes to push a change to the patient's name must also push at least one of: barcode, SSN, or DOB.
If you want to find out what changes the crew may've made to the patient record, then request the trip progress data from AngelTrack, as discussed below.
Retrieving the Status of All Active Calls
The API includes a /BulkStatus URL by which you can retrieve the live status of all of your trips, in a single request.
Just request a GET with the necessary headers (explained above), and receive back an XML or JSON document containing these structures:
public class TripStatusReport
{
public int DispatchID { get; set; }
public String ExternalRecordID { get; set; }
public DateTime TimeActivated { get; set; }
public DateTime? TimeAssigned { get; set; } = null;
public DateTime? TimeEnroute { get; set; } = null;
public DateTime? TimeOnScene { get; set; } = null;
public DateTime? TimeOfPatientContact { get; set; } = null;
public DateTime? TimeTransportBegan { get; set; } = null;
public DateTime? TimeArrivedAtDestination { get; set; } = null;
public DateTime? TimeReturnedToService { get; set; } = null;
}
public class BulkStatusReplyData
{
/// <summary>
/// Contains the AngelTrack build number of the answering server, for use in the
/// future for deciding whether certain API functions are available.
/// </summary>
public int AngelTrackBuildNumber { get; set; } = 0;
/// <summary>
/// Contains 200 upon success, in which case there will be rows in the lists of configuraiton items.
/// The API never returns any HTTP code in the range 201-299.
/// Contains an HTTP status code between 300 and 599 to indicate a serious error that wholly prevents
/// the processing of the request.
/// </summary>
[Range(200, 599)]
public int EquivalentHttpStatusCode { get; set; } = 200;
/// <summary>
/// When EquivalentHttpStatusCode >= 300, this will contain at least one explanation.
/// When EqiuvalentHttpStatusCode == 200, this may be empty, or it may contain reports of tolerable
/// errors, such as a failure to assign the trip to the specified unit due to an inability to
/// match the vehicle's callsign or the crew members' patch numbers against AngelTrack's records.
/// </summary>
public System.Collections.Generic.List<String> ErrorMessages { get; set; } = new System.Collections.Generic.List<String>();
/// <summary>
/// Returns the provider's current local date/time, for use in comparing the timestamps in the trip status reports
/// </summary>
public DateTime ProviderLocalTime { get; set; } = DateTime.MinValue;
/// <summary>
/// Array of status reports for all dispatches which were sent via the CAD API and which are still active (not yet closed or cancelled).
/// </summary>
public System.Collections.Generic.List<TripStatusReport> TripStatusReports { get; set; } = new System.Collections.Generic.List<TripStatusReport>();
}
In the 'TripStatusReports' collection you will find one record for each trip which:
- Was submitted by this API;
- Has an activation time up to 20 hours in the past, or up to 4 hours in the future; and
- Is not yet completed or cancelled (you must use the regular /Nemsis URL to request the status of completed and cancelled trips).
The /BulkStatus URL supports only the GET verb. It is throttled to a maximum of 12 calls during any 18-minute period; any calls in excess of this amount will receive an error 429 "Too many requests".
Retrieving Brief Progress Data for a Specific Trip
At any time you can request status for any trip that you submitted via this API, showing the progress of the assigned unit (if any). To do so, send a GET request for the dispatch ID that AngelTrack returned to you earlier when you submitted the trip, and do NOT include any "Verbose=1" in the query-string.
This example shows how to request status for dispatch ID 42:
GET https://your_server_name.angeltrack.com/the_api_url_for_your_server/42
Your GET request must include the "Authorization" header as discussed above.
You cannot request data for a trip that was not submitted by this API.
The reply will be a standard data structure as discussed in the "Reply Data" section above. Its TripXML property will be NULL. Its StatusMessages property will contain a "Success." message, plus another message beginning with "Trip status: " that contains the brief progress report, suitable for display to your user.
You can request up to 20 brief progress reports per minute; any requests in excess of this will return EquivalentHttpStatusCode = 429 "Too many requests".
Retrieving Verbose Progress Data for a Specific Trip
At any time you can request a NEMSIS XML document for any trip that you submitted via this API, showing the progress of the assigned unit (if any). To do so, send a GET request for the dispatch ID that AngelTrack returned to you earlier when you submitted the trip, and include "Verbose=1" in the query-string.
This example shows how to request the verbose XML for dispatch ID 42:
GET https://your_server_name.angeltrack.com/the_api_url_for_your_server/42?Verbose=1
Your GET request must include the "Authorization" header as discussed above.
You cannot request data for a trip that was not submitted by this API.
The reply will be a standard data structure as discussed in the "Reply Data" section above. Its TripXML property will contain the NEMSIS v3.5.0 XML content for the trip -- but only these sections:
- /eRecord
- /eResponse
- /eDispatch
- /eCrew
- /eTimes
- /ePatient
- /eScene
If you require full NEMSIS XMLs with all the notes and document scans included, you must download them from AngelTrack's UI, or using the billing API.
Because these NEMSIS XMLs are costly to generate, you can request a maximum of 10 of them per minute, and this limitation includes any POSTs you send to create or update trips. Any requests in excess of this will return EquivalentHttpStatusCode = 429 "Too many requests". It is faster to request brief progress data instead; see above.
Other Limitations
Throttle
There is a throttle on this API endpoint:
- A maximum of ten requests per minute to create trips, update trips, or request verbose progress reports.
- Separately, a maximum of twenty requests per minute for brief progress reports.
If you exceed these limits, you will receive a reply with EquivalentHttpStatusCode = 429 "Too many requests".
No telemedicine
Presently, the API cannot book a call for telemedicine services.
If you need this feature, please get in touch, so that we can arrange an API extension using the eCustomResults node.
No automatic round trips / No automatic wait-and-return
If you wish to book a round trip, i.e. an outbound trip and a return trip that are paired, you must submit them as separate records, each with their own unique eRecord.01.
If you send two records, one an outbound trip and one for the return, then AngelTrack will automatically link them together as an outbound/return pair.
No automatic recurring trips
The API is not permitted to book an auto-recurring trip. Each individual trip must be booked separately.
No integration with crew scheduler
Although this API can book trips that do not activate for several hours, this capability is not intended for serious scheduling of future trips, or for graceful pre-assignments of crews to those trips. As such, the API does not integrate with AngelTrack's crew scheduler. Any shift that the API automatically creates will always activate immediately, even if not needed for several hours.
If you wish to take advantage of AngelTrack's trip scheduler, recurring trips, scheduled shifts, and preassignments, you must use AngelTrack's CAD.
No patient data updates
If your payload XML includes a patient name, SSN, DOB, or barcode (ePatient.01), AngelTrack will attempt to locate a matching patient record in its database. If no match is found, then AngelTrack will automatically create a new patient record, and populate it with all the data it can scrape from your request.
If, however, your request matches an existing patient record, then although AngelTrack will attach that record to the trip, it will not update it with any demographic or billing information. This limitation exists to prevent clashes between patient data in the third-party CAD versus patient data in AngelTrack that dispatchers and crews may be updating.
Thus, whatever PHI you have for the patient must be sent in your first request to create a new trip.
Shift records
If using this API to perform trip assignments to responding units, and if no dispatcher is using AngelTrack to create shift records for available units in the normal way, then this API will create ad-hoc shift records as needed. These are created on-the-fly to match each trip's time window, and so they probably will not accurately reflect the real time periods at which your crews were on the clock. There will usually also be duplicate shift records, if a call was booked and assigned but then its activation time or crew composition changed.
When using AngelTrack in this way, all of its reports that analyze shift records -- especially those covering utilization and staffing -- will not produce good data.
Automatic Round-Trip Pairing
If you send an outbound trip and then a return trip, AngelTrack will automatically pair them together, if possible, as long as they meet the following criteria:
Outbound trip's pickup street address, pickup city, and pickup state are the same as the return trip's dropoff street address, dropoff city, and dropoff state;
Same patient record attached to both calls;
Return trip's activation time (eTimes.02) is between +30 and +480 minutes after the outbound trip's activation time.
Automatic Tagging
Any trip created via this API will be automatically tagged with any tags that are marked as "Default". It will also receive any tag whose name is "External API".
Tags can auto-create service charges, so if you want to automatically apply a service charge to any trip received via this API, refer to the Service Charges Guide.
Reviewing the Server Logs
If you would like to see your API requests from the server's point of view, you may download recent API request logs from the CAD API for NEMSIS configuration item under Settings.
Retrieving the Facility List and Other Configuration Items
The API includes a /Configuration URL by which you can retrieve the provider's list of facilities, their list of facility types, their list of provided service levels, their list of choices for the dispatch complaint, and their list of insurance payor IDs.
If you need it, the provider can obtain this URL for you by visiting the CAD API configuration item under Settings.
The /Configuration URL offers only the GET verb, and it is throttled to a maximum of 24 requests during any 12-hour period.
In the facilities list returned by this URL, the 'id' field contains either the facility code assigned by the state trauma registry, or else an AngelTrack-assigned identifier prefixed with "ATRK-". Either way, the facility id is suitable to be sent back to the /Nemsis URL in the eScene.10 and/or eDisposition.02 field.
Sample XML Files
Here are examples of abbreviated NEMSIS XML files, suitable for submission to the /Nemsis URL of this API, containing all the fields a CAD might want to send. The API does not perform XSD enforcement, so you can send only those fields for which you have data.
This first example is for wheelchair transport from a nursing home to a dialysis center. The trip activates at 08:15 for a 9:00 pickup and 10:00 dropoff, and is billable under a contract with the nursing home. (For AngelTrack to auto-configure the billing arrangements, the nursing home must have a facility record in AngelTrack with the appropriate contract settings already configured.)
<?xml version="1.0" encoding="utf-8"?>
<EMSDataSet xmlns="http://www.nemsis.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.nemsis.org http://nemsis.org/media/nemsis_v3/release-3.5.0/XSDs/NEMSIS_XSDs/EMSDataSet_v3.xsd">
<Header>
<PatientCareReport>
<eRecord>
<eRecord.01>ECAD130002</eRecord.01>
<eRecord.SoftwareApplicationGroup>
<eRecord.03>Ultra-CAD 9000</eRecord.03>
</eRecord.SoftwareApplicationGroup>
</eRecord>
<eResponse>
<eResponse.14>WC41</eResponse.14>
</eResponse>
<eDispatch>
<eDispatch.01>2301071</eDispatch.01>
<eDispatch.02>2302001</eDispatch.02>
<eDispatch.05>2305007</eDispatch.05>
</eDispatch>
<eCrew>
<eCrew.CrewGroup>
<eCrew.01>0055001614</eCrew.01>
</eCrew.CrewGroup>
</eCrew>
<eTimes>
<eTimes.01>2022-12-16T14:10:00-00:00</eTimes.01>
<eTimes.02>2022-12-16T14:15:00-00:00</eTimes.02>
<eTimes.03>2022-12-16T14:20:00-00:00</eTimes.03>
<eTimes.06>2022-12-16T15:00:00-00:00</eTimes.06>
<eTimes.11>2022-12-16T16:00:00-00:00</eTimes.11>
</eTimes>
<ePatient>
<ePatient.01>EPAT18168</ePatient.01>
<ePatient.PatientNameGroup>
<ePatient.02>Smith</ePatient.02>
<ePatient.03>James</ePatient.03>
</ePatient.PatientNameGroup>
<ePatient.17>1960-01-02</ePatient.17>
</ePatient>
<ePayment>
<ePayment.01>2601017</ePayment.01>
</ePayment>
<eScene>
<eScene.09>Y92.12</eScene.09>
<eScene.10>ST006804</eScene.10>
<eScene.11>30.236256,-95.276360</eScene.11>
<eScene.13>Eastern Skilled Nursing</eScene.13>
<eScene.15>68040 Elm Street</eScene.15>
<eScene.16>Room 33</eScene.16>
<eScene.17>1380948</eScene.17>
<eScene.18>48</eScene.18>
<eScene.19>77070</eScene.19>
<eScene.21>48201</eScene.21>
<eScene.22>US</eScene.22>
</eScene>
<eSituation>
<eSituation.19>This field contains comments to the driver.</eSituation.19>
</eSituation>
<eDisposition>
<eDisposition.DestinationGroup>
<eDisposition.01>Quality Dialysis Center</eDisposition.01>
<eDisposition.02>ST001993</eDisposition.02>
<eDisposition.03 StreetAddress2="1993">19930 Franklin Street</eDisposition.03>
<eDisposition.04>1380948</eDisposition.04>
<eDisposition.05>48</eDisposition.05>
<eDisposition.06>48201</eDisposition.06>
<eDisposition.07>77070</eDisposition.07>
<eDisposition.08>US</eDisposition.08>
<eDisposition.09>30.216774,-95.317856</eDisposition.09>
</eDisposition.DestinationGroup>
<eDisposition.16>4216015</eDisposition.16>
<eDisposition.20>4220005</eDisposition.20>
<eDisposition.21>4221025</eDisposition.21>
</eDisposition>
</PatientCareReport>
</Header>
</EMSDataSet>
This next example is for BLS transport of a bed-confined DNR patient who requires oxygen, travelling from a nursing home to a dialysis center. The trip activates at 08:15 for a 9:00 pickup and 10:00 dropoff, is covered by the patient's MCR and MCD insurance, and was assigned (by the CAD) to a BLS crew aboard an ambulance named Medic53.
<?xml version="1.0" encoding="utf-8"?>
<EMSDataSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.nemsis.org">
<Header>
<PatientCareReport>
<eRecord>
<eRecord.01>ECAD119961</eRecord.01>
<eRecord.SoftwareApplicationGroup>
<eRecord.03>Ultra-CAD 9000</eRecord.03>
</eRecord.SoftwareApplicationGroup>
</eRecord>
<eResponse>
<eResponse.14>Medic53</eResponse.14>
</eResponse>
<eDispatch>
<eDispatch.01>2301071</eDispatch.01>
<eDispatch.02>2302001</eDispatch.02>
<eDispatch.05>2305007</eDispatch.05>
</eDispatch>
<eCrew>
<eCrew.CrewGroup>
<eCrew.01>001614</eCrew.01>
</eCrew.CrewGroup>
<eCrew.CrewGroup>
<eCrew.01>001590</eCrew.01>
</eCrew.CrewGroup>
</eCrew>
<eTimes>
<eTimes.01>2022-12-16T14:10:00-00:00</eTimes.01>
<eTimes.02>2022-12-16T14:15:00-00:00</eTimes.02>
<eTimes.03>2022-12-16T14:20:00-00:00</eTimes.03>
<eTimes.06>2022-12-16T15:00:00-00:00</eTimes.06>
<eTimes.11>2022-12-16T16:00:00-00:00</eTimes.11>
</eTimes>
<ePatient>
<ePatient.01>EPAT17099</ePatient.01>
<ePatient.PatientNameGroup>
<ePatient.02>Smith</ePatient.02>
<ePatient.03>Emery</ePatient.03>
</ePatient.PatientNameGroup>
<ePatient.05 StreetAddress2="Apt 32">170990 River Road</ePatient.05>
<ePatient.06>1380948</ePatient.06>
<ePatient.07>48201</ePatient.07>
<ePatient.08>48</ePatient.08>
<ePatient.09>77091</ePatient.09>
<ePatient.10>US</ePatient.10>
<ePatient.11>123456</ePatient.11>
<ePatient.12>111997099</ePatient.12>
<ePatient.13>9906003</ePatient.13>
<ePatient.14>2514011</ePatient.14>
<ePatient.AgeGroup>
<ePatient.15>68</ePatient.15>
<ePatient.16>2516009</ePatient.16>
</ePatient.AgeGroup>
<ePatient.17>1954-10-31</ePatient.17>
<ePatient.18 PhoneNumberType="9913003">713-997-7099</ePatient.18>
<ePatient.18 PhoneNumberType="9913009">713-997-7098</ePatient.18>
<ePatient.20>48</ePatient.20>
<ePatient.21>123456789</ePatient.21>
</ePatient>
<ePayment>
<ePayment.01>2601005</ePayment.01>
<ePayment.CertificateGroup>
<ePayment.04>2604001</ePayment.04>
<ePayment.04>2604033</ePayment.04>
</ePayment.CertificateGroup>
<ePayment.InsuranceGroup>
<ePayment.09>TXMCR</ePayment.09>
<ePayment.10>Medicare Part B of Texas</ePayment.10>
<ePayment.11>2611003</ePayment.11>
<ePayment.15>17055</ePayment.15>
<ePayment.17>222222222</ePayment.17>
<ePayment.18>111111111</ePayment.18>
<ePayment.19>Smith</ePayment.19>
<ePayment.20>Emery</ePayment.20>
<ePayment.22>2622001</ePayment.22>
</ePayment.InsuranceGroup>
<ePayment.InsuranceGroup>
<ePayment.09>60054</ePayment.09>
<ePayment.10>Aetna Medicaid Plans</ePayment.10>
<ePayment.11>2611005</ePayment.11>
<ePayment.17>444444444</ePayment.17>
<ePayment.18>333333333</ePayment.18>
<ePayment.19>Smith</ePayment.19>
<ePayment.20>Sheila</ePayment.20>
<ePayment.22>2622003</ePayment.22>
</ePayment.InsuranceGroup>
<ePayment.ClosestRelativeGroup>
<ePayment.23>Smith</ePayment.23>
<ePayment.24>Johnny</ePayment.24>
<ePayment.26>2001 Hillcroft</ePayment.26>
<ePayment.27>1380948</ePayment.27>
<ePayment.28>48</ePayment.28>
<ePayment.29>77057</ePayment.29>
<ePayment.30>US</ePayment.30>
<ePayment.31 PhoneNumberType="9913003">713-555-4444</ePayment.31>
<ePayment.32>2632003</ePayment.32>
</ePayment.ClosestRelativeGroup>
<ePayment.50>2650007</ePayment.50>
<ePayment.53>PAN123456</ePayment.53>
</ePayment>
<eScene>
<eScene.09>Y92.12</eScene.09>
<eScene.10>ST001968</eScene.10>
<eScene.11>30.063645,-95.273580</eScene.11>
<eScene.13>Southwest Skilled Nursing</eScene.13>
<eScene.15>19680 Main Street East</eScene.15>
<eScene.16>Suite 16</eScene.16>
<eScene.17>1380948</eScene.17>
<eScene.18>48</eScene.18>
<eScene.19>77030</eScene.19>
<eScene.21>48201</eScene.21>
<eScene.22>US</eScene.22>
</eScene>
<eSituation>
<eSituation.19>This field contains comments to the crew.</eSituation.19>
</eSituation>
<eHistory>
<eHistory.05>3105011</eHistory.05>
</eHistory>
<eDisposition>
<eDisposition.DestinationGroup>
<eDisposition.01>Southwest Dialysis Center</eDisposition.01>
<eDisposition.02>ST00408</eDisposition.02>
<eDisposition.03>4080 Main Street East</eDisposition.03>
<eDisposition.04>1380948</eDisposition.04>
<eDisposition.05>48</eDisposition.05>
<eDisposition.06>48201</eDisposition.06>
<eDisposition.07>77092</eDisposition.07>
<eDisposition.08>US</eDisposition.08>
<eDisposition.09>30.486595,-94.796221</eDisposition.09>
</eDisposition.DestinationGroup>
<eDisposition.16>4216005</eDisposition.16>
<eDisposition.20>4220001</eDisposition.20>
<eDisposition.21>4221007</eDisposition.21>
</eDisposition>
</PatientCareReport>
</Header>
</EMSDataSet>
This next example is for car service from the patient's residence to a dialysis center, activating at 10:00 for 10:30 pickup and 11:00 dropoff. The patient will be invoiced $55.60 for the trip. The external CAD has not assigned a responder. Because the request is for car service, the trip won't be reportable to any state trauma registry, therefore it is fine to omit the state facility IDs for the pickup and dropoff locations.
<?xml version="1.0" encoding="utf-8"?>
<EMSDataSet xmlns="http://www.nemsis.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<PatientCareReport>
<eRecord>
<eRecord.01>ECAD132004</eRecord.01>
<eRecord.SoftwareApplicationGroup>
<eRecord.03>UltraCAD 9000</eRecord.03>
</eRecord.SoftwareApplicationGroup>
</eRecord>
<eDispatch>
<eDispatch.01>2301071</eDispatch.01>
<eDispatch.05>2305007</eDispatch.05>
</eDispatch>
<eTimes>
<eTimes.02>2022-12-17T16:00:00-00:00</eTimes.02>
<eTimes.06>2022-12-17T16:30:00-00:00</eTimes.06>
<eTimes.11>2022-12-17T17:00:00-00:00</eTimes.11>
</eTimes>
<ePatient>
<ePatient.01>EPAT15543</ePatient.01>
<ePatient.PatientNameGroup>
<ePatient.02>Smith</ePatient.02>
<ePatient.03>Jimmy</ePatient.03>
</ePatient.PatientNameGroup>
<ePatient.17>1961-02-03</ePatient.17>
</ePatient>
<ePayment>
<ePayment.01>2601011</ePayment.01>
</ePayment>
<eScene>
<eScene.11>30.4710,-94.7730</eScene.11>
<eScene.13>Patient Residence</eScene.13>
<eScene.15>85130 Franklin Street</eScene.15>
<eScene.17>1331324</eScene.17>
<eScene.18>48</eScene.18>
<eScene.19>77423</eScene.19>
<eScene.21>48473</eScene.21>
<eScene.22>US</eScene.22>
</eScene>
<eSituation>
<eSituation.19>Park as close to the front stairs as possible.</eSituation.19>
</eSituation>
<eDisposition>
<eDisposition.DestinationGroup>
<eDisposition.01>Southwest Dialysis Center</eDisposition.01>
<eDisposition.03>4080 Main Street East</eDisposition.03>
<eDisposition.04>1380948</eDisposition.04>
<eDisposition.05>48</eDisposition.05>
<eDisposition.06>48201</eDisposition.06>
<eDisposition.07>77092</eDisposition.07>
<eDisposition.08>US</eDisposition.08>
<eDisposition.09>30.486595,-94.796221</eDisposition.09>
</eDisposition.DestinationGroup>
<eDisposition.16>4216011</eDisposition.16>
</eDisposition>
<eCustomResults>
<eCustomResults.ResultsGroup>
<eCustomResults.01>55.60</eCustomResults.01>
<eCustomResults.02>ATPriceQuote</eCustomResults.02>
</eCustomResults.ResultsGroup>
</eCustomResults>
<eCustomResults>
<eCustomResults.ResultsGroup>
<eCustomResults.01>Patient has hardship policy #H3294 in place.</eCustomResults.01>
<eCustomResults.02>ATBillingNotes</eCustomResults.02>
</eCustomResults.ResultsGroup>
</eCustomResults>
</PatientCareReport>
</Header>
</EMSDataSet>