State Trauma Registry Uploads

A walkthrough of what NEMSIS is, what your trauma registry customizations are, how to troubleshoot them

AngelTrack handles the uploading of your reportable EMS calls to your state trauma registry.

To see where each NEMSIS datafield comes from in AngelTrack, refer to the AngelTrack NEMSIS Crosswalk.

NEMSIS Validation

Before a run report can be submitted to your state trauma registry, it must pass NEMSIS validation.

Validation consists of three steps:

  1. Validation against the XSD files provided by NEMSIS. A .XSD file is a set of computerized rules governing the structure of a .XML file. Validation against the .XSD proves that AngelTrack created a well-formed .XML document that contains all data elements required by the NEMSIS organization.
  2. Validation against the Schematron file provided by NEMSIS. Schematron is a different set of computerized rules, governing certain if-then conditions in the data, such as "if the patient was transported, then a final patient condition must be recorded".
  3. Validation against any state or local Schematron file applicable to your service area. See below for details.

validation failure occurs when a piece of required data is missing. For example, if transport occurs, then the crew must provide (among other things) the patient's condition at destination. AngelTrack's pages indicate most of these requirements by turning the affected fields red, in order to draw the crew's attention to it. However, there is always the possibility that a supervisor or biller pushed a report to QA with some items still red. If not caught by QA, then that report will end up in the fail list.

Your AngelTrack cloud server knows which dispatches are reportable to your state trauma registry, and it will NEMSIS validate them for you. Any dispatch that fails validation will be flagged for you, along with a description of what caused the validation to fail.

Validation Points in AngelTrack's Workflow

As dispatches move through AngelTrack's postprocess workflow, NEMSIS validation occurs at four points:

  1. When the crew completes their report and attempts to send it to QA;
  2. When the QA reviewer signs off on the report and attempts to send it onward to Billing;
  3. When the report enters the State Upload Queue, which is the list of all reports that are ready for upload to the state trauma registry; and
  4. When a dispatch already in the State Upload Queue, or already uploaded to the state, experiences a modification of its followup data or PCR data.

At steps one and two above (send to QA / pass QA), NEMSIS validation is performed on-the-fly, when the employee clicks the button to send the report onward. If validation is successful, then the button click is acknowledged, and the page closes as normal. If the validation fails, then the page refuses to close, and shows the list of validation errors. The errors must be corrected before the report can be sent onward.

PostprocessWorkflow.Validations.1

Once a dispatch reaches the Billing office, it also enters the State Upload Queue. Once there, validation is performed one more time, in the background, by your AngelTrack cloud server. Any dispatch that passes validation will appear in the grid of dispatches ready for upload; any failures are displayed in the grid of failed dispatches, along with the list of validation errors.

PostprocessWorkflow.Validations.2

Automatic revalidation and reupload when data is changed

Once a dispatch graduates QA, it enters the State Upload Queue. It exits the queue after upload to the state trauma registry.

If followup data or PCR data are ever changed, then it will reenter the queue, including another NEMSIS validation. This is the fourth validation, and its outcome determines whether the modified dispatch appears in the "ready for upload" list or the "failed" list.

PostprocessWorkflow.Validations.3

AngelTrack keeps track of all of that for you. Uploads and re-uploads are recorded in the dispatch's journal, viewable on the "Journal" tab of the Dispatch Edit page.

3rd and 4th validations run slowly and continuously

Your AngelTrack cloud server performs the third and fourth validations in the background, once per minute, twenty-four hours a day, whenever any validations are needed.

Because this processing occurs in the background at a steady pace, it may take several minutes for it to reach a dispatch that you just modified. Your changed dispatch record may not immediately show up in the State Upload Queue.

Also, if you change the patient disposition or the execution status, the dispatch may no longer be reportable... in which case it will disappear from the queue altogether.

State and Local Schematrons

The NEMSIS national Schematron applies to every EMS run report in every state, and so is already installed on your AngelTrack cloud server. Your state's schematron, if any, is installed too, imposing additional requirements on your run reports.

If you have any county schematrons you must maintain compliance with, send them to AngelTrack support.

To check which state and county schematrons are already installed in your AngelTrack cloud server, visit the State Upload Status page under Settings.

Schematron updates

When your state publishes a new schematron, AngelTrack Support is notified, and will install it in your cloud server for you... typically within 7 days of its publication.

If you are also subject to a county-level schematron, then you must notify AngelTrack Support whenever your county updates it.

