Purpose Statement

Advanced EMS Workflow Conditions enable administrators to build sophisticated, multi-layered conditional logic that handles complex clinical scenarios requiring grouped field dependencies, nested conditions, and dynamic logic operators. This advanced functionality extends beyond single-field conditions to create enterprise-level workflow rules that manage entire form sections, evaluate multiple criteria simultaneously, and adapt logic structure mid-rule to accommodate nuanced EMS protocols and state reporting requirements.

Background Information

Complex workflow conditions become essential when agencies need to implement advanced clinical protocols, manage intricate state reporting logic, or create highly specialized form behaviors that cannot be achieved through simple field-level rules. These advanced workflows leverage group-based conditions, allowing administrators to evaluate multiple fields collectively rather than individually, and support mid-rule logic switching between AND/OR operators to create precisely tailored conditional statements.

This capability is particularly valuable for agencies managing multiple service levels, diverse call types, or sophisticated QA/QI requirements where documentation needs vary significantly based on compound criteria. While basic workflows address straightforward if-then scenarios, complex workflows provide the architectural framework needed for robust, scalable ePCR configurations that maintain data integrity across varied operational contexts.

Common Complex Workflow Scenarios

1. Some states require that specific fields contain only actual values or Pertinent Negatives under certain conditions, prohibiting both empty fields and "Not Applicable, Not Recorded, or Not Reporting" values. This workflow example demonstrates how to enforce this requirement using nested conditions with mid-rule logic switching.

1. Logic Structure:
   1. The top-level AND condition establishes when the rule applies (in this example, Unit Disposition = Patient Contact Made)
   2. The nested OR group evaluates whether the Medical/Surgical History field is either Empty OR contains restricted "Not Values" (Not Applicable, Not Recorded, Not Reporting)

1. This structure allows a single validation rule to catch both error conditions—leaving the field blank or selecting a prohibited value—ensuring providers document actual clinical findings or valid Pertinent Negatives when the triggering condition is met.
    

 

 

Hospital Team Activations - Requiring Group Documentation Conditionally

1. Some state requirements mandate hospital team pre-arrival alerts for specific clinical conditions during transport. For example, a state may require that the Hospital Team Activation fields be documented when a patient with Stroke or Cardiac Arrest impressions is being transported by this unit.

1. Why Group-Level Validation: Because these fields exist within a grid (Hospital Team Activation Group), writing validation rules on individual fields alone won't effectively drive providers to complete them. Instead, this workflow targets the group itself to require at least one row be entered when specific conditions are met.

1. Logic Structure:
   1. The top-level AND conditions establish that the group contains fewer than 1 row (meaning it's empty) and the patient is being transported
   2. The nested OR group checks whether either the Primary or Secondary Provider Impressions contain the critical values that trigger the requirement

1. This approach ensures providers are prompted to document hospital team notifications when clinically necessary, regardless of which impression field contains the triggering diagnosis.
    

 

 

 

Crew Member Verification - Confirming Crew Attribution

1. It is important to ensure the provider completing this report was listed as a crew member on this incident. This simple workflow uses a Warning Validation to flag the signature field if the name selected in "Crew Member Completing this Report" does not match any crew member listed in the Crew Member grid.

1. Benefits:
   1. Prompts the provider to confirm they are the correct person authoring the report
   2. Helps prevent documentation mismatch where someone not involved in the call attempts to complete the ePCR
   3. Ensures accountability and accurate crew attribution for each incident report
       

 

 

 

Vitals Group Validation - Requiring Minimum Vital Sign Assessments

1. Many states and departments require that providers document a minimum number of vital sign assessments during patient care, regardless of which specific fields are completed in each row. For example, an agency may require at least two timestamped vital sign assessments for every transported patient to demonstrate ongoing patient monitoring.

1. Logic Structure: This workflow validates at the group level by counting the total number of vitals rows documented, without evaluating what fields are completed within those rows. The validation triggers when the Vitals Group contains fewer than 2 rows and the patient is being transported.

1. Flexibility: This approach allows providers to document whatever vital signs are clinically obtained at each assessment—one row might contain HR, BP, and RR while another contains only SpO2 and BGL—without being blocked by field-specific requirements. The workflow simply ensures that at least two separate vital sign assessments have been documented before the report can be finalized.
    

 

 

 

Vitals Group Validation - Requiring Specific Vital Sign Fields

1. Some agencies have more granular requirements that mandate specific vital signs be documented a minimum number of times for trending purposes. For example, protocols may require at least two Heart Rate measurements for every transported patient to support clinical decision-making and demonstrate ongoing cardiac monitoring.

1. Logic Structure: This workflow still validates at the group level but adds logic to count how many times a specific field (Heart Rate) has been documented across all vitals rows. By checking that the Vitals Group contains fewer than 2 instances where HR is "Not Empty," the workflow counts actual HR documentation without requiring HR be completed in every single vitals row.

1. Example: A provider might document HR and BP in one row, then document RR and SpO2 in a second row, and finally add HR again in a third row—this would satisfy the "at least 2 HR values" requirement even though HR wasn't documented in every row.

1. Scaling This Approach: To require multiple specific vital signs, simply use the Copy feature to duplicate this workflow and change the target field in each copied version. For example, if your agency requires a minimum of two measurements for HR, BP, RR, and SpO2, you would create four separate workflows on the Vitals Group—one counting each field. Agencies with comprehensive vital sign requirements may have 8-12 workflows built on the Vitals Group, each counting a different field, which collectively ensure protocol compliance while still allowing crews autonomy in how they document each individual vitals row.
    

 

 

 

Pregnancy Status - Conditional Requirements Based on Patient Demographics

1. Many EMS agencies have clinical protocols requiring pregnancy status assessment for patients of childbearing age. These requirements help ensure appropriate care decisions, medication considerations, and destination selection. However, requiring pregnancy-related fields for all patients regardless of demographics creates unnecessary documentation burden and can be clinically irrelevant.

1. Logic Structure: This workflow demonstrates how to conditionally prompt pregnancy status documentation based on patient age and biological sex using a Warning Validation. The workflow uses multiple AND conditions to create a precise demographic filter:
   1. Currently Pregnant field must be empty
   2. Patient Sex equals Female
   3. Patient Age is greater than or equal to 12 and less than or equal to 65
   4. Age Unit is in Years

1. All five conditions must be true for the warning to trigger.

1. Benefits: This approach prompts providers to document pregnancy status only when clinically relevant, reducing unnecessary warnings for pediatric patients, elderly patients, and male patients while ensuring protocol compliance for patients of childbearing potential. Because this uses a Warning rather than an Error validation, providers can still save the report if pregnancy status cannot be obtained, but they receive a clear prompt when documentation is expected.

Note: The age range can be adjusted to match your agency's specific protocol requirements or state guidelines.