Appendix III – Universal Documentation Guideline

Table of Contents

Aliases

NEMSIS, Documentation

Patient Care Goals

  1. Support continuity of patient care and continuous performance improvement (CPI) of patient care through meeting minimum documentation standards for all EMS events where a patient was encountered
  2. This guideline defines minimum standards and inclusions used and referenced throughout this document under the “Quality Improvement” section of each guideline
  3. The National EMS Information System (NEMSIS) submission requirements, state and local EMS systems, and EMS billing reimbursement services will have more extensive minimum requirements that exceed this guideline
  4. This guideline can be used as a starting point for systems looking to more formally define documentation requirements

Patient Presentation

Inclusion Criteria

All EMS events where a patient was encountered and one or more clinical guideline was used to determine patient treatment and/or disposition.

Exclusion Criteria

None

Toolkit for Key Categories of Data Elements

Incident Demographics

  1. Incident Demographics include the type of incident, location, time, dispatch information, response resources and patient/incident disposition of the EMS event
    1. This information will always apply and be available, even if the responding unit never arrives on scene (is cancelled) or never makes patient contact
    2. Incident demographics are important for filtering incident types and outcomes when doing CPI reviews, providing aggregate descriptive data, and billing for reimbursement
  2. Minimum Incident Demographic Fields include:
    1. Incident Times
      1. eTimes.03 – Unit Notified by Dispatch Date/Time (NEMSIS mandatory)
      2. eTimes.05 – Unit En Route Date/Time (Unit responding)
      3. eTimes.06 – Unit Arrived on Scene Date/Time (If arrived)
      4. eTimes.07 – Arrived at Patient Date/Time (If patient contact made)
      5. eTimes.09 – Unit Left Scene Date/Time (Unit Transporting Time, if applicable)
      6. eTimes.11 – Patient Arrived at Destination Date/Time (If applicable)
      7. eTimes.13 – Unit Back in Service Date/Time (NEMSIS mandatory)
    2. eResponse.05 – Type of Service Requested (e.g. 911 vs interfacility)
    3. eResponse.07 – Primary Role of the Unit (e.g. Transport or non-transport)
    4. eDispatch.01 – Complaint Reported by Dispatch (Dispatch reason from EMD)
    5. Crew Responding:
      1. eCrew.01 – Crew Member ID (Crew name or license # depending on software)
      2. eCrew.02 – Crew Member Level (License level for this call)
      3. eCrew.03 – Crew Member Response Role (e.g. Primary or secondary care giver)
    6. eScene.09 – Incident Location Type
      1. Used for multiple purposes, including CARES (Cardiac Arrest Registry to Enhance Survival)
    7. Response Modes (e.g. lights and sirens)
      1. eResponse.23 – Response Mode to Scene
      2. eResponse.24 – Additional Response Mode Descriptors
    8. Delays:
      1. eResponse.09 – Type of Response Delay
      2. eResponse.10 – Type of Scene Delay

Patient Demographics and Medical History

Patient demographics in this section include the minimum information required for CPI review and do not include protected health information (PHI) or patient identifiable information. Local systems may require additional PHI to support EMS reimbursement and link local level CPI reviews to specific incidents or outcome data.

  1. Minimum Patient Demographic and History Fields include:
    1. ePatient.13 – Gender
    2. ePatient.15 – Age
    3. ePatient.16 – Age Units
    4. eHistory.06 – Medication Allergies
    5. eHistory.07 – Environmental/Food Allergies
    6. eHistory.08 – Medical/Surgical History
    7. eHistory.12 – Current Medications
    8. eHistory.17 – Alcohol/Drug Use Indicators
    9. eHistory.01 – Barriers to Patient Care
    10. eExam.01 – Estimated Body Weight in Kilograms
    11. eExam.02 – Length-based Tape Measure

Patient Complaints and Symptoms

  1. Patient and situational history for this EMS event generally addresses issues leading up to EMS being requested and include patient complaints, SAMPLE history, signs or symptoms, barriers and confounders, onset times, and trauma and cardiac arrest historical information
  2. Patient Complaints, Signs and Symptoms, and Key Related Times:
    1. eSituation.02 – Possible Injury
    2. Patient Complaint Group
      1. eSituation.03 – Complaint Type
      2. eSituation.04 – Complaint
      3. eSituation.05 – Duration of Complaint
      4. eSituation.06 – Time Units of Duration of Complaint
    3. eSituation.07 – Chief Complaint Anatomic Location
    4. eSituation.08 – Chief Complaint Organ System
    5. Signs and Symptoms
      1. eSituation.01 – Date/Time of Symptom Onset
      2. eSituation.09 – Primary Symptom [Single Choice]
      3. eSituation.10 – Other Associated Symptoms [Choose All that Apply]
    6. eSituation.18 – Date/Time Last Known Well (Stroke/CVA)

Situational History for this EMS Event

  1. SAMPLE History
    NOTE: Although many assessment guidelines refer to this history mnemonic, many electronic patient care report (ePCR) systems do not collect this information in a tool organized specifically in this group, but rather throughout the EMS record in the appropriate areas to the topics

    1. Symptoms
      1. eSituation.09 – Primary Symptom
        AND
      2. eSituation.10 – Other Associated Symptoms
    2. Allergies
      1. eHistory.06 – Medication Allergies
        AND
      2. eHistory.07 – Environmental/Food Allergies
    3. Medications
      1. eHistory.12 – Current Medications
    4. Past medical and surgical history
      1. eHistory.08 – Medical/Surgical History
    5. Last Oral Intake
      1. eHistory.19 – Last Oral Intake (if software configured to collect)
        and/or
      2. eNarrative.01 – Patient Care Report Narrative
    6. Events leading to activation of EMS
      1. eSituation.17 – Patient Activity
        and/or
      2. eNarrative.01 – Patient Care Report Narrative
  2. Barriers and Situational Confounders
    1. eHistory.01 – Barriers to Patient Care
    2. eHistory.17 – Alcohol/Drug Use Indicators
  3. Stroke
    1. eSituation.18 – Date/Time Last Known Well (Stroke/CVA)
  4. Trauma History and Situation
    1. eSituation.02 – Possible Injury (Yes/No – based on mechanism, not listing an actual injury)
    2. eInjury.01 – Cause of Injury
      1. Known to providers as Mechanism of Injury; values are from ICD-10
      2. Intent is included where possible in ICD-10, but is no longer a separate field as it was in NEMSIS v2
    3. eInjury.03 – Trauma Center Criteria (Combined steps 1 and 2 of CDC’s “Guidelines for Field Triage of Injured Patients”)
    4. eInjury.04 – Vehicular, Pedestrian, or Other Injury Risk Factor (Combined steps 3 and 4 of CDC’s “Guidelines for Field Triage of Injured Patients”)
    5. eInjury.07 – Use of Occupant Safety Equipment
    6. Destination Pre-Arrival Alerts (e.g. trauma alerts)
      1. eDisposition.24 – Destination Team Pre-Arrival Alert or Activation
      2. 25 – Date/Time of Destination Pre-Arrival Alert or Activation
    7. Cardiac Arrest History and Situation
      NOTE: The following fields meet the needs of Utstein Criteria reports and many of the fields in CARES. CARES has additional custom fields that may be available from your software vendor.

      1. eArrest.01 – Cardiac Arrest [Yes/No]
      2. eArrest.02 – Cardiac Arrest Etiology
      3. eArrest.03 – Resuscitation Attempted By EMS
      4. eArrest.04 – Arrest Witnessed By
      5. eArrest.05 – CPR Care Provided Prior to EMS Arrival
      6. eArrest.06 – Who Provided CPR Prior to EMS Arrival
      7. eArrest.07 – AED Use Prior to EMS Arrival
      8. eArrest.08 – Who Used AED Prior to EMS Arrival
      9. eArrest.09 – Type of CPR Provided
      10. eArrest.11 – First Monitored Arrest Rhythm of the Patient
      11. eArrest.12 – Any Return of Spontaneous Circulation
      12. eArrest.14 – Date/Time of Cardiac Arrest
      13. eArrest.15 – Date/Time Resuscitation Discontinued
      14. eArrest.16 – Reason CPR/Resuscitation Discontinued
      15. eArrest.17 – Cardiac Rhythm on Arrival at Destination
      16. eArrest.18 – End of EMS Cardiac Arrest Event
      17. eScene.02 – Other EMS or Public Safety Agencies at Scene
      18. eScene.03 – Other EMS or Public Safety Agency ID Number
      19. eScene.04 – Type of Other Service at Scene

Provider Impressions and Incident/Patient Disposition

  1. Provider Impressions (Provider Field Working Diagnosis)
    1. eSituation.11 – Provider’s Primary Impression [Single Choice]
      1. The word “Primary” causes a great deal of understandable confusion with this field, this should be the diagnosis of the most acute (primary) problem NOT NECESSARILY THE FIRST problem that was wrong with the patient, or their initial complaint
    2. eSituation.12 – Provider’s Secondary Impressions [Choose all that Apply]
  2. Incident/Patient Disposition
    1. eSituation.13 – Initial Patient Acuity (Intended to be prior to EMS care)
    2. eDisposition.19 – Final Patient Acuity (Intended to be after EMS care)
    3. eDisposition.12 – Incident/Patient Disposition
    4. eDisposition.16 – EMS Transport Method
    5. Transport Mode (e.g. use of lights and sirens)
      1. eDisposition.17 – Transport Mode from Scene
      2. eDisposition.18 – Additional Transport Mode Descriptors
    6. eDisposition.01 – Destination/Transferred To, Name
      1. Intended by NEMSIS to be the destination facility or the Agency transferred to, although many ePCR systems only collect this as the destination facility because of the complexity of mixing facilities and services in the same field

 

Assessments and Exams

  1. Exams
    By definition, use of NEMSIS eExam fields is optional; they are, however, available for both state and local EMS system use.

    1. Many systems do not require use of these fields as they can be time-consuming to enter, often too detailed (e.g. there is no value for whole arm, it would need to be entered as shoulder, upper arm, elbow, forearm and wrist with separate exam findings for each component, meaning a single exam finding of paralysis for an arm would take ten steps to enter) and the same information is often reflected in the provider’s narrative.
    2. However, there is some utility in targeted use of these fields for certain situations such as stroke, spinal exams, and trauma without needing to enter all the fields in each record.
  2. Capacity Assessment Group
    1. This can be used to support documentation of patient capacity for refusal of care and/or transport, participation in advanced spinal assessments, or support for treatment decisions by EMS providers. NOTE: The Capacity Assessment Group does not provide a legal definition of capacity and should not be used as such. It is intended only to assist the EMS provider in documenting the most basic exam and history findings in order to determine capacity. Many additional factors must be considered when determining capacity including the situation, patient medical history, medical conditions, and consultation with direct medical oversight.
    2. Barriers and situational confounders [Both only single entry]
      1. eHistory.01 – Barriers to Patient Care
      2. eHistory.17 – Alcohol/Drug Use Indicators
    3. Glasgow Coma Score (GCS) Vitals Group [see Vitals section] [serial entries allowed]
    4. eVitals.26 – Level of Responsiveness (AVPU) [serial entries allowed]
    5. eExam.19 – Mental Status Assessment [serial entries allowed]
    6. eExam.20 – Neurological Assessment [serial entries allowed]
  3. Stroke Assessments
    1. Initial Vitals\
    2. eSituation.18 – Date/Time Last Known Well (Stroke/CVA)
    3. Stroke Score Group
    4. eExam.19 – Mental Status Assessment
    5. eExam.20 – Neurological Assessment (Speech, facial droop, arm drift, unilateral weakness)
    6. eVitals.31 – Reperfusion Checklist (May not apply if service area does not use due to lack of consensus on a standard reperfusion checklist, or acceptance by EMS if used)
  4. Spinal Injury/Exam
    1. Capacity Assessment Group
    2. Back and Spine Assessment Group
      1. eExam.13 – Back and Spine Assessment Finding Location
      2. eExam.14 – Back and Spine Assessment
    3. Extremity Assessment Group
      1. eExam.15 – Extremity Assessment Finding Location
      2. eExam.16 – Extremities Assessment
  5. 12-lead EKG Acquisition
    1. eTimes.06 – Unit Arrived on Scene Date/Time
    2. eTimes.07 – Arrived at Patient Date/Time
    3. EKG Rhythm Group [see Vitals section]
    4. Attach 12-lead graphic ePCR (through direct integration linkage with EKG monitor or attachment of scanned printout as allowed/available in software)
    5. 12-lead-EKG Procedure-documented under Procedures Performed Group
  6. Trauma/Injury
    1. The exam fields have many useful values for documenting trauma (deformity, bleeding, burns, etc.). Use of targeted documentation of injured areas can be helpful, particularly in cases of more serious trauma. Because of the endless possible variations where this could be used, specific fields will not be defined here. Note, however that the exam fields use a specific and useful Pertinent Negative called “Exam Finding Not Present.” This can be used to document that the provider actually performed the assessment, but did not find any injury/abnormality.

Vitals

  1. Vitals Date/Time Group
    1. eVitals.01 – Date/Time Vital Signs Taken
    2. eVitals.02 – Obtained Prior to this Unit’s EMS Care
  2. Glasgow Coma Score (GCS) Group
    1. Vitals Date/Time Group
    2. eVitals.19 – Glasgow Coma Score-Eye
    3. eVitals.20 – Glasgow Coma Score-Verbal
    4. eVitals.21 – Glasgow Coma Score-Motor
    5. eVitals.22 – Glasgow Coma Score-Qualifier
    6. eVitals.23 – Total Glasgow Coma Score
  3. EKG Rhythm Group
    1. Vitals Date/Time Group
    2. eVitals.03 – Cardiac Rhythm/Electrocardiography (EKG)
    3. eVitals.04 – EKG Type
    4. eVitals.05 – Method of EKG Interpretation
  4. Temperature Group
    1. Vitals Date/Time Group
    2. eVitals.24 – Temperature
    3. eVitals.25 – Temperature Method
  5. Pain Scale Group
    1. Vitals Date/Time Group
    2. eVitals.27 – Pain Scale Score
    3. eVitals.28 – Pain Scale Type
  6. Stroke Score Group
    1. Vitals Date/Time Group
    2. eVitals.29 – Stroke Scale Score
    3. eVitals.30 – Stroke Scale Type
  7. Additional Vitals Options
    1. All should have a value in the Vitals Date/Time Group and can be documented individually or as an add-on to basic, standard, or full vitals
    2. eVitals.09 – Mean Arterial Pressure
    3. eVitals.13 – Pulse Rhythm
    4. eVitals.15 – Respiratory Effort
    5. eVitals.16 – End Tidal Carbon Dioxide (ETCO2)
    6. eVitals.17 – Carbon Monoxide (CO)
    7. eVitals.18 – Blood glucose Level
    8. eVitals.26 – Level of Responsiveness (AVPU)
    9. eVitals.32 – APGAR
  8. Routine Vitals – Includes the following vital signs:
    1. Vitals Date/Time Group
    2. Blood Pressure
    3. eVitals.06 – SBP (Systolic Blood Pressure)
    4. eVitals.07 – DBP (Diastolic Blood Pressure)
    5. eVitals.10 – Heart Rate
    6. eVitals.12 – Pulse Oximetry
    7. eVitals.14 – Respiratory Rate
    8. eVitals.26 – Level of Responsiveness (AVPU)
    9. Pain Scale Group
  9. Initial Vitals
    1. Routine Vitals
    2. eVitals.18 – Blood glucose Level
    3. Glasgow Coma Score (GCS) Group
    4. Temperature Group
  10. Full Vitals
    1. Initial Vitals
    2. eVitals.13 – Pulse Rhythm
    3. eVitals.15 – Respiratory Effort
    4. eVitals.16 – End Tidal Carbon Dioxide (ETCO2) (If available and applicable)
    5. EKG Rhythm Group (If available and applicable)

Medications Given

  1. eMedications.01 – Date/Time Medication Administered
  2. eMedications.02 – Medication Administered Prior to this Unit’s EMS Care
  3. eMedications.03 – Medication Given
    1. Pertinent Negatives (medication qualifiers) allowed
      1. Contraindication Noted
      2. Medication Already Taken
      3. Denied By Order
      4. Refused
      5. Medication Allergy
      6. Unable to Complete
  4. eMedications.04 – Medication Administered Route
  5. eMedications.05 – Medication Dosage
  6. eMedications.06 – Medication Dosage Units
  7. eMedications.07 – Response to Medication [see Definitions of Medication Response below]
  8. eMedications.08 – Medication Complication
  9. eMedications.09 – Medication Crew (Healthcare Professionals) ID (Name or license #)
  10. eMedications.10 – Role/Type of Person Administering Medication (License level)

Procedures Performed

  1. eProcedures.01 – Date/Time Procedure Performed
  2. eProcedures.02 – Procedure Performed Prior to this Unit’s EMS Care
  3. eProcedures.03 – Procedure
    1. Pertinent Negatives Allowed
      1. Contraindication Noted
      2. Refused
      3. Denied By Order
      4. Unable to Complete
  4. eProcedures.04 – Size of Procedure Equipment
  5. eProcedures.05 – Number of Procedure Attempts (This should always be “1” with each attempt at a procedure documented separately with appropriate date/time stamp)
  6. eProcedures.06 – Procedure Successful
  7. eProcedures.07 – Procedure Complication
  8. eProcedures.08 – Response to Procedure [see Definitions for Response to Procedures below]
  9. eProcedures.09 – Procedure Crew Members ID
  10. eProcedures.10 – Role/Type of Person Performing the Procedure
  11. eProcedures.13 – Vascular Access Location (If applicable)

Narrative

The use of the narrative is essential to an effective and complete Patient Care Record. It summarizes the incident history and care in a manner that is easily digested between caregivers for continuity of care and provides a place for EMS to document facts that do not fit into fixed data fields [see Narrative section under Notes/Educational Pearls (below) for more detail]

Notes/Educational Pearls

Documenting Signs and Symptoms versus Provider Impressions

  1. Signs and Symptoms
    1. Signs and Symptoms should support the provider impressions, treatment guidelines and overall care given. A symptom is something the patient experiences and tells the provider; it is subjective. A sign is something the provider sees; it is objective.
    2. Symptoms should not be confused with provider impressions. The provider impressions are the EMS working field diagnosis of the patient’s actual medical condition.
  2. Provider Impressions
    1. There is often a great deal of confusion on the part of EMS providers about the difference between symptoms and provider impressions. Provider impressions should be supported by symptoms but not be the symptoms except on rare occasions where they may be the same (e.g. weakness when no etiology for the weakness can be determined by the EMS provider).
    2. Correctly documenting impressions is essential to many aspects of EMS data use, such as EMS reimbursement, reports of incident types, specialty registries (e.g. CARES) and CPI reviews. EMS agencies could literally lose money or equipment and staffing resources if the providers are incorrectly entering provider impressions. Addressing this issue should be an essential part of the record Quality Assurance and CPI process and documentation training.
    3. Example of documenting symptoms versus impressions:
      1. An opiate overdose patient who received naloxone and had a positive response. This patient would have possible Symptoms of altered mental status, unconscious, respiratory distress, and respiratory failure/apnea. All 4 of these symptoms are available as provider impressions, however the correct impression for this patient would be whatever variation of “Drug Overdose Opiates or Heroin” impression(s) are setup in the local ePCR system being used. This impression will specifically define the call as an overdose with opiates, rather than a case where one of the symptoms was also used as an impression when the use of naloxone and other assessments and diagnostic tools could not determine an etiology for the symptom(s).

 

Narrative

The various data fields within the ePCR are important as they provide a means of uniformly entering incident data that can be used for importing into billing software or hospital records, transmitting between EMS systems or creating descriptive reports, or conducting research. In most cases, at a local, state, or national level, if something wasn’t documented in the appropriate data field, it didn’t happen or exist. However, the Narrative plays several essential roles in the PCR.

  1. Role of the Narrative
    1. Provides an efficient and effective means to share patient information for continuity of care between EMS services and EMS and hospital staff. The narrative summarizes the incident history and care in a manner that is easily digested between caregivers.
    2. Provides a place for EMS to document facts that do not fit into fixed data fields. Specifically, this would include the detailed history of the scene, what the patient may have done or said or other aspects of the call that only the provider saw, heard, or did. The Narrative is the place for the EMS provider to “paint the picture” for all others to more fully understand the incident.
    3. Provides a standard means to add essential details about medical history, exams, treatments, patient response, and changes in patient condition that can’t otherwise be effectively or clearly communicated.
  2. Narrative Formats

Documentation by EMS providers demonstrates a wide variation of training and practice reinforcement. Most training programs provide limited instruction on how to properly document operational and clinical processes, and almost no practice. Most providers learn this skill on the job, and often proficient mentors are sparse. Therefore, it is essential that the EMS provider uses a standard format to ensure they are consistent and complete in their documentation. There are three standard formats for EMS documentation. EMS providers should choose the best match for them, master the format, and be consistent in its use.

  1. Medical Narrative: This format is the one most new EMS providers use as it is intuitive and easy to learn. Some more experienced providers use it as they find telling the story from start to finish works best to organize their thoughts. A drawback to this method is that it is easy to forget to include facts because of the lack of structure.
  2. SOAP: This format stands for Subjective, Objective, Assessment, and Plan. This is a format that is very common in the medical field.
  3. CHART: This format stands for Complaint, History, Assessment, Rx (Treatment) and T Each section’s content is clearly defined and consistent in format. It minimizes the likelihood of forgetting information and ensures documentation is consistent between records and providers. CHART is the format most recommended as best practice by EMS legal authorities and is considered the standard in many EMS systems. A variation is DCHART, where the “D” stands for Dispatch (reason).

Medications Given Showing Positive Action Using Pertinent Negatives

For medications that are required by protocol (e.g. aspirin for cardiac chest pain), pertinent negatives should be used to show that a medication protocol was considered but was satisfied by other than provider action.

Example: EMS is called to a patient for cardiac chest pain. The patient has already taken 324 mg of aspirin by the time EMS arrives per 9-1-1 pre-arrival instructions. EMS providers should document this as a medication given, prior-to-arrival, with the best estimated time, and qualify the medication as “Medication Already Taken” using the pertinent negative.

Definitions for Response to Medications

  1. Improved:
    1. The medication had its intended therapeutic effect and the patient’s symptoms decreased or clinical condition improved or resolved (the word “effective” could be generally be substituted for “improved”).
    2. If a patient had the intended therapeutic response to the medication, but a side effect that caused a clinical deterioration in another body system, then “Improved” should be chosen and the side effects documented as a complication (e.g. nitroglycerin improved chest pain but dropped the blood pressure).
  2. Unchanged:
    1. The medication was ineffective and had no intended therapeutic effect or had a sub-therapeutic and unnoticeable effect,
      AND
    2. The patient condition did not deteriorate.
  3. Worse:
    1. The patient condition deteriorated or continued to deteriorate because either the medication:
      1. Was ineffective and had no intended therapeutic effect;
        OR
      2. Had a sub-therapeutic effect that was unable to stop or reverse the decline in patient condition;
        OR
      3. Was the wrong medication for the clinical situation and the therapeutic effect caused the condition to worsen (e.g. giving glucose to a patient with hyperglycemia/diabetic ketoacidosis).

Definitions for Response to Procedures

  1. Not Applicable:
    1. The nature of the procedure has no direct expected clinical response (e.g. patient assessment, 12-lead EKG acquisition).
  2. Improved:
    1. The procedure performed had the intended effective outcome and/or the patient’s symptoms decreased or clinical condition improved or resolved (e.g. defibrillation resolved VF into a perfusing rhythm; intubation controlled the airway and allowed effective management of breathing).
    2. An effective procedure that caused an improvement in the patient condition may also have resulted in a procedure complication and the complication should be documented (e.g. intubation caused minor airway trauma, but the intubation successfully secured the airway).
  3. Unchanged:
    1. The procedure performed did not have the clinical effect intended, but did not directly worsen the patient’s symptoms or clinical condition (e.g. attempted defibrillation and the person remained in VF);
      or
    2. Had a sub-therapeutic effect and the symptoms continued (e.g. a bandage applied to a bleeding wound failed to stop the bleeding);
      or
    3. The nature of the procedure has no direct expected clinical response (e.g. patient assessment).
      1. NOTE: “Not Applicable” would also be appropriate to choose for these cases
  4. Worse:
    1. The results of the procedure performed lead to a worsening of the patient’s symptoms or condition (e.g. defibrillation converted VF into asystole, application of a splint caused significant increase in pain or loss of sensation and pulses).
    2. In the case of worsening condition, documentation of the procedure complications may also be appropriate.
    3. NOTE: Just because a patient got worse, doesn’t necessarily mean the provider performed the procedure incorrectly.

NEMSIS Data Standards and Limitations

  1. NEMSIS is a national dataset and standard used by all EMS software systems. Currently there are three versions of the data standard available for documentation and in which data is stored:
    1. NEMSIS Version 2.2.1 (v2.2.1)
      1. Adopted in 2006, there have been no changes since release
      2. Most states or systems have used this standard since its release, and the majority of most states’ data available since approximately 2016 is in this format.
      3. NEMSIS accepted v2.2.1 data through 12/31/2016, and some states may continue to collect data in this standard until they transition to NEMSIS v3 standards.
    2. NEMSIS Version 3 (v3)
      1. NEMSIS v3 was created and finalized in 2011 to replace v2.2.1 in order to allow the dataset to become more flexible for updates and adopt technical standards making linkage to other health records possible.
        1. NEMSIS v3.3.4 was released in March 2014 and was the first version in production where live data was collected by services and states and subsequently submitted to NEMSIS. NEMSIS will continue to accept v3.3.4 data until 12/31/2017.
        2. NEMSIS v3.4, released in March 2015, included both changed elements and many added values to existing elements. NEMSIS has been accepting data from this version concurrently with V3.3.4 data. As of 01/01/2018, v3.4 will be the only standard and V3.3.4 will be phased out. All documentation guidelines found in this document are based on the NEMSIS v3.4 dataset and standard.
  2. Mandatory and Required Elements
    1. Mandatory: NEMSIS makes certain elements or fields mandatory so, if not included, the record cannot be properly stored or moved electronically. These fields require real data and do not accept Nil (Blank) values, Not Values, or Pertinent Negatives.
    2. Required: NEMSIS requires these elements or fields to be completed or the record cannot be properly stored or moved electronically. However, required fields allow Nil (blank) values, Not Values, or Pertinent Negatives to be entered and submitted.
    3. State and local systems may have Mandatory or Required fields that are not Mandatory or Required by NEMSIS. The manager for these systems should be contacted for a list of these fields.
  3. Not Values, Nil, and Pertinent Negatives
    1. Not Values (NV), Nil, and Pertinent Negatives (PN) are values that are attributes of certain NEMSIS elements designed to clarify a null data entry or qualify data entry into the element with which the NV, Nil, or PN is associated.
    2. Not Values available are “Not Applicable” and “Not Recorded”
      1. Some NEMSIS rules require one of these values to be entered when data is imported/exported if there is no other data in a field (e.g. at least one medications given must have a value, if no medications are given, then the software system must insert “Not Applicable” in the medications field when exporting)
      2. At times the EMS provider use of “Not Applicable” is appropriate documentation (e.g. using “Not Applicable” under 03 – Trauma Center Criteria, which combines step 1 and 2 of CDC’s Guidelines for Field Triage of Injured Patients, when transporting a patient with a simple sprained ankle)
    3. Nil Values are blank values
      1. Values can be left blank, which can either be an accidental or purposeful omission of data.
      2. Value fields can appropriately and purposefully be left blank if there was nothing to enter (e.g. a procedure field left blank if no patient was encountered).
    4. Pertinent Negatives are attributes or qualifiers for both elements and fields. There are 11 possible Pertinent Negative values and the available list for each field varies as appropriate to the field. Two examples of the use of Pertinent Negatives are:
      1. Documenting non-administration of aspirin for chest pain by the EMS provider with the Pertinent Negative of “Medication Already Taken” to show evidence that this treatment requirement was met.
      2. Documenting assessment of, and lack of a gunshot wound to the chest with the qualifier of “Chest –> gunshot wound –> Exam Finding Not Present” in the examination section (previously you could only document a positive finding of a gunshot wound with was no way to document that you looked and did not find one).
  4. NEMSIS Element and Value Name Formats
    1. NEMSIS Elements/Fields are organized into groups with other related elements/fields
      1. There are two parent datasets: Demographic (designated by a “d”) and EMS (designated by an “e”). The majority of the documentation in any ePCR falls in the “e” section. The Demographic dataset is intended to be descriptive of the EMS agencies and system characteristics for correlation at a larger research level, rather than for use in operational CPI reviews.
      2. The element numbering structure reflects the dataset and the text group name of the element
  5. Example: “eVitals.06 – SBP (Systolic Blood Pressure)” where “e” is the EMS dataset and “Vitals” is the dataset grouping for all elements related to Vitals and the number is the number assigned to a specific element.
    1. “eVitals.06” is used to store the data in the background and “SBP (Systolic Blood Pressure)” is what providers and reviewers see.
    2. Values are designated by a code and text name.
      1. The codes are generally derived from various sources such as ICD-10, SNOMED, or RxNorm and are used to store and move the data in the system’s background.
      2. Codes are not seen by the EMS provider in the ePCR, but rather the provider will see text names.
        1. Some software systems allow the visible text name to be modified or relabeled to meet local standards or nomenclature; This feature can help improve data quality by making documentation easier for the provider.
      3. An example of a value code and name for cardiac chest pain, found under the element “eProtocols.01 – Protocols Used” is “9914117 – Medical-Cardiac Chest Pain”.
    3. All minimum general documentation guideline requirements are identified using the NEMSIS element, values codes, and names to allow application across a variety of ePCR software labels for these fields.
  6. Custom Elements/Fields and Values
    1. The NEMSIS Standard provides a data format for software vendors to create custom elements or values requested by states or local systems.
    2. States or local systems may create new elements or value extensions for existing NEMSIS elements to meet regional needs (e.g. adding additional protocol name values not on the NEMSIS list).

Airway Confirmation Fields

Specific use of the NEMSIS airway confirmation fields in documentation will not be detailed at this time due to current operational and technical challenges all states, local systems, and ePCR software vendors are experiencing.

The NEMSIS airway confirmation fields were closely modeled on the “Recommended Guidelines for Uniform Reporting of Data from Out-of-Hospital Airway Management: Position Statement of the National Association of EMS Physicians” and the fields and values could provide excellent and appropriately useful data to evaluate airway management. However, the technical structure of the fields has made their practical use limited as all the data is collected as a separate, self-contained group, rather than as part of the procedures group. This means EMS providers would need to enter much of the same information twice in the ePCR, in both the procedures area and airway confirmation section (when, who did it, what device was used, and complications).

Furthermore, the airway group can only be entered once per ePRC, so the fields cannot be used again if more than one airway was required (e.g. one airway became ineffective and needed to be replaced with a different type of airway). Many states and ePCR software vendors have been struggling with how to make these fields functional for use by only using a portion of them or looking to add mirrored custom values that are directly linked to procedures performed. However, solutions are currently far from practical, functional, effective, or uniform in how they are being implemented or used across various systems.