Importing Your State's Facility List

Most states maintain a list of hospitals and other prominent healthcare facilities, assigning a unique ID to each facility. Usually the ID is the facility's NPI, but sometimes the ID is an arbitrary number chosen by the trauma registry.

AngelTrack's data uploads to the trauma registry are supposed to include these facility IDs where applicable and where practical. That means you must input the ID for each facility in your facility list... and, of course, your dispatchers must take care to always attach the relevant facility records to dispatches.

Manually entering all those facility IDs is a miserable task. If your state's trauma registry is helpful, they will provide their facility list in electronic format.

Importing a facility list posted at NEMSIS

Your state is supposed to post their facility list in the national NEMSIS repository. AngelTrack can import it directly from there. This will already have been done for you when your AngelTrack server was first deployed, but you can do it again at any time to update the data.

To perform an import, visit your Facilities List and click the Add.multiple-4 button to open the Facility List Importer. The URL to your state's data in the NEMSIS repository will be pre-loaded and ready to go.

Unfortunately, not all states post a usable facility list; some are missing the street addresses or ZIP codes. In that case, you may instead be able to find your state's complete list posted elsewhere -- such as on their trauma registry's website.

Importing a CSV facility list

If your state has only an Excel or CSV facility list, AngelTrack can still import it.

The importer will offer a link to "Show detailed instructions"; click the link to display the complete rules for how your spreadsheet's columns must be named and ordered. Your data will probably require only minor adjustments, which can be performed right in Excel prior to the import. When you're done, If the format is a Microsoft Excel™ spreadsheet, do a "save as" to .CSV format, so that AngelTrack can digest it.

AngelTrack will make an effort to match/merge the new data into your existing facility records, in order to reduce the number of duplicates that are created during the import.

Jurisdiction of Interstate Transports

When you transport across state lines, AngelTrack calculates the jurisdiction state like this, using a Texas provider as an example:

  • Texas provider picks up in Texas and transports to Arkansas: Texas has jurisdiction
  • Texas provider picks up in Arkansas and transports to Texas: Texas has jurisdiction
  • Texas provider picks up in Arkansas and transports to Arkansas: Arkansas has jurisdiction
  • Texas provider picks up in Arkansas and transports to Louisiana: Arkansas has jurisdiction

The trip will be reportable to the state having jurisdiction. It is their schematron that will apply, and their custom data elements that must be collected.

The jurisdiction state also determines the service level of the crew; AngelTrack will look only at the crew certificates which were issued by the jurisdiction state, or which are marked "national" such as CPR cards.

State Custom Data Elements

Some states require PCRs to implement custom data-fields (eCustom/eCustomResult) to capture their specific requirements not present in the NEMSIS spec. AngelTrack LLC will deliver such functionality as may be required by your state; however there may be a substantial delay for the implementation, if they have not already been implemented on behalf of another customer in your state.

Custom ICD-10 codes for patient impressions, acute symptoms, and origin location types

In the PCR, AngelTrack offers the attending a set of drop-down lists of ICD-10 codes that are typical for EMS encounters. These lists come from the NEMSIS standard -- the recommended lists of impression codes, acute symptom codes, and origin location type codes that all PCR software should offer.

A few states have irregular requirements for which impression codes, acute symptom codes, and/or origin location type codes which may and may not be selected by the attending. To accomodate this requirement, AngelTrack allows you (captains, HR, and administrators) to modify AngelTrack's lists of these codes.

The user interface to view and alter the list is located in the Impression List, Acute Symptom List, and Origin Type List items under Settings. You can retire and unretire codes, or add new ones, at any time. Backwards-compatibility of older PCR assessments is automatically preserved.

AngelTrack Custom Data Elements

AngelTrack's NEMSIS exports include custom datafields that are specific to AngelTrack. Here follows the specification for how the data will be rendered in XML.

Fields which are always included

The following AngelTrack fields are always exported if they contain any data:

  • Billable service HCPCS code or pseudo-code
  • Dispatcher notes
  • Preauth notes
  • Billing notes
  • Patient notes (note: these come from the patient record, not from the particular dispatch)
  • Price quote (if any)
  • Zone
  • Tags
  • Provider's timezone offset (in minutes)

The NEMSIS XML definition, appearing at the top of any NEMSIS XML export from AngelTrack, for these fields is:

