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.

If you are looking for help with NFIRS uploads to your state fire database, refer to the State Fire Database Uploads Guide.

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. An .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 national datacenter (aka the TAC). Schematrons are sets 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 the Schematron file published by the trauma registry of the jurisdiction state.
4. Validation against any Schematron file published by the jurisdiction county. See below for details.

A 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.

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.

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.

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 is installed in AngelTrack too, imposing additional requirements on your run reports.

If you have any county schematrons for which you must maintain compliance, 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.

To see which schematrons are installed in AngelTrack, goto Settings, click the "NEMSIS Upload Status" item, and then scroll down. Each installed schematron's release date is part of its filename, as well as its NEMSIS version.

Importing or Reimporting Your State's Facility List

Most states maintain a list of hospitals and other prominent healthcare facilities, assigning a unique ID code to each facility. AngelTrack's data uploads to the trauma registry are supposed to include these facility codes where applicable, and where practical. To learn more about state facility codes, have a look at the State Facility Code Guide.

This requirement means your facility list in AngelTrack needs to be fully populated with your state's official list (if any), and your dispatchers must take care to always attach the relevant facility records to dispatches. To learn more about importing your state's facility list, look at the Facility List Import Guide.

If your state doesn't publish a facility list in usable format, then your dispatchers will create facility records on-the-fly, and then you must add the appropriate state facility IDs to them.

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- and County-Level Custom Data Elements

Some states and counties require PCRs to implement custom datafields (eCustom / eCustomResult) to capture their specific requirements not present in the national 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.

Depending on where and how a custom datafield fits into the PCR, AngelTrack LLC may choose to implement it within the PCR's regular UI, or else add it as a PCR Custom Field which will thereafter appear on the "Custom" tab. To learn more, read the Custom PCR Fields for EMS Guide. 

Custom ICD-10 codes for impression, acute symptom, injury cause, and origin location type

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 (eSituation.11 and eSituation.12), acute symptom codes (eSituation.09 and eSituation.10), injury cause codes (eInjury.01), and/or origin location type codes (eScene.09) which are available in the PCR. To accommodate this requirement, AngelTrack allows you (captains, HR, and administrators) to modify AngelTrack's lists of these codes.

The user interface to view and alter these lists is located 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, containing useful extra information that doesn't fit in the NEMSIS spec -- things like the price quote, caller name, time zone, billing notes, and so forth.

If you are importing AngelTrack's NEMSIS exports into a billing platform, you can benefit from this extra data. To learn more about this, refer to the Custom Fields in NEMSIS Data Guide.

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.

Automatic Upload to Your State

AngelTrack can perform all of your state uploads for you, automatically.

Visit the State Upload Status page under Settings and check the credentials 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.

Configuring your upload credential

Your trauma registry will tell you how to configure AngelTrack for upload to them. They will give you the following pieces of information:

• Upload URL
• Desired NEMSIS version (v3.4.0 or v3.5.0) and cutover date if any
• Username
• Password
• State license number ("dAgency.01")
• State agency number ("dAgency.02"), may differ from the state license number
• Whether they want to also receive "DEM" (demographics) uploads
• Token (usually optional)

Input all of this information into the upload credential in AngelTrack.  For a detailed walkthrough, please visit the State Upload Credential Input Guide.

As for the NEMSIS data version, most states are now on v3.5.0. If you know your state's cutover date, you can input it with the credential, so that AngelTrack will know when to switch to v3.5.0. If you set the data version to "Auto", then AngelTrack will switch to v3.5.0 just as soon as your state publishes their v3.5.0 schematron.

If you must upload data to more than one trauma registry, they might each ask for different values in the dAgency.01 and dAgency.02 fields, because they have each assigned you a provider ID unique to their own system. AngelTrack handles this situation via its "Overrides" fields, where each upload credential can specify a different dAgency.01 and dAgency.02 than your systemwide settings. See the section below on dAgency.01 / dAgency.02 for details.

Diagnosing an error -3 "Permission denied to this EMS organization"

If AngelTrack's state uploader issues this error code, then contact the trauma registry and double-check that all credential fields in AngelTrack match their expectations. See above for the list of credential fields that must match exactly.

If everything is correct but you still get a -3 permission error, and if the trauma registry is ImageTrend, then you may be seeing a side-effect of a missing DEM permission. Some states do not allow providers to submit DEM data, which is fine, but inside ImageTrend an EMS upload can sometimes issue a supplemental DEM update. (We conjecture that ImageTrend is copying some data from the EMS submission in order to flesh out the DEM data already on file for the provider.) If the provider's account in ImageTrend is marked "no DEM updates allowed", then this supplemental DEM update will fail with a permission error, causing the entire EMS upload to fail with error -3.

