Version 2 - XML Validation FAQ

Welcome the FAQs section of the NEMSIS website specifically for Software Developers. As the center receives questions from both EMS agencies and software developers, we will try to update this section. If you have any questions, please feel free to contact the NEMSIS Technical Assistance Center. We will try to update this section as often as possible.


XML Validation


Question: About the XML Schema

Q: The NHTSA 2.2.1 schema indicates that certain Date/Time elements in section E05 can be Null.  But my XML doesn’t validate when it contains the following: <E05_12></E05_12>. Why doesn’t this way of specifying an empty data element validate?

A: Because of the way that these elements are defined as “nullable” in the XSD, the proper way for an NHTSA v2.2.1 XML file to send empty data for one of these elements is as follows:  <E05_12 xsi:nil=”true”></E05_12>.

< Go to Top >


Question: About the National Elements

Q: The NHTSA 2.2 Data Dictionary indicates that a number of demographic elements are required National Elements. Why doesn’t my XML validate when I include all of the National demographic elements?

A: Because there are definitions for two NHTSA v2.2.1 XML files that are sent under different circumstances. Not all of the Demographic elements are sent as part of the “EMS Data Set” XML file, even if they are marked as National Elements in the Data Dictionary for the “Demographic Data Set”.  Currently there are eight elements that are part of the header of the each EMS record. As for the remaining Demographic National Elements, the expectation will be States and Territories providing this data once or twice a year.

< Go to Top >


Question: About Achieving Gold Compliance Status

Q: I want to achieve Gold standard compliance, but I don’t know what to send for some data elements in section E21 “Medical Device Data”. What data is needed for this section?

A:  The NEMSIS Technical Assistance Center understands that there are no current medical devices which are equipped to exchange data using the NHTSA Version 2.2.1 XML structure.  Since the implementation of this standard at the medical device level will require additional development time on the part of the medical device manufacturers, NEMSIS Gold Compliance will not require implementation of the E21 (Medical Device Data) section of the NHTSA Version 2.2.1 Dataset. 

< Go to Top >


Question: Why MySQL Is Not Supported

Q: Why is MySQL not being supported anymore?

A: MySQL is an open source program that is inexpensive but is difficult for us to support. We encourage users to use SQL Server 2005 Express Edition. One can download the database engine and management studio free of charge at this URL http://msdn.microsoft.com/vstudio/express/sql/download/

< Go to Top >


Question: About elements E07_18 through E07_31

Q: The XSD and database scripts for E07 appear incorrect...specifically elements E07_18 through E07_31. They are in the table E07_03_0 and should be in the table E07.

A: There is discrepancy that has been found between the database scripts and XSD. The database scripts allow multiple E07_18 through E07_31 data elements to be included in multiple E07_03_0 structures while the XSD only allow one instance. It has been decided to leave the database scripts as they are which means to simply leave these elements out of the XML file.

< Go to Top >


Question: About date and time

Q: How do I express times to the NEMSIS 2.2.1 standard?

A: Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z").
Times are expressed in local time, together with a time zone offset in hours and minutes. –A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. –A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC.

< Go to Top >

Question: About variables with lists (e.g., Procedures)

Q: EMS Procedures (E19_03) is an example of a variable with an incomplete list. We have tried to collapse all documented procedures into the list...but some just do not fit?

A: Several variables contained in the NHTSA 2.2.1 Data Dictionary contain lists considered incomplete. This is an area of concern that will be addressed during the next revision of the data dictionary. Until that time, it is suggested that states and agencies retain their larger lists. When data is exported to the National EMS Database, state-specific values that map to the current lists should be collapsed and others that do not map should be coded as -5.

Go to Top >

Question: About difference between Gold and Silver compliance

Q: What is the difference between Gold and Silver level compliance? Is Silver compliance just the elements marked as "National" in the Data Dictionary?

A: Several Gold level compliance indicates the ability to generate any of the 400+ data elements listed in the NHTSA 2.2.1 standard. A Gold level compliant product would be able to be marketed to any U.S. state or territory. Silver level compliance is not just the data elements marked as "National" in the NEMSIS Data Dictionary. Silver level is meant to allow a product to receive certification based just on elements requested by specific states or territories. These must include the 68 required "National" elements, but
would typically include many more based on state/territory requirements.