<EMSDataSet>
    <Header>
        <eCustomConfiguration>
            <eCustomConfiguration.CustomGroup CustomElementID="ATBillableServiceCode">
                <eCustomConfiguration.01>AngelTrack billable service code</eCustomConfiguration.01>
                <eCustomConfiguration.02>Billable service HCPCS code or pseudo-code</eCustomConfiguration.02>
                <eCustomConfiguration.03>9902009</eCustomConfiguration.03> <!-- data type: text -->
                <eCustomConfiguration.04>9923001</eCustomConfiguration.04> <!-- recurrence: no -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
            </eCustomConfiguration.CustomGroup>
            <eCustomConfiguration.CustomGroup CustomElementID="ATDispatcherNotes">
                <eCustomConfiguration.01>AngelTrack dispatcher notes</eCustomConfiguration.01>
                <eCustomConfiguration.02>Dispatcher notes</eCustomConfiguration.02>
                <eCustomConfiguration.03>9902009</eCustomConfiguration.03> <!-- data type: text -->
                <eCustomConfiguration.04>9923001</eCustomConfiguration.04> <!-- recurrence: no -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
            </eCustomConfiguration.CustomGroup>
            <eCustomConfiguration.CustomGroup CustomElementID="ATPreauthNotes">
                <eCustomConfiguration.01>AngelTrack preauth notes</eCustomConfiguration.01>
                <eCustomConfiguration.02>Preauth notes</eCustomConfiguration.02>
                <eCustomConfiguration.03>9902009</eCustomConfiguration.03> <!-- data type: text -->
                <eCustomConfiguration.04>9923001</eCustomConfiguration.04> <!-- recurrence: no -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
            </eCustomConfiguration.CustomGroup>
            <eCustomConfiguration.CustomGroup CustomElementID="ATBillingNotes">
                <eCustomConfiguration.01>AngelTrack billing notes</eCustomConfiguration.01>
                <eCustomConfiguration.02>Billing notes</eCustomConfiguration.02>
                <eCustomConfiguration.03>9902009</eCustomConfiguration.03> <!-- data type: text -->
                <eCustomConfiguration.04>9923001</eCustomConfiguration.04> <!-- recurrence: no -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
            </eCustomConfiguration.CustomGroup>
            <eCustomConfiguration.CustomGroup CustomElementID="ATPatientNotes">
                <eCustomConfiguration.01>AngelTrack patient notes</eCustomConfiguration.01>
                <eCustomConfiguration.02>Patient notes</eCustomConfiguration.02>
                <eCustomConfiguration.03>9902009</eCustomConfiguration.03> <!-- data type: text -->
                <eCustomConfiguration.04>9923001</eCustomConfiguration.04> <!-- recurrence: no -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
            </eCustomConfiguration.CustomGroup>
            <eCustomConfiguration.CustomGroup CustomElementID="ATZone">
                <eCustomConfiguration.01>AngelTrack zone name</eCustomConfiguration.01>
                <eCustomConfiguration.02>Zone</eCustomConfiguration.02>
                <eCustomConfiguration.03>9902009</eCustomConfiguration.03> <!-- data type: text -->
                <eCustomConfiguration.04>9923001</eCustomConfiguration.04> <!-- recurrence: no -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
            </eCustomConfiguration.CustomGroup>
            <eCustomConfiguration.CustomGroup CustomElementID="ATTag">
                <eCustomConfiguration.01>AngelTrack tag</eCustomConfiguration.01>
                <eCustomConfiguration.02>Tag</eCustomConfiguration.02>
                <eCustomConfiguration.03>9902009</eCustomConfiguration.03> <!-- data type: text -->
                <eCustomConfiguration.04>9923003</eCustomConfiguration.04> <!-- recurrence: yes -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
            </eCustomConfiguration.CustomGroup>
            <eCustomConfiguration.CustomGroup CustomElementID="ATTimezoneOffsetMinutes">
                <eCustomConfiguration.01>AngelTrack timezone offset minutes</eCustomConfiguration.01>
                <eCustomConfiguration.02>Offset minutes</eCustomConfiguration.02>
                <eCustomConfiguration.03>9902005</eCustomConfiguration.03> <!-- data type: integer -->
                <eCustomConfiguration.04>9923001</eCustomConfiguration.04> <!-- recurrence: no -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
            </eCustomConfiguration.CustomGroup>
           <eCustomConfiguration.CustomGroup CustomElementID="ATPriceQuote">
               <eCustomConfiguration.01>AngelTrack price quote</eCustomConfiguration.01>
               <eCustomConfiguration.02>Price quote</eCustomConfiguration.02>
               <eCustomConfiguration.03>9902005</eCustomConfiguration.03> <!-- data type: integer/number -->
                <eCustomConfiguration.04>9923001</eCustomConfiguration.04> <!-- recurrence: no -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
          </eCustomConfiguration.CustomGroup>
