NEMSIS Data Submission and PHI Exposure — What Your Vendor Sends and Why You Should Verify It

Most EMS agencies have no idea what their ePCR vendor actually transmits to the state when they hit submit.

The NEMSIS upload runs in the background. The vendor manages it. The agency trusts that it is built correctly and sends only what is required. That trust is usually misplaced. Vendors operate on a different risk model than the agency does, because their liability is limited by contract while the agency's liability runs straight through to OCR.

This article covers the NEMSIS V3 schema, what state offices and CMS see in the payload, the re-identification risk in narrative fields, and how to validate your vendor's NEMSIS payload before it leaves your control.

NEMSIS V3 Schema PHI Exposure Risks

The NEMSIS V3 schema is an XML-based data standard with several hundred data elements organized into patient demographics, clinical findings, and treatment records. The schema collects granular information for good reason, but that granularity means it collects a lot of data.

When your agency transmits a patient record to the state EMS office, the payload generally includes full PHI. Patient name, date of birth, address, and Social Security number in some state configurations. Provider identifiers and response timestamps get transmitted too. The state needs this information for regulatory auditing and clinical quality improvement programs, which is why it travels in the clear.

At the federal level, the NEMSIS Technical Assistance Center creates public-release research datasets that get de-identified downstream. But the transmission from your agency to the state office does not operate under that assumption. The data that leaves your agency is fully identified.

This is the exposure model most agencies never account for. They think about the ePCR database sitting on a server. They do not think about the XML payload traveling from the vendor's cloud to the state's data warehouse. That payload is a full patient record in transit.

Re-identification Risk in EMS Patient Narratives

The discrete fields in the NEMSIS schema are strictly defined. Patient age maps to an age field and gender maps to a gender field, which makes these values easy to mask or aggregate. The narrative field does not have that protection.

The narrative is free text. Providers type whatever they need to document the call, and a good narrative is specific. That specificity creates the re-identification risk.

Typical narratives include house numbers and street names, landmarks visible from the scene, names of family members present, and details about rare medical conditions that identify a specific person when combined with a geographic area.

Now imagine that narrative field gets transmitted inside a NEMSIS payload that has been de-identified at the discrete field level. The name and DOB are stripped, but the narrative still says "Patient found in the blue house behind the old mill on Route 9." Anyone who knows the area can identify that patient.

A provider who writes a thorough narrative is doing their clinical job correctly. But that same thoroughness becomes an exposure risk when the narrative travels outside your control. The discrete field protections do not apply to free text. A patient note with a home address buried in paragraph two bypasses the structural controls the schema provides.

State EMS offices are covered entities, so the transmission to them is permitted under HIPAA. But the data flows into larger databases for research and quality reporting, and every hop adds new surfaces where that unmasked narrative becomes visible.

How to Audit Your ePCR Vendor's NEMSIS Data Submission

Most agencies treat the NEMSIS upload as a vendor-managed black box. That is the risk.

A defensible validation process has four steps.

Step 1: Request a sample XML payload. Ask your vendor for a redacted sample of the actual XML file generated for NEMSIS submission. Look at what fields are being transmitted. Compare them against the official NEMSIS V3 schema requirements for your state. If you see fields being sent that your state does not require, you have a data over-collection problem.

Step 2: Check for ghost fields. Vendors sometimes include extra fields in the payload that they collect internally but do not need to send. These could be internal tracking fields or legacy data maps or fields the vendor added for their own analytics. If those fields contain PHI and they are not required for submission, they are an unnecessary exposure.

Step 3: Review audit logs. Your vendor should provide logs of what was sent and when. Verify that the payload matches the intended submission window. Accidental bulk uploads of incorrect records happen more often than agencies realize.

Step 4: Evaluate narrative scrubbing tools. Some ePCR software includes built-in PHI scrubbers or alerts that warn providers when they enter potentially identifying patterns in the narrative. If your vendor offers this feature, enable it. If they do not offer it, document that gap and plan for remediation.

I covered the broader vendor trust question in The HIPAA Risk Analysis That Holds Up Under OCR Review. The same principle applies here. The agency is the steward of the patient's PHI. The vendor manages the pipeline. If the pipeline leaks, the agency answers for it.

What Data Does CMS Receive From NEMSIS Submissions

State EMS offices receive the full identified record, which includes patient demographics, provider details, clinical data, and the narrative. The state uses this data for regulatory compliance checks and quality improvement analysis.

CMS receives a subset of that data through the NEMSIS aggregation pipeline. The federal datasets get de-identified before public release. But the data that reaches CMS is only as clean as the data that was submitted. If the narrative field contains PHI that was never scrubbed, that PHI entered the federal pipeline.

The CMS risk angle is that the data exists in more places than the agency controls, not that CMS will misuse it. Every database that receives your NEMSIS payload is another attack surface. If a state data warehouse is compromised, the narratives from your agency's calls are in that breach, and your agency will be named in the notification.

Frequently Asked Questions

Does NEMSIS strip PHI before data reaches the federal level?

Public-release research datasets from the NEMSIS TAC are de-identified. The initial transmission from your agency to the state office usually contains full PHI for regulatory purposes. De-identification happens downstream, not at the point of collection.

Why are narrative fields more dangerous than discrete fields for PHI?

Discrete fields like age and gender are easy to mask or aggregate. Narratives are free text. A provider can accidentally include a phone number, a relative's name, or a specific address inside a paragraph. That text bypasses every structured protection the schema provides.

How can I tell if my ePCR vendor is sending more data than necessary?

Request a sample XML export of a typical NEMSIS submission. Compare the fields in that XML against the official NEMSIS V3 schema requirements for your state. If data fields appear in the payload that are not required, you have an exposure risk.

What happens if my agency discovers PHI in narrative fields after submission?

That depends on whether the data was accessed by an unauthorized party. If the narrative was transmitted but not breached, document the gap and remediate it for future submissions. If the data was breached, follow your breach notification procedure.

Who is liable if the vendor sends PHI the agency did not authorize?

The agency carries the regulatory risk. The vendor's BAA limits their contractual liability. OCR looks at the covered entity, not the vendor. If the vendor transmitted a ghost field containing PHI without the agency's knowledge, the agency still answers for it.

Closing

The NEMSIS submission pipeline is not something you can set and forget. The schema is broad and the narrative field is unguarded, and the data travels further than most people track. Request the sample XML and check the narrative scrubbing and document what is actually being sent. Your agency's risk profile depends on knowing what leaves your control.

-- Steven