AngelTrack has a technology called the Contextualizer that helps you figure out how to resolve a state data validation error message.
National, State, and County Validation Rules
Every EMS call is subject to a national set of data validation rules, published by the NEMSIS TAC. AngelTrack has these rules onboard.
Every EMS call is also subject to your state's data validation rules, which they publish in a national repository. AngelTrack has a copy of them onboard, and keeps them automatically updated for you.
Some EMS calls may also be subject to your county's data validation rules, if they publish any. Not many counties do. If yours does, you must notify AngelTrack LLC, and we will retrieve and install them for you.
Every fire call is subject to a national set of data validation rules, published by FEMA, consisting of 184 "relational edits", 19 "incident module rules" and a couple dozen "star rules" representing the "required field" stars seen on paper NFIRS forms. AngelTrack has all these rules onboard.
Data Validation Points
When you submit your report to QA, AngelTrack applies all applicable rules to the data. If any rules throw an error, AngelTrack displays the error message and requires you to fix it before submitting. If any rule throws a warning, Angeltrack displays the warning message and gives you the option to bypass it.
The same thing happens when your QA reviewer passes your report and attempts to send it onward to billing. If any data validation rules fail, either you or your QA reviewer must make the necessary corrects before AngelTrack will allow the report to move forward.
State Data Validation Error Messages are Cryptic and Terrible
AngelTrack LLC does not control the contents of the national, state, and county data validation rules; they are developed and published by third parties. They often contain bugs, typos, and obscure references to the data spec. As a result, the error messages do always make sense. Sometimes you'll have to guess why the rules are complaining.
Furthermore, most of the rules are conditional, meaning that one datafield can determine the acceptable answers allowed in a completely different datafield. For example, if your report indicates that patient transport occurred, then the data validation rules might forbid you from answering "Not applicable" in the datafield that documents whether you drove with lights and sirens... because if you did perform a transport, then it must be possible for you to say whether or not you ran lights and sirens.
In that situation, the data validation error message shown to you might say:
"Based on Incident/Patient Disposition, Transport Mode from Scene (eDisposition.17) is a required field."
That error message is trying to explain that your answer to the datafield named "Incident/Patient Disposition" means you must provide a real answer in the datafield named "Transport Mode from Scene".
The strange word "eDisposition.17" is the internal technical name of the datafield which stores your answer to the question of lights and sirens. There are many such internal names: eResponse.05, eDispatch.02, eCrew.01, eVitals.33, and so on.
How the Contextualizer Can Help
To assist you in understanding these state data validation error messages, AngelTrack has a feature called the Contextualizer. It analyzes each error message, attempting to identify all datafields that are contributing to the issue. Whenever it identifies a contributing datafield, it adds a link you can click, which will take you straight to the PCR field in question.
Here is how it works:
Step 1. You finish your report, and click the "Submit to QA" button. AngelTrack performs a data validation, applying all national, state, and county rules that have jurisdiction over your report.
Step 2. If any rule throws an error or a warning, it appears on the screen for your review. If the rule implicates any datafields in the failure, AngelTrack will turn them into clickable links, like this:
Step 3: Clicking any of those links will take you straight to the datafield in question, which AngelTrack will momentarily highlight in yellow, like this:
Step 4: For data validation rules that indicate a conflict between two different datafields, such as:
"Based on your answer to datafield X, your answer to datafield Y is unacceptable."
...you must decide which datafield to fix. For example, if the patient's DOB is wrong, then you might be asked to provide an APGAR score, but the APGAR datafield is not the problem; the problem is the DOB datafield.
Likewise, a great many data validation rules depend on your answers to the Disposition fields group in the Followup. So, before you go digging into a bunch of weird validation errors, first make sure that your Disposition fields are correct. AngelTrack auto-sets them for you by monitoring your progress and record-keeping during the call, but this is not foolproof and so the automatic Disposition field settings could cause data validation errors later.
Limitations
The Contextualizer depends on your state to provide well-formed data validation rules, which include the necessary diagnostic data in the related-elements and missing-elements nodes. Not all states do this perfectly, and so the Contextualizer will sometimes not be able to offer you any links to the implicated fields.
Also, a few datafields come from data provided by the dispatcher, rather than from the PCR... including the origin address, the destination address, and any relevant facility codes. If you have 'Dispatcher' access in AngelTrack then you will be able to follow the link and make the necessary corrections to these datafields in the run ticket; otherwise, the link will give you an access-denied message, and you must ask your dispatcher to make the correction for you.