<eCustomConfiguration.CustomGroup CustomElementID="ATCustomDefinition12345">
               <eCustomConfiguration.01>AngelTrack custom PCR field 12345</eCustomConfiguration.01>
                <eCustomConfiguration.02>[Name of field]</eCustomConfiguration.02>
                <eCustomConfiguration.03>9902003, 9902005, 9902009, or 9902011</eCustomConfiguration.03> <!-- data type: varies -->
                <eCustomConfiguration.04>9923001</eCustomConfiguration.04> <!-- recurrence: no -->
                <eCustomConfiguration.05>9903007</eCustomConfiguration.05> <!-- usage: optional -->
            </eCustomConfiguration.CustomGroup>
        </eCustomConfiguration>
    </Header>
</EMSDataSet>

 

The lattermost field definition above is an example of how a custom PCR field will appear. There can be multiple custom PCR fields.

Here is a sample of the actual data, appearing near the bottom of a NEMSIS XML export:

<EMSDataSet>
    <Header>
        <PatientCareReport>
            <eCustomResults>
                <eCustomResults.ResultsGroup>
                    <eCustomResults.01>A0428</eCustomResults.01>
                    <eCustomResults.02>ATBillableServiceCode</eCustomResults.02>
                </eCustomResults.ResultsGroup>
                <eCustomResults.ResultsGroup>
                    <eCustomResults.01>One-way transport only. Patient insurance is pending; facility agreed to accept the bill.</eCustomResults.01>
                    <eCustomResults.02>ATDispatcherNotes</eCustomResults.02>
                </eCustomResults.ResultsGroup>
                <eCustomResults.ResultsGroup>
                    <eCustomResults.01>Facility was reminded to file PAN on 2017-09-01, no response received.</eCustomResults.01>
                    <eCustomResults.02>ATPreauthNotes</eCustomResults.02>
                </eCustomResults.ResultsGroup>
                <eCustomResults.ResultsGroup>
                    <eCustomResults.01>Non-Covered Destination form signed by Sarah Connor</eCustomResults.01>
                    <eCustomResults.02>ATBillingNotes</eCustomResults.02>
                </eCustomResults.ResultsGroup>
                <eCustomResults.ResultsGroup>
                    <eCustomResults.01>MC part B coverage verified 2017-08-16</eCustomResults.01>
                    <eCustomResults.02>ATPatientNotes</eCustomResults.02>
                </eCustomResults.ResultsGroup>
                <eCustomResults.ResultsGroup>
                    <eCustomResults.01>Global</eCustomResults.01>
                    <eCustomResults.02>ATZone</eCustomResults.02>
                </eCustomResults.ResultsGroup>
                <eCustomResults.ResultsGroup>
                    <eCustomResults.01>Logisticare</eCustomResults.01>
                    <eCustomResults.02>ATTag</eCustomResults.02>
                </eCustomResults.ResultsGroup>
                <eCustomResults.ResultsGroup>
                    <eCustomResults.01>-300</eCustomResults.01>
                    <eCustomResults.02>ATTimezoneOffsetMinutes</eCustomResults.02>
                </eCustomResults.ResultsGroup>
                <eCustomResults.ResultsGroup>
                   <eCustomResults.01>450.00</eCustomResults.01>
                   <eCustomResults.02>ATPriceQuote</eCustomResults.02>
                </eCustomResults.ResultsGroup>
               <eCustomResults.ResultsGroup>
                    <eCustomResults.01>Refused</eCustomResults.01>
                    <eCustomResults.02>ATCustomDefinition12345</eCustomResults.02>
                </eCustomResults.ResultsGroup>
            <eCustomResults>
        </PatientCareReport>
    </Header>
</EMSDataSet>

Base64 warning

Sometimes users will cut-and-paste content from other web pages (e.g. insurance carrier eligibility checks) into AngelTrack's billing- or preauth-notes fields, or even the dispatcher notes field. If such content includes non-printable characters, then AngelTrack must base64 encode the data when emitting it as eCustomResults nodes.