To work around this problem, the state must temporarily mark the provider's account as "allow DEM update". Then wait for AngelTrack to successfully upload at least one EMS record. Afterward the state can revoke the permission again.

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 gets changed, after a ten-minute delay while AngelTrack waits to see if the user is going to make any additional changes.

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

AngelTrack's state uploader can upload to multiple authorities, in a cascade:

1. Incident city
2. Incident county
3. Statewide

That is, each credential in the uploader can have a jurisdiction city, or a jurisdiction county, or be a statewide credential. To decide where each report should be uploaded, AngelTrack checks for a city match, and if not found then a county match, and if not found then a statewide credential.

For example, suppose you have a credential for the city of Dallas and another for the city of Fort Worth, plus a credential for Tarrant County, and finally a statewide credential. AngelTrack will then decide jurisdiction like this:

1. Check to see if the incident occurred within Dallas or Forth Worth, and if so, upload it using those credentials.
2. If no match found by city, then check to see if the incident occurred within Tarrant County, and if so, upload it using that credential.
3. If no match found by city or by county, then upload it using the statewide credential.

In this manner, you can create a cascade of credentials for the different authorities to which you must submit reports.

Each dispatch is only ever reportable to one credential. The automatic uploader does not support reporting one particular dispatch to multiple authorities. If you are in that situation, follow the instructions below for manual uploading.

Note that this restriction does not apply to ET3 uploads, to CAD pushes to ESO, or to progress-report pushes to HealthEMS and to VectorCare. All of those have their own separate uploaders and so run independently of the automatic state uploader.

Creating new credentials

If your trauma registry is not already in the built-in list, but it uses any of the common state registry backends, then AngelTrack already knows how to upload to it.

Simply click the icon to add a new trauma registry. The web-service type will default to "ImageTrendStandard"; 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, NEMSIS data version, and any ID number overrides.

dAgency.01 / State License Number / dAgency.02 / State Agency Number

The dAgency.01 ("State license number") and dAgency.02 ("State agency number") datafields specify your license number and your trauma registry number. These are systemwide fields, configurable via the Business Information page under Settings. Each of your upload credentials will automatically utilize these systemwide fields when performing an upload.

If you must report data to multiple trauma registries, and if any of them asks for different identifiers in dAgency.01 or dAgency.02, then you can configure the upload credential to override the systemwide settings.

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.

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.

Anything in the pass list will be automatically uploaded by AngelTrack, if there is an appropriate upload credential available.

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 totally obtuse. This is because the error messages are software-generated, using computer validation scripts provided by third parties (state health departments).

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.

AngelTrack has a feature called the Contextualizer which will help you figure out how to fix each data validation error. It analyzes the error message, attempting to identify all datafields that are contributing. Whenever it identifies one, it adds a link you can click, which will take you straight to the PCR field in question, which it will highlight, like this:

To learn more about how to fix validation errors with the help of the Contextualizer, take a look at the Contextualizer Guide.

If you encounter a validation error message that you just can't figure out, even after trying all the field links provided by the Contextualizer, then 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's pass list 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 NY, which forbid the upload of certain PHI data.

"Cancellations"

In AngelTrack, dispatchers mark a call as "Cancelled" if it never happened. For example, perhaps transportation was booked in advance, but then the patient changed their mind, and so no crew ever rolled. These cases are not reportable to the state.

Whereas when a state trauma registry or fire databases asks you to report your "cancellations", they are asking for you to send reports for the times when you rolled a crew but then pulled them off while they were still enroute. AngelTrack calls this a "Completed, best effort." In NFIRS this is known as incident type 611.

AngelTrack knows to report these to your state. This behavior is controlled by a Preference Setting named "Send all BLS+ reports", and it is enabled by default.

For all of this to work, dispatchers must know how to handle these dud calls. The dispatch board offers a best-effort icon for this purpose; clicking it will properly close the call as a best-effort, rather than as a cancellation. The crew will then be required to perform some minimal book-keeping -- just enough information to satisfy the state registry for a cancelled-enroute situation.

If your state asks you how many cancellations you've had, use AngelTrack's reports to count up the number of dispatches that are marked "Completed, best effort"; do not count any dispatches that are marked "Cancelled". To learn more, refer to the Call Completion Guide.

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 DEM (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 / Incident Facility Code / eScene.10
• Destination code / Destination Transferred To, Code / 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. To learn more, read the State Facility Code Guide.

To learn how to import your state's facility list into AngelTrack, or to update your facility list with the latest data from your state, take a look at the Facility List Import/Update 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:

And then how it looks after lookups:

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.