Go to Top >

Question: About when to submit sample XML for compliance testing

Q: How soon should I be submitting the required sample XML files for complaince testing?

A: The earlier the better. These sample XML files are evaluated to determine your readiness to undergo the formal testing. Sending these sample files is your opportunity to receive feedback on how to improve your product. In addition, any major issues uncovered in either XML structure or data content must be corrected before you can participate in the formal tests. So the earlier the files are submitted, the more time you allow yourself to make corrections to be included in a particular testing cycle.

Go to Top >

Question: About "Allows Multiples"

Q: Why does the Data Dictionary identify some elements as "Allows Multiples", and yet the demographic elements in the Header of the EMSDataSet only allows for one value instead of multiple values?

A: Certain data elements appear in both the Demographic Data Set and the EMS Data Set. The NEMSIS schema (XSD) dictates whether a data element "allows multiples". These elements that appear in both data sets can allow multiples in the Demographic Data Set but not in the EMS Data Set. For example, the Demographic XML file would specify all of the Counties where an EMS Agency provides service, but the EMS XML file would only identify a single County where specific EMS incident(s) have occurred.

Go to Top >

Question: Why does NHTSA 2.2.1 and NTDS share common XSDs

Q: I have heard that the NHTSA 2.2.1 database shares common XSDs with the National Trauma Data Standard (NTDS). Why is this?

A: The National Trauma Data Standard (NTDS) data dictionary contains a number of variables that are to be obtained from the pre-hospital record. The programming language that defines variables in NTDS and NHTSA 2.1.1 were designed to exactly match. This was done so that "next generation" trauma registry software and pre-hospital software could exchange data. Thus, in the future, trauma registrars may open a new record on a patient, only to find that all of the pre-hospital variables have "auto-populated" the record. Similarly, when an abstractor finishes a trauma registry record, ED and hospital outcome data could "back-populate" the EMS record, allowing EMS to evaluate QA topics for transported patients. For a detailed description of the overlap between the two data bases, click on this link. In the linked document, green variables demonstrate direct XML and XSD compatability when moving from NEMSIS to NTDS.  Yellow indicates variables in NEMSIS that could “inform” trauma registry abstractors, but no direct data transfer is possible (i.e., there is non-matching XML and XSDs)

Go to Top >

Question: What is meant by "Active" and "Inactive" for several demographic varibales?

Q: What do you mean by an "Active" or "Inactive" for agency [D01] and what does the date refer to?

A: In answering your question, let me begin my pulling some information from the description of the NEMSIS scheme: "Attribute group used to define the current status of an element value and the date the status was confirmed."

In other words, the Status indicates whether the value for the data element is "Active" or "Inactive". I get this question a lot, and I always tell the software vendors that we expect that the data values that they are sending are "Active" so they should always indicate "Status='A' ".

Actually I find the Date to be the more confusing of the two. I guess that if you have, for example, population data from the 2000 census, then the Date should indicate the date on which that census data was "confirmed".

My recommendation to the software vendors has been that if the value is the most current that is available, then it is acceptable to set the Date to the date on which the XML file is being generated. This approach can then be applied to every data element that requires the Date attribute.

<Go to Top >

Question: Is there a separate CPT coding system for pre-hospital, and if so, do you know how I can get a copy?

Q: According to the NEMSIS data dictionary, the standard Procedure codes (D04_04) were generated using the CPT code list. In looking at a CPT coding manual, I was unable to find codes that matched those listed in the dictionary. Is there a separate CPT coding system for pre-hospital, and if so, do you know how I can get a copy?

A: There is no separate CPT code list for pre-hospital, but the NEMSIS version 2.2.1 schema (XSD) was defined with a fixed list of codes that are typically used for pre-hospital. Most likely for the version 3 data set we will allow any CPT code, but at the moment to pass XML validation the code must be from the fixed list in the XSD. And as far as I know these codes are in any CPT coding manual. Adding state-specific procedure codes beyond those in the NEMSIS XSD means that the XML data will not pass validation against our schema. If any state is requiring that then they will probably need a custom schema for the state and then map the additional procedure codes back to the NEMSIS list before they send XML data to the NEMSIS national data base.

<Go to Top >