Custom PCR fields

If there are any custom PCR fields defined in the system, and if any marked ☑ This field is reportable to the state, they too will be included in the NEMSIS XML export, following the 'ATCustomDefinition12345' example in the XML shown above. However, it is extremely unlikely that your state will be able to make use of them, since your state will not be anticipating their inclusion.

Upload of Attached Documents

NEMSIS uploads can include attached documents. State trauma registries vary in their demands for attached documents, so AngelTrack has four choices (in Preferences under Settings) for including them in your NEMSIS uploads:

  • ☑ Do not include any documents means that no documents -- be they directly attached or indirectly applied -- will be included in the upload. This setting is intended for use when your state a) does not care about attached documents, and b) has problems accepting the large uploads that result from the inclusion of documents.
  • ☑ Include all documents attached to the dispatch means that only documents directly attached to the dispatch record will be included. Typically, this includes face sheets, fresh PMHx and medication lists, and one-shot PCS forms. This is the default setting.
  • ☑ Include all documents attached to the dispatch or to its paired dispatch is the same as above but also includes any documents directly attached to the paired dispatch, meaning: every uploaded dispatch will include its documents plus those attached to any return trip.
  • ☑ Include all applicable documents within the document persistence window means that all documents that are applicable to a dispatch will be included, going back up to 60 days (or however long you've configured your document persistence window). Because a single document can span many dispatches, that single document will get uploaded repeatedly, once for each relevant run. Do not select this setting unless you are certain that your state trauma registry wishes it.

The default setting will include only those documents that were directly attached to the dispatch by the crew.

Check with your state trauma registry to verify that they do, or do not, wish to receive attached documents. Some states do not want them, as they are large and burdensome to process on the receiving end.

Manual Validation Using the NEMSIS XML Workbench

If you wish to experiment with the NEMSIS validation process, you can do so using the NEMSIS XML Workbench, available under Billing Home. It permits you to exercise step 1 and step 2 of the aforementioned process, and view the results, for any dispatch you choose.

The workbench will load any dispatch ID you specify, including dispatches that were cancelled or that did not include a patient transport. These dispatches may fail to validate on account of missing data, but they are not reportable.

The workbench can also load your NEMSIS demographic submission, which is the data package uploaded to your state's trauma registry in order to describe your agency's capabilities. The workbench can load the demographic data, validate it against the XSDs and/or the schematrons, and display the results.

Using the State Upload Queue

As AngelTrack validates reportable dispatches, they are sorted into the two lists of the State Upload Queue: the pass list and the fail list.

When you visit the State Upload Queue, if there are any dispatches in the fail list, they will be shown in the respective grid. From there you can open the PCR or the Dispatch Edit page to make the necessary corrections.

Someone at headquarters or in your billing office must be responsible for handling any items in the fail list; AngelTrack cannot correct them on its own.

Why dispatches sometimes end up in the fail list

As shown above, validation occurs when the crew attempts to send their report to QA, and occurs again when QA attempts to send the report onward to the Billing office. Once at the Billing office, the dispatch has been validated twice, and is ready for upload to the state trauma registry. So how can a dispatch end up in the "failed to validate" list?

The answer is: because of changes made to the run ticket and/or PCR data by the biller. Billers have authority to make such changes as are necessary to make the report suitable for an insurance claim. Standard protocol is they should send the report back to the crew or QA with a list of requested changes but sometimes they make a judgement call, and make some edits (very often after talking with the crew). When they do this, there is some small chance that the change will result in a validation error later, when AngelTrack performs the 3rd validation immediately before upload to the state.

Billers also have authority to jump a dispatch over QA even though it still fails NEMSIS validation. It will then end up in the fail list, waiting to be fixed so that it can be uploaded.

Validation error messages are cryptic and terrible

When a dispatch fails validation, the validation error messages are stored for display in the fail list. By reviewing the error messages, you can identify the problem and correct it.

Unfortunately, the validation error messages are usually cryptic, sometimes hopelessly obtuse. This is because the error messages are software-generated, using computer validation scripts provided by third parties (the NEMSIS org and sometimes also your state health department). AngelTrack does not control these validation scripts and so cannot do much to improve the comprehensibility of the error messages they generate.

Here is an example of a typical validation error:

Based on Incident/Patient Disposition, the following should be recorded: Transport Mode from Scene, Final Patient Acuity

There are usually enough hints in there to figure out the problem. Do you see it? There is some data missing from the Followup.

If you encounter a validation error message that you just can't figure out, refer to the AngelTrack NEMSIS Crosswalk. It shows how each NEMSIS datafield maps to AngelTrack fields.

Clearing out the fail list

Any time anyone modifies PCR data, the underlying dispatch will be automatically re-validated. At that time, if the validation is successful, it will automatically move from the fail list to the ready list. No user intervention is required.

You can also force an immediate re-validation by clicking the "Revalidate" button in the rightmost column of the fail list. AngelTrack will revalidate the call, which can take a minute or so. At that time the call will return to either the fail list or the ready list.

Manually uploading to the state

If your state's trauma registry does not yet have a webservice available to receive automatic uploads, then you must upload them manually.

The State Upload Queue has a bulk exporter that can package up batches of validated calls for transmission to your state trauma registry. It can batch up to 100 items at a time, as a single enormous .XML file ready for upload.

While it is technically possible to include more than 100 calls in the .XML file, many state trauma registries are not able to process a file larger than that, or will timeout during the transmission process.

The checkbox ☑ Always include PHI data allows you to command AngelTrack's NEMSIS exporter to always include PHI data in the export. Normally, exports from the State Upload Queue page will omit PHI data for states like PA and NY, which forbid the upload of PHI data.

Automatic Upload to Your State

If your state has a webservice available to receive NEMSIS uploads, then AngelTrack can perform all of your uploads for you, automatically. Your state must publish a WSDL file (pronounced "whiz-dull") that describes its webservice, in order for AngelTrack to make use of it. Your state must also issue you a name and password, used to access the webservice.

Visit the State Upload Status page under Settings and check the receivers list. If you see your state in the list, then your state has a webservice available and AngelTrack knows how to utilize it. Activate the entry, click "Edit" to input your username and password, and then save. AngelTrack will then begin automatic uploads to it.

In order to minimize the impact on your AngelTrack cloud server and on the state's webservice, uploads are performed one dispatch at a time, once per minute, all day and all night... as long as there any pending uploads.

Automatic re-upload after data change

Per the NEMSIS specification, AngelTrack will automatically re-validate and re-upload any run report whose PCR or dispatch data is changed.

Forcing a re-upload

To force an individual dispatch to be re-uploaded, simply visit its Followup page, scroll to the bottom, and hit the "Save" button without making any actual changes. Then return to Dispatch Edit, switch to the "Billing" tab, and see that the "Trauma registry" status shows AngelTrack re-validating and re-uploading the call.

To force a range of dispatches to be re-uploaded, visit the State Upload Status page under Settings and use the "Bulk Operations" panel.

City- and county-level credentials

If you must report data to specific cities or counties, AngelTrack can do it automatically.

Each credential in the list can be city-level, county-level, or state-level. Whenever a dispatch is ready for upload, AngelTrack first checks to see if there is an active city-level credential that covers the dispatch's origin address. If none is found, then it checks for an active county-level credential. If still no match, then AngelTrack looks for an active state-level credential instead.

In this manner, you can upload to specific city and county registries where applicable, while uploading everything else to your state registry.

All-states credentials

If there are any all-states entries in the receivers list, those can be activated as necessary. However, if an all-states entry is active, then no other entries can be active, because there can be only one receiver for each dispatch in the system.

By default there are two all-states entries in the list, both of which refer to the NEMSIS national upload site. Those entries can be selected for testing purposes, or if your state trauma registry specifically orders you to do so.

Creating new credentials

If your trauma registry is not already in the built-in list, but it uses ImageTrend / ImageTrend Elite in the normal way, then AngelTrack already knows how to upload to it.

Simply click the Add-Sep-20-2022-07-10-28-53-PM icon to add a new trauma registry. The web-service type will be "ImageTrendStandard"; you might need to change this if your state uses trauma registry software other than ImageTrend. Then carefully input the upload URL that your trauma registry gave you -- not the URL to the WSDL -- as well as the jurisdiction city or county if not reporting statewide. Also specify your username, password, token if any, and any ID number overrides.

Immediate upload before QA review

Normally, AngelTrack uploads a run report after it has completed QA review including any rounds of corrections.

A few states want to receive run reports more quickly than this; they wish to receive them before QA review, just as soon as the Attending finishes the report and sends it to QA. They want the reports right away so that hospitals can receive information about arriving patients within an hour of dropoff.

AngelTrack can fulfill this request. Simply visit the Preferences page under Settings and tick the ☑ Send report on submission to QA checkbox under the "NEMSIS uploads" section.

Demographic Uploads aka "DEM"

The NEMSIS specification also requires the upload of "demographic" data, which is a package of data about your EMS company and its capabilities. The content of the demographic package is defined by NEMSIS, and contains approximately the following:

  1. Nearly everything in every tab (except "Online Resources") of the Business Information page under Settings;
  2. The Procedure List, including each procedure's patch requirement and SNOMED code;
  3. The Medication List, including each medication's patch requirement and RxNAV code;
  4. Your Medical Protocol, to indicate which protocol sections are active (authorized) for your crews.
  5. Your Stations List.
  6. Your Vehicles List.
  7. Your Devices List.
  8. Your Employees List, including all details stored for each employee:
    • Name
    • Mailing address
    • Race, gender, date of birth, citizenship
    • Certificates
    • Experience
    • Hiring information
    • Immunizations
    • Education level
    • Languages spoken
  9. Your annual call volume numbers going back two years.
  10. Any row from your Facilities List where the "DEM reportability" field is either:
    • Set to "Always"; or
    • Set to "Auto" and the facility has at least one completed trip (inbound or outbound) in the past year.

Any time you make a change to the Business Information page, and then click "Save", AngelTrack will quickly test your demographic settings against the validation Schematrons installed on your cloud server. The Schematrons verify that you have provided the minimum necessary information and that there are no contradictions. If the validation fails, it will display the reason why.

Automatic demographic uploads

Once you enable automatic NEMSIS uploads to your state trauma registry, the demographic package will be sent too. Per the NEMSIS specification, the demographic package will be sent under the following circumstances:

  1. Prior to uploading the first pending run report, and
  2. After any change to the underlying demographic settings, and
  3. Once every year.

All of that is handled automatically. In the list of trauma registry credentials in the State Upload Status page, you can see the date of each credential's last demographic upload.

Some states do not wish to receive demographic uploads

Some states do not want or allow an automatic upload of your demographic data. Instead, they require you to submit the data in some other way, such as sending in paper forms or filling out online forms.

AngelTrack already knows which states behave this way, and so will not attempt a demographic upload to them. In the state credential list under State Upload Status, these states are marked "[N/A]" under their demographic upload time. (You can change that setting by editing the credential.)

If your state is one of those, then they will not be notified of demographic changes occurring at your agency... including vehicle purchases and retirements, hirings and terminations, new service levels offered, protocol changes, and so forth. AngelTrack can tell you that such changes have occurred (it is displayed on the State Upload Status page under Settings)... but how you notify your state about the changes, and how often you do so, is between you and them. Usually, such states will provide their own web interface for you to input the information by hand.

Data Quality Complaints

Many state trauma registries are purchasing data analytics suites from their gateway vendors, and running analytics on the uploaded data. As a result, you may receive a "data quality complaint" from your state. The complaint typically reads like this:

1. Assessment: Jan 97%, Feb 94%, Mar 96%, Apr 100%, May 100%, Jun 100% , Jul 100%, Aug 100%, Sep 96%
Report Title: Private BLS Assessment, Folder: QA/QI
Deficiencies: None
Concerns: None

2. Situation: Jan 49%, Feb 56%, Mar 54%, Apr 31%, May 8%, Jun 0%, Jul 3%, Aug 6%, Sep 9%
Report Title: Private BLS Situation, Folder: QA/QI
Deficiencies: Destination Code, Medical History, Medication Allergies, and Current Medications.
Concerns: These are critical data elements for continuity of care and all efforts should be taken by your crews to adequately document these fields. No CAP was received for Q2. Compliance to this quality bundle is at a critical level. It has also been identified that you have defaulted Destination Code = Not Recorded. This is also a critical issue.

The categories such as "Assessment", "Situation", and "Times" refer to sections of the NEMSIS upload data format. It is often difficult to understand how these categories relate to pages in AngelTrack; for example, the "Situation" category includes data from the dispatch ticket, from the origin facility record, from the PCR PMHx page, and from the Followup. To see where each NEMSIS datafield comes from in AngelTrack, refer to the AngelTrack NEMSIS Crosswalk.

That said, there are certain very common complaints that are explained just below...

Destination Code / State Facility Code / eScene.10 / eDisposition.02

Any complaints about the following fields:

  • State facility code
  • Origin code / IncidentFacilityCode / eScene.10
  • Destination code / DestinationTransferredToCode / eDisposition.02

...arise due to missing state facility codes.

Most trauma registries publish a list of registered medical facilities in their jurisdiction. Each facility in the list has a state-assigned ID code -- usually just its NPI. When you pick up from or drop off to that facility, the trauma registry expects the facility ID code to be included in the uploaded report.

AngelTrack accomplishes this using its facility records, each of which has a "State Facility Code" field for this purpose. You must therefore constantly update and curate your facility records, not only to eliminate the occasional duplicates, but also to verify that the ID codes are present. You can easily accomplish the latter by Export-2 exporting the list to Microsoft Excel™ or Google Sheets™ and then checking for records which lack columns demanded by trauma registries:

  • Street address
  • City
  • County
  • State
  • ZIP code
  • State facility code

If your state trauma registry publishes its facility list in a standard .CSV format, or in Excel format which can be "Saved As..." a .CSV file, AngelTrack can Add.multiple-Sep-20-2022-07-11-01-00-PM import it in bulk. The importer is smart, matching up existing records and filling in any missing fields. To learn more, read the Importing a List of Facilities Guide.

Medical History (eHistory.08) / Medication Allergies (eHistory.06)

Data quality complaints about any of the following fields:

  • Medical History / MedicalSurgicalHistory / eHistory.08
  • Medication Allergies / MedicationAllergies / eHistory.06

...arise from a complex situation in AngelTrack's PCR user interface.

The problem is: A NEMSIS upload lists the patient's medical history as a series of ICD-10 codes, and the patient's medications and medication allergies each as a series of RxNorm codes. However, EMS crews are not generally expected to look up these codes from the enormous lists of all possible codes.

AngelTrack's PCR offers a compromise. The crew can fill out the three relevant fields using freeform text, which is how other EMS crews and ER personnel can best understand it. The crews (or your backoffice staff) can then optionally look up the matching ICD-10 and RxNorm codes, and add them to the freeform text. The PCR offers some lookup tools which partially automate the process: Simply type in the name of a disease, or the trade name or generic name of a medication, into the "Search" boxes and choose from the popup list of matches.

Here is how the PCR looks before code lookups:

PCR.PMHx.FreeformTextFields.before

And then how it looks after lookups:

PCR.PMHx.FreeformTextFields.after

When it is time to upload the run report to the trauma registry, AngelTrack will automatically scrape any ICD-10 or RxNorm codes from those text fields, and upload the scraped codes to the trauma registry.

It is up to management to decide who is responsible for these intensive lookups. AngelTrack provides the necessary UI for the crews to do it right in the PCR... but identical UI is available in Patient Edit, allowing billers, supervisors, and dispatchers to do it too.

Remember that these datafields are checkpointed. This means their contents will be carried forward into future transports, but not backwards into past transports. To learn more, read the Patient Data Checkpoints Guide.

By the way, notice how the NEMSIS data format imposes an interesting limitation on PMHx records: there is no RxNorm code to express the idea of "allergic to NSAIDs". Instead, the crew must select every single NSAID in the list... or, as a reasonable compromise, express it like this:

Rx153010: Advil and all other NSAIDs

This compromise will satisfy the trauma registry by reporting an RxNorm code ("Rx153010 Advil"), but also preserve the important piece of information ("and all other NSAIDs") for which there is no RxNorm code.

Likewise in the list of the patient's medical history, ICD-10 codes offer no method for expressing the idea of "suspected", or "intermittent", or other statements of time and uncertainty. The same workaround can be used: specify the ICD-10 code desired by the trauma registry, and then add additional freeform text after it.

Time-to-Upload Maximums

Some states require you to have your charts uploaded within a certain maximum time window -- typically 48 hours from report completion, on average.

In order to decrease your average time to upload, you can go to Settings | Preferences, find the Trauma Registry settings, and tell AngelTrack to upload trips upon reaching QA, rather than upon graduating from QA. This will result in frequent re-uploads, as crews make changes to their charts in order to pass QA, but if your state is pressing you for quick uploads then they will not mind this.

To monitor your average time to first upload, use the "Dispatches-Uploads" dataset in the "Dispatches" category in Report Builder. You can also use the built-in report "Trauma Registry - Hours to First Upload", which has got the data already arranged for you.