Location-based sharing of cross-configuration EPCR data

Abstract

A system for sharing patient care record (ePCR) data between emergency medical services (EMS) agencies. The system includes a memory, a network interface, and a processor. The memory stores a first EMS system configuration of a first EMS agency, and a second EMS system configuration of a second EMS agency. The processor is configured to receive, via the network interface, a message requesting creation of a second ePCR associated with a scene location and the second EMS system configuration, identify a first ePCR created before the second ePCR and associated with the scene location and the first EMS system configuration, determine that the second EMS system configuration authorizes access to ePCR data associated with the first EMS system configuration, and store a set of cross-configuration ePCR data field values from the first ePCR within the second ePCR.

Description

LOCATION-BASED SHARING OF CROSS-CONFIGURATION EPCR DATARELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No.63 / 762,395 titled “LOCATION-BASED SHARING OF CROSS-CONFIGURATION EPCR DATA” and filed February 24, 2025, which is hereby incorporated herein by reference in its entirety.BACKGROUND

[0002] The present disclosure is directed to systems and methods for sharing electronic patient care record (ePCR) data between emergency medical services (EMS) agencies. EMS agencies create and use an ePCR for each patient encounter. These patient encounters result, for example, from a crew of EMS professionals being dispatched to a particular location to respond to a call for help. Even if a particular patient has been treated during multiple encounters with one or more EMS agencies, there will be a newly generated and separate ePCR for each encounter with each agency. This stands in contrast to a patient medical record generated by a physician where the record follows the patient and includes information about multiple encounters with the physician for that same patient. The ePCR contains a complete and time-stamped record of medical observations, interventions and treatments, and transport for the patient during a patient encounter. Due to the intricacies of medical care along with governmental reporting guidelines, the ePCR is typically a complex and lengthy document.

[0003] Software applications exist that interact with EMS personnel to complete ePCRs. These software applications include user interface screens with controls to receive input from EMS personnel regarding the patient encounter. This input specifies values of data fields that document the complete encounter record described above.SUMMARY

[0004] In an example, a system for sharing patient care record (ePCR) data between emergency medical services (EMS) agencies is provided. The system includes a memory; at least one network interface; and at least one processor coupled with the at least one network interface and the memory. The memory stores a first EMS system configuration of a first EMS agency, and a second EMS system configuration of a second EMS agency, the first EMS system configuration being distinct from the second EMS system configuration. The at least one processor is configured to receive, via the at least one network interface, a messagerequesting creation of a second ePCR associated with a scene location and the second EMS system configuration, identify a first ePCR created before the second ePCR and associated with the scene location and the first EMS system configuration, determine that the second EMS system configuration authorizes access to ePCR data associated with the first EMS system configuration, and store a set of cross-configuration ePCR data field values from the first ePCR within the second ePCR.

[0005] The system may incorporate one or more of the following features. In the system, to identify the first ePCR may include to compare at least one first ePCR data field value recorded in the first ePCR to at least one second ePCR data field value recorded in the second ePCR. The at least one first ePCR data field value may be a time of arrival at the scene location recorded in the first ePCR; the at least one second ePCR data field value may be a time of arrival at the scene location recorded in the second ePCR; and to compare may include to determine whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the arrival at the scene location recorded in the second ePCR transgresses a threshold value. The at least one first ePCR data field value may be a time of arrival at the scene location recorded in the first ePCR; the at least one second ePCR data field value may be a time of ePCR creation recorded in the second ePCR; and to compare may include to determine whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the ePCR creation recorded in the second ePCR transgresses a threshold value. The at least one first ePCR data field value may be a first address of the scene location; the at least one second ePCR data field value is a second address of the scene location; and to compare may include to determine whether the first address matches the second address. The first address is a first text string; and the second address is a second text string. The first text string may include a first zone improvement project (ZIP) code and a first street address; and the second text string may include a second ZIP code and a second street address.

[0006] The system may further include a user interface configured to receive input specifying the second ePCR data field value. In the system, to receive the input may include to receive gesture-based alphanumeric input. The first ePCR data field value is a first set of global positioning system (GPS) coordinates; the second ePCR data field value is a second set of GPS coordinates; and to compare may include to determine whether the first set of GPS coordinates matches the second set of GPS coordinates.

[0007] The system may further include a computer-aided dispatch (CAD) system. In the system, the at least one processor may be configured to receive, via the at least one networkinterface, one or more messages from the CAD system; parse the one or more message to extract a CAD data field value; and store the CAD data field value in the second ePCR as the at least one second ePCR data field value.

[0008] In the system, the at least one processor may be configured to receive one or more selections of one or more ePCR data fields from the first ePCR; and to store the set of crossconfiguration ePCR data field values may include to store, within the second ePCR, first cross-configuration ePCR data field values from a default set of ePCR data fields in the first ePCR, and to store, within the second ePCR, second cross-configuration ePCR data field values from the one or more ePCR data fields. The default set of ePCR data fields may include patient data fields; and the one or more ePCR data fields may include one or more encounter data fields. The one or more encounter data fields may include one or more of physiological measurement data fields and EMS event data fields.

[0009] In the system, to store the set of cross-configuration ePCR data field values may include to flag each ePCR data field value of the set as originating from the first ePCR. The system may further include a user interface configured to provide the set of crossconfiguration ePCR data field values for editing. In the system, the user interface may be configured to remove a flag for each ePCR data field value that is edited. The user interface may be configured to record an audit trail of events associated with the set of crossconfiguration ePCR data field values. The audit trail may include one or more of a timestamp recorded when the set of cross-configuration ePCR data field values was stored within the second ePCR, an identifier of the first ePCR, one or more identifiers of one or more patients encountered at the scene location, an identifier of an EMS provider at the scene location, and an identifier of a computing device that originated the message requesting creation of a second ePCR.

[0010] The system may further include a user interface configured to provide a tabular chronology that includes a plurality of entries arranged in chronological order, each entry of the plurality of entries indicating an ePCR that originated the entry and being representative of either an ePCR data field value of the set of cross-configuration ePCR data field values or another ePCR data field value stored in the second ePCR. In the system, the at least one processor may be further configured to determine that at least one importable ePCR data field value from the set of cross-configuration ePCR data field values is absent from the second EMS system configuration. The second EMS system configuration may store a code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the second ePCR; the importable ePCR data field value may be authorized for storagewithin a respective ePCR data field of the first ePCR according to the first EMS system configuration and unauthorized for storage within a respective ePCR data field of the second ePCR according to the second EMS system configuration; and the at least one processor may be configured to add at least one hidden record to the code table specifying that the importable ePCR data field value is authorized for importation into the respective ePCR data field of the second ePCR.

[0011] In the system, the code table may be a second code table; the first EMS system configuration may store a first code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the first ePCR; and to add the at least one hidden record to the second code table may include to identify at least one existing record in the first code table specifying the importable ePCR data field value, copy at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, and mark the at least one new record in the second code table as hidden. The second EMS system configuration may stores a code table specifying ePCR data fields authorized for inclusion within the second ePCR; the set of cross-configuration ePCR data field values from the first ePCR may include at least one ePCR data field for an ePCR data field not specified within the code table; and the at least one processor may be configured to add at least one hidden record to the code table specifying that the at least one ePCR data field is authorized for importation into the second ePCR. The code table may be a second code table; the first EMS system configuration may store a first code table specifying ePCR data fields authorized for inclusion within the first ePCR; and to add the at least one hidden record to the second code table may include to identify at least one existing record in the first code table specifying the at least one ePCR data field, copy at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, and mark the at least one new record in the second code table as hidden. It should be noted that, in some examples, to copy at least a portion of the at least one existing record in the first code table to at least one new record in the second code table may include to generate one or more new values equivalent to the portion of the at least one existing record in the first code table and to store the one or more new values in the at least one new record.

[0012] The system may further include a user interface configured to provide access to the code table for editing. The user interface may be configured to omit visualizations of hidden records. In the system, the memory may store a registry with one or more records that authorize the second EMS agency to read the ePCR data associated with the first EMS agency, and store the ePCR data within the second ePCR; and to determine that the secondEMS agency is authorized to access the ePCR data associated with the first EMS agency may include to identify the one or more records within the registry, determine, from the one or more records, that the second EMS agency is authorized to read the ePCR data associated with the first EMS agency, and determine, from the one or more records, that the second EMS agency is authorized to store the ePCR data within the second ePCR.

[0013] The system may further include a user interface configured to provide the registry for editing to a user associated with the first EMS agency; and receive input authorizing the second EMS agency to read the ePCR data associated with the first EMS agency.

[0014] The system may further include a user interface configured to provide the registry for editing to a user associated with the second EMS agency; and receive input authorizing the second EMS agency to store the ePCR data associated with the first EMS agency.

[0015] In the system, the at least one processor may be configured to receive, via the at least one network interface, a message requesting closure of the second ePCR; validate the second ePCR; and close the second ePCR in response to validation success. In the system, to validate the second ePCR may include to skip validation of one or more ePCR data field values of the set of cross-configuration ePCR data field values. In the system, to validate the second ePCR includes to skip at least one validation rule invoked by presence of one or more ePCR data field values of the set of cross-configuration ePCR data field values. The at least one validation rule may require an identified ePCR data field to be populated if one of the one or more ePCR data field values is present. The at least one validation rule may require an identified ePCR data field to be populated if an EMS call type identified in the second ePCR matches a target EMS call type; and the set of cross-configuration ePCR data field values includes a value of NULL for the identified ePCR data field.

[0016] In another example, a method implemented by a computing device for sharing patient care record (ePCR) data between emergency medical services (EMS) agencies is provided. The method includes receiving, via at least one network interface, a message requesting creation of a second ePCR associated with a scene location and a second EMS system configuration, identifying a first ePCR created before the second ePCR and associated with the scene location and a first EMS system configuration distinct from the second EMS system configuration, determining that the second EMS system configuration authorizes access to ePCR data associated with the first EMS system configuration, and storing a set of cross-configuration ePCR data field values from the first ePCR within the second ePCR.

[0017] In the method, identifying the first ePCR may include comparing at least one first ePCR data field value recorded in the first ePCR to at least one second ePCR data field valuerecorded in the second ePCR. The at least one first ePCR data field value may be a time of arrival at the scene location recorded in the first ePCR; the at least one second ePCR data field value may be a time of arrival at the scene location recorded in the second ePCR; and comparing may include determining whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the arrival at the scene location recorded in the second ePCR transgresses a threshold value. The at least one first ePCR data field value may be a time of arrival at the scene location recorded in the first ePCR; the at least one second ePCR data field value may be a time of ePCR creation recorded in the second ePCR; and comparing may include determining whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the ePCR creation recorded in the second ePCR transgresses a threshold value. The at least one first ePCR data field value is a first address of the scene location; the at least one second ePCR data field value is a second address of the scene location; and comparing may include to determining whether the first address matches the second address.

[0018] The method may incorporate one or more of the following features. In the method, the first address may be a first text string; the second address may be a second text string; and determining whether the first address matches the second address may include determining whether the first text string matches the second text string. The first text string may include a first zone improvement project (ZIP) code and a first street address; and the second text string may include a second ZIP code and a second street address; and determining whether the first text string matches the second text string may include determining whether the first ZIP code matches the second ZIP code, and determining whether the first street address matches the second street address.

[0019] The method may further include receiving, via a user interface, input specifying the second ePCR data field value. In the method, receiving the input may include receiving gesture-based alphanumeric input. In the method, the first ePCR data field value may be a first set of global positioning system (GPS) coordinates; the second ePCR data field value may be a second set of GPS coordinates; and comparing may include determining whether the first set of GPS coordinates matches the second set of GPS coordinates.

[0020] The method may further include receiving, via the at least one network interface, one or more messages from a computer-aided dispatch (CAD) system; parsing the one or more message to extract a CAD data field value; and storing the CAD data field value in the second ePCR as the at least one second ePCR data field value. The method may further include receiving one or more selections of one or more ePCR data fields from the firstePCR, and in the method, storing the set of cross-configuration ePCR data field values may include storing, within the second ePCR, first cross-configuration ePCR data field values from a default set of ePCR data fields in the first ePCR, and storing, within the second ePCR, second cross-configuration ePCR data field values from the one or more ePCR data fields. In the method, storing the first ePCR data field values from the default set may include storing the first ePCR data field values from patient data fields; and storing the second ePCR data field values from the one or more ePCR data fields may include storing the second ePCR data field values from one or more encounter data fields. Storing the second ePCR data field values from the one or more encounter data fields may include storing one or more of physiological measurement data fields and EMS event data fields.

[0021] In the method, storing the set of cross-configuration ePCR data field values may include flagging each ePCR data field value of the set as originating from the first ePCR. The method may further include providing, via a user interface, the set of cross-configuration ePCR data field values for editing. The method may further include removing a flag for each ePCR data field value that is edited. The method may further include recording an audit trail of events associated with the set of cross-configuration ePCR data field values. In the method, recording the audit trail may include recording one or more of a timestamp recorded when the set of cross-configuration ePCR data field values was stored within the second ePCR, an identifier of the first ePCR, one or more identifiers of one or more patients encountered at the scene location, an identifier of an EMS provider at the scene location, and an identifier of a computing device that originated the message requesting creation of a second ePCR.

[0022] The method may further include providing, via a user interface, a tabular chronology that includes a plurality of entries arranged in chronological order, each entry of the plurality of entries indicating an ePCR that originated the entry and being representative of either an ePCR data field value of the set of cross-configuration ePCR data field values or another ePCR data field value stored in the second ePCR. The method may further include determining that at least one importable ePCR data field value from the set of crossconfiguration ePCR data field values is absent from the second EMS system configuration.

[0023] In the method, the second EMS system configuration may store a code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the second ePCR; the importable ePCR data field value may be authorized for storage within a respective ePCR data field of the first ePCR according to the first EMS system configuration and unauthorized for storage within a respective ePCR data field of the secondePCR according to the second EMS system configuration; and the method may further include adding at least one hidden record to the code table specifying that the importable ePCR data field value is authorized for importation into the respective ePCR data field of the second ePCR. In the method, the code table may be a second code table; the first EMS system configuration may store a first code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the first ePCR; and adding the at least one hidden record to the second code table may include identifying at least one existing record in the first code table specifying the importable ePCR data field value, copying at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, and marking the at least one new record in the second code table as hidden. The second EMS system configuration may store a code table specifying ePCR data fields authorized for inclusion within the second ePCR; the set of cross-configuration ePCR data field values from the first ePCR may include at least one ePCR data field for an ePCR data field not specified within the code table; and the method further include adding at least one hidden record to the code table specifying that the at least one ePCR data field is authorized for importation into the second ePCR. The code table may be a second code table; the first EMS system configuration may stores a first code table specifying ePCR data fields authorized for inclusion within the first ePCR; and adding the at least one hidden record to the second code table may include identifying at least one existing record in the first code table specifying the at least one ePCR data field, copying at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, and marking the at least one new record in the second code table as hidden.

[0024] The method may further include providing, via a user interface, access to the code table for editing. The method may further include omitting visualizations of hidden records.

[0025] In the method, determining that the second EMS agency is authorized to access the ePCR data associated with the first EMS agency may include identifying one or more records within a registry, the registry storing one or more records that authorize the second EMS agency to read the ePCR data associated with the first EMS agency, and store the ePCR data within the second ePCR; determining, from the one or more records, that the second EMS agency is authorized to read the ePCR data associated with the first EMS agency, and determining, from the one or more records, that the second EMS agency is authorized to store the ePCR data within the second ePCR. The method may further include providing, via a user interface, the registry for editing to a user associated with the first EMS agency; andreceiving input authorizing the second EMS agency to read the ePCR data associated with the first EMS agency.

[0026] The method may further include providing, via a user interface, the registry for editing to a user associated with the second EMS agency; and receiving input authorizing the second EMS agency to store the ePCR data associated with the first EMS agency. The method may further include receiving, via the at least one network interface, a message requesting closure of the second ePCR; validating the second ePCR; and closing the second ePCR in response to validation success. The method may further include validating the second ePCR includes skipping validation of one or more ePCR data field values of the set of cross-configuration ePCR data field values. In the method, validating the second ePCR may include skipping at least one validation rule invoked by presence of one or more ePCR data field values of the set of cross-configuration ePCR data field values. Skipping the at least one validation rule may include skipping one or more validation rules that require one or more identified ePCR data fields to be populated if one or more of the one or more ePCR data field values is present. Skipping the at least one validation rule may include skipping one or more validation rules that require one or more identified ePCR data fields to be populated if an EMS call type identified in the second ePCR matches a target EMS call type.

[0027] In another example, one or more non-transitory computer-readable media are provided. The one or more non-transitory computer-readable media store sequences of instructions executable by a processor to share patient care record (ePCR) data between emergency medical services (EMS) agencies. The sequences of instructions including instructions to receive, via at least one network interface, a message requesting creation of a second ePCR associated with a scene location and a second EMS system configuration, identify a first ePCR created before the second ePCR and associated with the scene location and a first EMS system configuration distinct from the second EMS system configuration, determine that the second EMS system configuration authorizes access to ePCR data associated with the first EMS system configuration, and store a set of cross-configuration ePCR data field values from the first ePCR within the second ePCR.

[0028] In the computer-readable media, the instructions to identify the first ePCR may include instructions to compare at least one first ePCR data field value recorded in the first ePCR to at least one second ePCR data field value recorded in the second ePCR. The at least one first ePCR data field value may be a time of arrival at the scene location recorded in the first ePCR; the at least one second ePCR data field value may be a time of arrival at the scene location recorded in the second ePCR; and the instructions to compare may includeinstructions to determine whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the arrival at the scene location recorded in the second ePCR transgresses a threshold value. The at least one first ePCR data field value may be a time of arrival at the scene location recorded in the first ePCR; the at least one second ePCR data field value may be a time of ePCR creation recorded in the second ePCR; and the instructions to compare may include instructions to determine whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the ePCR creation recorded in the second ePCR transgresses a threshold value. The at least one first ePCR data field value may be a first address of the scene location; the at least one second ePCR data field value may be a second address of the scene location; and the instructions to compare may include the instructions to determine whether the first address matches the second address. The first address may be a first text string; the second address may be a second text string; and the instructions to determine whether the first address matches the second address may include instructions to determine whether the first text string matches the second text string. The first text string may include a first zone improvement project (ZIP) code and a first street address; the second text string may include a second ZIP code and a second street address; and the instructions to determine whether the first text string matches the second text string may include instructions to determine whether the first ZIP code matches the second ZIP code, and determine whether the first street address matches the second street address.

[0029] The computer-readable media may incorporate one or more of the following features. The computer-readable media may further include instructions to receive, via a user interface, input specifying the second ePCR data field value. The instructions to receive the input may include instructions to receive gesture-based alphanumeric input. The first ePCR data field value may be a first set of global positioning system (GPS) coordinates; the second ePCR data field value may be a second set of GPS coordinates; and the instructions to compare may include instructions to determine whether the first set of GPS coordinates matches the second set of GPS coordinates.

[0030] In the computer-readable media, the sequences of instructions may further include instructions to receive, via the at least one network interface, one or more messages from a computer-aided dispatch (CAD) system; parse the one or more message to extract a CAD data field value; and store the CAD data field value in the second ePCR as the at least one second ePCR data field value. The sequences of instructions may further include instructions to receive one or more selections of one or more ePCR data fields from the first ePCR, andthe instructions to store the set of cross-configuration ePCR data field values may include instructions to store, within the second ePCR, first cross-configuration ePCR data field values from a default set of ePCR data fields in the first ePCR, and store, within the second ePCR, second cross-configuration ePCR data field values from the one or more ePCR data fields. The instructions to store the first ePCR data field values from the default set may include instructions to store the first ePCR data field values from patient data fields; and the instructions to store the second ePCR data field values from the one or more ePCR data fields may include instructions to store the second ePCR data field values from one or more encounter data fields. The instructions to store the second ePCR data field values from the one or more encounter data fields may include instructions to store one or more of physiological measurement data fields and EMS event data fields.

[0031] In the computer-readable media, the instructions to store the set of crossconfiguration ePCR data field values may include instructions to flag each ePCR data field value of the set as originating from the first ePCR. The sequences of instructions may further include instructions to provide, via a user interface, the set of cross-configuration ePCR data field values for editing. The sequences of instructions may further include instructions to remove a flag for each ePCR data field value that is edited. The sequences of instructions may further include instructions to record an audit trail of events associated with the set of cross-configuration ePCR data field values. The instructions to record the audit trail may include instructions to record one or more of a timestamp recorded when the set of crossconfiguration ePCR data field values was stored within the second ePCR, an identifier of the first ePCR, one or more identifiers of one or more patients encountered at the scene location, an identifier of an EMS provider at the scene location, and an identifier of a computing device that originated the message requesting creation of a second ePCR.

[0032] In the computer-readable media, the sequences of instructions may further include instructions to provide, via a user interface, a tabular chronology that includes a plurality of entries arranged in chronological order, each entry of the plurality of entries indicating an ePCR that originated the entry and being representative of either an ePCR data field value of the set of cross-configuration ePCR data field values or another ePCR data field value stored in the second ePCR. The sequences of instructions may further include instructions to determine that at least one importable ePCR data field value from the set of crossconfiguration ePCR data field values is absent from the second EMS system configuration.

[0033] In the computer-readable media, the second EMS system configuration may store a code table specifying ePCR data field values authorized for storage within respective ePCRdata fields of the second ePCR; the importable ePCR data field value may be authorized for storage within a respective ePCR data field of the first ePCR according to the first EMS system configuration and unauthorized for storage within a respective ePCR data field of the second ePCR according to the second EMS system configuration; and the sequences of instructions may further include instructions to add at least one hidden record to the code table specifying that the importable ePCR data field value is authorized for importation into the respective ePCR data field of the second ePCR. The code table may be a second code table; the first EMS system configuration stores a first code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the first ePCR; and the instructions to add the at least one hidden record to the second code table may include instructions to identify at least one existing record in the first code table specifying the importable ePCR data field value, copy at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, and mark the at least one new record in the second code table as hidden. The second EMS system configuration may store a code table specifying ePCR data fields authorized for inclusion within the second ePCR; the set of cross-configuration ePCR data field values from the first ePCR may include at least one ePCR data field for an ePCR data field not specified within the code table; and the sequences of instructions may further include instructions to add at least one hidden record to the code table specifying that the at least one ePCR data field is authorized for importation into the second ePCR. The code table may be a second code table; the first EMS system configuration stores a first code table specifying ePCR data fields authorized for inclusion within the first ePCR; and the instructions to add the at least one hidden record to the second code table may include instructions to identify at least one existing record in the first code table specifying the at least one ePCR data field, copy at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, and mark the at least one new record in the second code table as hidden.

[0034] In the computer-readable media, the sequences of instructions may include instructions to provide, via a user interface, access to the code table for editing. The sequences of instructions may further include instructions to omit visualizations of hidden records.

[0035] In the computer-readable media, the instructions to determine that the second EMS agency is authorized to access the ePCR data associated with the first EMS agency may include instructions to identify one or more records within a registry, the registry storing one or more records that authorize the second EMS agency to read the ePCR data associated withthe first EMS agency, and store the ePCR data within the second ePCR; determine, from the one or more records, that the second EMS agency is authorized to read the ePCR data associated with the first EMS agency, and determine, from the one or more records, that the second EMS agency is authorized to store the ePCR data within the second ePCR. The sequences of instructions may further include instructions to provide, via a user interface, the registry for editing to a user associated with the first EMS agency; and receive input authorizing the second EMS agency to read the ePCR data associated with the first EMS agency. The sequences of instructions may further include instructions to provide, via a user interface, the registry for editing to a user associated with the second EMS agency; and receive input authorizing the second EMS agency to store the ePCR data associated with the first EMS agency.

[0036] In the computer-readable media, the sequences of instructions may further include instructions to receive, via the at least one network interface, a message requesting closure of the second ePCR; validate the second ePCR; and close the second ePCR in response to validation success. The sequences of instructions to validate the second ePCR may include instructions to skip validation of one or more ePCR data field values of the set of crossconfiguration ePCR data field values. The sequences of instructions to validate the second ePCR may include instructions to skip at least one validation rule invoked by presence of one or more ePCR data field values of the set of cross-configuration ePCR data field values. The sequences of instructions to skip the at least one validation rule may include instructions to skip one or more validation rules that require one or more identified ePCR data fields to be populated if one or more of the one or more ePCR data field values is present. The sequences of instructions to skip the at least one validation rule may include instructions to skip one or more validation rules that require one or more identified ePCR data fields to be populated if an EMS call type identified in the second ePCR matches a target EMS call type.BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Various aspects of at least one example are discussed below with reference to the accompanying figures, which are not intended to be drawn to scale. The figures are included to provide an illustration and a further understanding of the various aspects and examples disclosed herein and are incorporated in and constitute a part of this specification. However, the figures are not intended to limit the scope of the disclosure. The figures, together with the remainder of the specification, serve to explain principles and operations of the described and claimed aspects and examples. In the figures, each identical or nearly identical componentthat is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every figure.

[0038] FIG. l is a storyboard diagram illustrating a patient encounter with multiple responding EMS agencies that each utilize a common, cloud-based charting system configured to generate and share ePCR data in accordance with at least one example disclosed herein.

[0039] FIG. 2 is a block diagram showing a more detailed example of the charting system introduced in FIG. 1.

[0040] FIG. 3 A is a flow diagram illustrating an ePCR notification process that at least some examples of the charting system introduced in FIG. 1 are configured to execute.

[0041] FIG. 3B is a flow diagram illustrating another ePCR notification process that at least some examples of the charting system introduced in FIG. 1 are configured to execute.

[0042] FIG. 4 is a front view of an ePCR user interface screen configured to receive input specifying a location of a scene of a patient who is a subject of an EMS call in accordance with at least one example disclosed herein.

[0043] FIG. 5 is a front view of an ePCR user interface screen and dialog box configured to receive input specifying times at which certain events occur within an EMS call in accordance with at least one example disclosed herein.

[0044] FIG. 6 is a front view of an ePCR user interface screen configured to indicate availability of ePCR data generated by a first EMS agency for importation into an ePCR created by a second EMS agency in accordance with at least one example disclosed herein.

[0045] FIG. 7 is a flow diagram illustrating a cross-configuration ePCR data importation process that at least some examples of the charting system introduced in FIG. 1 are configured to execute.

[0046] FIG. 8 is a block diagram illustrating front views of ePCR user interface screens involved in importation and display of cross-configuration ePCR data in accordance with at least one example disclosed herein.

[0047] FIG. 9 is a front view of an ePCR user interface screen configured to receive input selecting a first ePCR generated by a first EMS agency for importation into a second ePCR generated by a second EMS agency in accordance with at least one example disclosed herein.

[0048] FIG. 10A is a front view of an ePCR user interface screen configured to receive input selecting certain ePCR data field values from a first ePCR generated by a first EMS agency for importation into ePCR data fields of a second ePCR generated by a second EMS agency in accordance with at least one example disclosed herein.

[0049] FIG. 10B is another front view of the ePCR user interface screen illustrated in FIG.10A in accordance with at least one example disclosed herein.

[0050] FIG. 11 is a front view of an ePCR user interface screen configured to display ePCR data field values within a first ePCR created by a first EMS agency imported from ePCR data field values of a second ePCR generated by a second EMS agency in accordance with at least one example disclosed herein.

[0051] FIG. 12 is a block diagram illustrating processes and data stores involved in autonomous manipulation of an EMS agency’s configuration data to enable importation of ePCR data fields and ePCR data field values not previously stored in the EMS agency’s configuration data in accordance with at least one example disclosed herein.

[0052] FIG. 13 is a flow diagram illustrating another cross-configuration ePCR data importation process that at least some examples of the charting system introduced in FIG. 1 are configured to execute.

[0053] FIG. 14 is a flow diagram illustrating an audit trail process that at least some examples of the charting system introduced in FIG. 1 are configured to execute.

[0054] FIG. 15 is a front view of an ePCR user interface screen configured to receive input altering ePCR data field values imported from another ePCR in accordance with at least one example disclosed herein.

[0055] FIG. 16 is a flow diagram illustrating a cross-configuration authorization process that at least some examples of the charting system introduced in FIG. 1 are configured to execute.

[0056] FIG. 17 is a block diagram illustrating front views of ePCR user interface screens involved in cross-configuration authorization in accordance with at least one example disclosed herein.

[0057] FIG. 18 is a front view of an ePCR user interface screen configured to authorize field personnel of a first EMS agency to import ePCR data from ePCRs created by another EMS agency in accordance with at least one example disclosed herein.

[0058] FIG. 19 is a flow diagram illustrating an ePCR validation process that at least some examples of the charting system introduced in FIG. 1 are configured to execute.

[0059] FIG. 20 is a flow diagram illustrating an CAD data importation process that at least some examples of the charting system introduced in FIG. 1 are configured to execute.

[0060] FIG. 21 is an entity relationship diagram illustrating data structures configured to store ePCR and cross-configuration ePCR data in accordance with at least one example disclosed herein.

[0061] FIG. 22 is a schematic block diagram of examples of computing and medical device components with which at least one example disclosed herein may be implemented.DETAILED DESCRIPTION

[0062] As summarized above, the systems and methods disclosed herein are directed to sharing of ePCR data between EMS agencies.

[0063] Often in an emergency encounter, EMS caregivers interact with a critically ill patient for the first time and with no prior medical knowledge about the patient. The emergency encounter is usually in a non-medical environment like a home, office, or gym. In many cases, the encounter occurs in the chaotic environment of a fire scene, a car accident, or a mass casualty scene.

[0064] For example, consider an illustrative scenario of a crew of EMS caregivers in an ambulance being called upon to treat a patient suffering from an emergency medical condition (e.g., cardiac arrest, trauma, respiratory distress, drug overdose, etc.) and to transport the patient to a hospital. During the course of this emergency encounter, the EMS caregivers may be required to travel to a patient’s scene, determine patient information, such as a mechanism of injury and a chief complaint, observe patient symptoms and conditions, measure patient physiological parameters (such as heart rate and other vital signs, electrocardiogram (ECG) traces, temperature, blood-oxygen data, and the like), administer treatments, interventions, and / or medications, and transport the patient from the scene to a medical facility.

[0065] To provide a complete and accurate record of each encounter that includes patient and encounter information, as described above, the EMS caregivers are tasked not only with providing medical care to patients but also recording and documenting detailed encounter information. For example, the EMS caregivers may document observations, examinations, and / or communications with the patient relevant to the patient’ s medical condition. This patient information can include, for instance, patient biographical information, past medical conditions, medications, allergies, vital signs, mental state, and the like. Other patient information recorded may include patient demographic information and billing / insurance information. In addition to patient information, the EMS caregivers may also be expected to record information regarding the encounter itself, such as the type of service requested, response mode, transport, and the like. This documentation may take the form of an ePCR. The ePCR includes data fields configured to store a comprehensive set of patient and encounter information according to a schema that controls the structure of the data provided to the digital record. The ePCR may include hundreds of mandatory data fields, although data field entriescan include “not applicable” for data fields that do not apply to a particular call. In some examples, the schema may be a multi-agency standard that provides a compliance architecture to allow transfer of data and data interoperability between individual agency systems and enables entry of data in a centralized database. An example of such a standard is the National Emergency Medical Services Information Standard (NEMSIS) for emergency care medical record data collection. NEMSIS is an official EMS data collection standard for EMS agencies which allows transfer of data between systems and provides a national EMS repository for reporting and research. NEMSIS provides consistent definitions of data elements used in EMS and other pre-hospital care settings. The NEMSIS data collection via NEMSIS-compliant ePCRs may enable analysis of this data for evaluation of and evidence-based improvements in patient care across an array of EMS agencies. In particular, the NEMSIS-compliant ePCRs conform to a structured XML standard for the ePCR data. NEMSIS and the XML standard are examples only and other formats and / or content requirements are within the scope of this disclosure. For instance, the HL7®FHIR® (Health Level Seven Fast Healthcare Interoperability Resources) standard defines how healthcare information can be exchanged between different computer systems such as those servicing emergency care and those servicing hospitals. Other examples of standards include, but are not limited to, an HL7 version 2, version 3 or CDA standard, an Electronic Data Interchange (EDI) Healthcare including, 270, 271, 276, 277, 278, 820, 834, 835, 837P and 8371 standard, SNOMED CT standard, diagnosis classification ICD standard, and procedure chart HCPCS and CPT standards.

[0066] In an implementation, the data fields within an ePCR may be organized into data set sections that cover various aspects of the emergency encounter. These data set sections may include, for example, data sets for airway, cardiac arrest, EMS crew, medical device, dispatch, patient disposition, patient examination, patient history, injury, laboratory results, and medications. In addition, in some implementations, an agency may include customized data set sections. As an example, a patient history section may include the data fields indicated below in Table 1. Examples of field values for the data fields are also provided in Table 1. The data field values may be associated with an ICD chart (e.g., International Classification of Diseases) for billing purposes.

[0067] As another example of ePCR data, Table 2 below shows examples of data fields and data field values for a pre-scheduled dialysis transport.Pickup Zone 16&

[0068] For maximum accuracy and to provide the most real-time benefit to caregivers, both pre-hospital and at a transport destination, the ePCR should be completed contemporaneously with, i.e., during, the ongoing encounter, with a completed document available upon transfer of the patient from EMS to a medical facility. However, this documentation competes for the attention of the responders with the responders need to attend to medical care of the patient. For example, entering this data during the encounter may divert the attention of the EMS caregiver away from the patient and reduce the amount of time the EMS caregiver can devote to patient care.

[0069] In some implementations, the ePCR may include 50-1000 fields for which a data entry is required (e.g., required by laws of a state or another jurisdiction and / or required for adherence to a data collection standard). The voluminous number of required fields may cause users to skip or rush through these fields, particularly in the context of an emergency response. A dedicated documentarian is typically not available in a small team of EMS responders. However, skipped, inaccurate, and / or incomplete data entry may negatively affect patient care and patient outcomes. Furthermore, such reduction or inaccuracy may result in a reduction in the accuracy and completeness of information passed from an initial emergency care encounter to a subsequent hospital encounter. Post hoc completion of the ePCR increases inaccuracies and introduces delay into the overall continuity of care provided to the patient because this practice requires the EMS caregiver to remember what transpired during the encounter and, in some instances, what portions of the ePCR have and have not been completed.

[0070] To decrease the level of effort required to complete an ePCR, among other benefits, an EMS charting system is provided that enables sharing of ePCR data between EMS agencies. It is not uncommon for multiple EMS units to be dispatched to treat a patient in urgent need of assistance. For example, a patient at the scene of a fire may be treated by first responders and later treated by a more advanced EMS crew including a paramedic. In these situations, both the first responders and the EMS crew may create, and eventually complete, an ePCR to document each respective patient encounter. The first responders may take vital signs of the patient upon arrival. The systems and methods described herein enable the later arriving EMScrew to benefit from from the treatment completed by the first responders by importing ePCR data descriptive of the patient’s vital signs from an ePCR created by the first responders. This importation may be executed even if the first responders and the EMS crew are employed by different EMS agencies.

[0071] Cross-configuration sharing of ePCR data, such as the sharing of vital signs between the first responders and the EMS crew described above, faces several technological obstacles. For instance, ePCR systems that support the creation of ePCRs store configuration data that tends to be idiosyncratic to each EMS agency. As this configuration data drives many characteristics of ePCRs generated by ePCR systems, the idiosyncrasies within the configuration data can lead to incompatibilities. For instance, a first EMS agency may not offer a treatment that a second EMS agency offers. In this situation, the configuration of the first EMS agency may omit the treatment offered by the second EMS agency and, as such, any ePCR data that records the treatment, when administered by the second EMS agency, is incompatible with - and cannot be recorded in - an ePCR created by the first EMS agency according to the configuration limitations of the first EMS agency. To overcome this obstacle, some examples described herein recognize the incompatibility and autonomously reconfigure the ePCR system configuration data of the first EMS agency to allow ePCRs generated by the ePCR system to store what would otherwise be incompatible cross-configuration ePCR data. For example, cross-configuration ePCR data may include ePCR data that originates according to a first ePCR data configuration associated with a first ePCR data structure but that is recorded in a second ePCR data structure associated with a second ePCR data configuration. The recordation occurs as the result of a data sharing or transfer between the first and second ePCRs. The second ePCR data configuration may preclude or exclude data entries directly to the second ePCR data structure that conform to the first ePCR data configuration, for example, data entries that do not originate from a share or transfer operation (non-shared or nontransferred data). Further, in some examples, the systems and methods described herein reconfigure the ePCR system configuration data in a manner that hides the changes, thereby preventing EMS providers associated with the first EMS agency from recording ePCR data that indicates performance of the treatment, even after the autonomous reconfiguration has been completed.

[0072] The systems and method described herein solve other technological problems that inhibit cross-configuration sharing of ePCR data. For instance, some examples described herein create audit trails that track the provenance of ePCR data. In doing so, these examples enable historical analysis for a variety of purposes (e.g., billing, performance analysis, etc.),even where ePCRs include data originating from multiple EMS agencies. Other examples account for the potential presence of cross-configuration ePCR data when validating ePCRs. These examples enable EMS personnel to, for example, close ePCRs that include crossconfiguration ePCR data without impact. Other benefits and advantages of the examples disclosed herein will be apparent in view of this disclosure.

[0073] FIG. 1 introduces an ePCR system 106 configured to share ePCR data between EMS agencies. As illustrated in FIG. 1, the ePCR system 106 is hosted within a cloud environment 102. The ePCR system 106 is configured to interoperate with a plurality of ePCR clients 110 hosted by computing devices 104. Individual ePCR clients 110 are depicted in FIG. 1 as ePCR client 110A and ePCR client 110N. Individual computing devices 104 are depicted in FIG 1 as computing device 104 A and computing device 104N. In some examples, the ePCR client 110A may be associated with a first EMS caregiver who works for a first EMS agency. The ePCR client 11 On may be associated with a second EMS caregiver who works for a second EMS agency distinct from the first EMS agency. Associations between individual ePCR clients 110 and an EMS caregivers may be established, for example, by authentication of the EMS caregivers to EMS caregiver accounts through the ePCR clients 110. These EMS caregiver accounts may be setup within the system 106 prior to authentication of the EMS caregivers.

[0074] Continuing with the example of FIG. 1, the ePCR system 106 includes an ePCR sharing service 108 that is configured to share, or synchronize, ePCR data between EMS agencies under certain conditions. For instance, as shown in FIG. 1, the service 108 is configured to receive ePCR data generated by the ePCR client 110A prior to a first time (e.g., Timei) and, if certain conditions are present, communicate the received ePCR data to the ePCR client 110N. In some examples, the conditions that must be present to facilitate this crossconfiguration sharing of ePCR data include temporal and geographic proximity 112 between the computing devices 104 A and 104N.

[0075] Continuing with the example of FIG. 1, an emergency call center may receive an EMS call reporting that a patient is in distress and in need of assistance. As part of handling the EMS call, systems and / or personnel at the call center may dispatch a first responder to the scene of the patient. The first responder may travel to the scene and administer care to the patient. The first responder may also create an ePCR at Timei to record the first responder’s actions on behalf of the patient. Later, an additional responder may arrive on scene at Time? to administer subsequent care to the patient and to transport the patient to a medical facility. The additional responder may also create an ePCR to record the additional responder’s actions on behalf of the patient. In this example, if Timei and Time? are within a threshold value of oneanother and locations of the computing devices 104 A and 104N come within a threshold distance of the scene while the second ePCR remains open, the service 108 may store some or all of the ePCR data stored in the first ePCR within the the second ePCR as cross-configuration ePCR data. The cross-configuration ePCR data may include indicators or otherwise be tagged or annotated to point out that the cross-configuration ePCR data was sourced from the first ePCR.

[0076] In some examples, the service 108 is configured to check for the presence of other conditions prior to sharing ePCR data between EMS agencies. More details regarding these and other examples of the service 108, and the system 106 overall, are described below.

[0077] Turning now to FIG. 2, one example of the system 106 introduced in FIG. 1 is illustrated in greater detail. As shown in FIG. 2, the system 106 includes the service 108 of FIG. 1, an ePCR system data store 204, a computer-aided dispatch (CAD) system interface 208, a validation service 214, and an ePCR system interface 202. The data store 204 includes, among other information, a plurality of EMS agency configurations 206 (shown as 206A-206N) and a sharing registry 212. The ePCR interface 202 is configured to interoperate with the ePCR clients 110 of FIG. 1. The CAD interface 208 is configured to interoperate with a CAD system 210.

[0078] In some examples, each of the interfaces 202 and 208 is configured to expose and implement an application programming interface (API) through which the system 106 can communicate with external processes. For instance, in certain examples, the interface 208 is configured to exchange messages (e.g., API calls and responses) specifying CAD data fields and CAD data field values with the CAD system 210. In these examples, the interface 208 may be configured to parse the messages to extract CAD data fields and CAD data field values. Examples of these CAD data fields and CAD data field values include patient name, patient social security number, dispatch record identifier, dispatch center, date and time of dispatch, and date and time that the scene location was reported. Furthermore, in certain examples, the interface 208 may be configured to maintain (e.g. in the data store 204) a cross-reference that associates CAD data fields with corresponding ePCR data fields. In these examples, the interface 208 may be configured to identify, via the cross-reference, ePCR data fields that correspond to extracted CAD data fields and to import data field values from the extracted CAD data fields into ePCR data fields that correspond to the extracted CAD data fields. In some examples, the clients 110 are configured to interact with users to identify extracted CAD data fields to import, as described further below with reference to FIG. 20.1

[0079] In some examples, the interface 202 is configured to exchange messages (e.g., API calls and responses) specifying ePCR data fields and ePCR data field values with the clients 110. In some examples, the interface 202 further communicates messages to the clients 110 to request specific behavior within user interface screens and controls implemented by code within the clients 110. The content of these messages varies with the implementation of the clients 110. For instance, messages communicated to the clients 110 that are browser-based or that are hybrid apps (e.g., that include an embedded browser) may include hypertext markup language (HTML) or other data that specifies user interface controls, user interface control behavior, and control layouts within the user interface screens. Additionally or alternatively, messages communicated to clients 110 that are specialized applications natively executed by a computing device (e.g., the devices 104 of FIG. 1) may include private API calls to request specific behavior within user interface screens and controls implemented by code within the clients 110. Other examples of techniques implemented by certain versions of the interface 202 to support interoperation between the system 106 and the clients 110 will be apparent in view of this disclosure. The APIs may be implemented using a variety of interoperability standards and architectural styles. For instance, in one example, the APIs are web services interfaces implemented using a REST architectural style. In this example, the APIs communicate with a client process using HTTP along with JavaScript Object Notation (JSON) and / or extensible markup language (XML). In some examples, portions of the HTTP communications can be encrypted to increase security. Alternatively or additionally, in some examples, the APIs are implemented as a .NET web API that responds to HTTP posts to particular uniform resource locators (URLs). Alternatively or additionally, in some examples, the APIs are implemented using simple file transfer protocol commands and / or a proprietary application protocol accessible via a transmission control protocol socket. Thus, the APIs described herein are not limited to a particular implementation.

[0080] In some examples, the validation service 214 is configured to validate ePCR data values prior to closure of an ePCR. In some examples, this validation may be executed on an ePCR field-by-field basis to ensure the ePCR meets requirements specified by local, state, and national standards, as well as EMS agency policies. In certain examples, the validation service is configured to handle the presence of cross-configuration ePCR data in a specialized manner, as is described below with reference to FIG. 19. It should be noted that, in some examples, the service 214 may be hosted locally with each of the clients 110, rather than within the system 106.

[0081] Continuing with examples illustrated by FIG. 2, the data store 204 is configured to store the various data elements and structures utilized by processes within the ePCR system. For instance, in some examples, the data store 204 stores ePCR data within one or more relational database tables that are at least partially normalized to reduce data redundancy. FIG.21 illustrates a subset of the tables stored in at least one example of the data store 204. As shown in FIG. 21, these tables include a cross-configuration data table 2103, an ePCR table 2105, an ePCR data fields table 2107, and a NEMSIS map table 2109. In some examples, the table 2105 includes a primary key column configured to store ePCR identifiers and one or more other columns configured to store metadata descriptive of ePCRs. This ePCR metadata may include, for example, an identifier of an EMS agency whose personnel created the ePCR. Other ePCR metadata that the table 2105 may be configured to store includes identifiers of EMS crews associated with the ePCR and timestamps that indicate times at which various events related to the ePCR occurred (e.g., EMS crew dispatch time, arrival time, and the like).

[0082] Continuing with examples illustrated by FIG. 21 , the table 2103 includes primary key columns configured to store an ePCR identifier, a key string, and a value string. In these examples, each element of cross-configuration ePCR data can be associated with a particular ePCR via ePCR identifiers stored in the tables 2103 and 2105 (e.g., via a join operation). Moreover, in some examples, each element of cross-configuration ePCR data is stored in, or identified by, a key-value pair, or an index signature, made up of the key string and the value string of a given row. As such, the table 2103 enables the system 106 to easily identify crossconfiguration ePCR data separately from other ePCR data.

[0083] Continuing with examples illustrated by FIG. 21, the table 2107 includes columns configured to store identifiers of ePCR data fields and metadata descriptive of ePCR data fields. This metadata may include, for example, locations within the data store 204 (e.g., tables and columns) that store ePCR data field values associated with the identified ePCR data fields, the type of data (string, integer, etc.) stored at the locations, and tags that associate identified ePCR data fields with JSON field names. As described further below, the associations between the ePCR data fields and the JSON field names enables synchronization between the ePCRs stored in the data store 204 and local copies of the ePCRs maintained by ePCR clients (e.g., the ePCR clients 110 of FIG. 2). Further, in some examples, the table 2109 includes columns configured to store identifiers of ePCR data fields and element numbers (identifiers) prescribed by the NEMSIS standard. In some examples, the tables 2107 and 2109 may be joined to map ePCR data field values to NEMSIS element number values, thereby enabling the system 106 to translate ePCR data to NEMSIS data.

[0084] In some examples, each of the configurations 206A-206N store configuration data for a distinct EMS agency that subscribes to the the system 106 for electronic EMS charting services. This configuration data may specify a variety of information regarding EMS agencies, such as EMS agency names, selected charting service options, and user account information. In certain examples, the configuration data includes one or more code tables that specify, among other configuration information, ePCR data fields and ePCR data field values that are authorized for storage in ePCRs generated by users associated with the EMS agency. Code tables are described further below with reference to FIG. 12. In combination, the configurations 206A-206N enable a single implementation of the system 106 to service multiple EMS agencies. In at least some examples, as referred to herein, a first EMS agency is distinct from a second EMS agency if the first EMS agency’s configuration data is stored and maintained separately from the second EMS agency’s configuration data.

[0085] In some examples, the registry 212 stores a plurality of records, each of which may specify a cross-configuration ePCR data sharing arrangement between two EMS agencies. A sharing arrangement may identify, for example, both EMS agencies involved in the sharing arrangement and whether the sharing arrangement is a one-way arrangement (e.g., in which a first EMS agency shares ePCR data with a second EMS agency but the second EMS agency does not share ePCR data with the first EMS agency) or a two-way arrangement (e.g., in which a first EMS agency shares ePCR data with a EMS second agency and the second EMS agency shares ePCR data with the first EMS agency). Moreover, a sharing arrangement may specify whether an EMS agency is authorized to read ePCR data generated by another EMS agency distinctly from whether an EMS agency is authorized to store ePCR data generated by another EMS agency. In some examples, authorization for a first EMS agency to read ePCR data generated by a second EMS agency is granted by the second EMS agency, while authorization for a first EMS agency to store ePCR data generated by a second EMS agency is granted by the first EMS agency.

[0086] As described above, in some examples, cross-configuration ePCR data may include CAD system data that is imported into an ePCR prior to the ePCR being shared between agencies. FIG. 20 illustrates a CAD importation process implemented in some examples to accomplish this objective. The process 2000 may be executed by an ePCR system (e.g., the system 106 of FIG. 1) in some examples.

[0087] As shown in FIG. 20, the process 2000 starts with the ePCR system receiving 2002 one or more dispatch records from a compatible CAD system. For instance, in some examples, a CAD interface (e.g., the interface 208 of FIG. 2) implemented by the ePCR system receivesone or more messages that indicate the generation of one or more new dispatch records. The new dispatch records may be originally generated, in some examples, via interaction between the CAD system and one or more users (e.g., one or more dispatchers). The messages may include one or more API calls communicated by the CAD system to the CAD interface. These API calls may comply with an API implemented and exposed by the CAD interface. The API calls may specify, for example, CAD data fields and CAD data field values that specify scene location information, patient data, identifiers of EMS crews dispatched to scene locations, and one or more timestamps that indicate dates and times of occurrence of events recorded by the CAD system. In some examples, upon reception of the messages, the CAD interface extracts the new dispatch records from the messages and stores the new dispatch records within an ePCR system data store (e.g., the data store 204 of FIG. 2) for subsequent processing.

[0088] Continuing with the process 2000, an ePCR interface (e.g., the interface 202 of FIG.2) filters 2004 the new dispatch records to establish potential associations between subsets of the new dispatch records and open ePCRs. For instance, in some examples, the ePCR interface searches open ePCRs stored in the ePCR system data store for one or more ePCR data field values that match one or more CAD data field values stored in the new dispatch records. CAD data fields and ePCR data field that may be compared during this search include data fields that store scene location information, patient data, timestamps, and identifiers of the EMS crews associated with the dispatch records and the ePCRs. Where the ePCR data field values match the CAD data field values, the ePCR interface may record (e.g., in the ePCR system data store) a potential association between the ePCR storing the ePCR data field values and the new dispatch record storing the CAD data field values. The conditions required to find a match between the ePCR data field values and the CAD data field values vary between examples. For instance, in some examples, an exact match between all of the ePCR data field values and the CAD data field values is required to find a match. In other examples, only a portion of the ePCR data field values and the CAD data field values are required to be similar to find a match. For instance, in at least one example, the ePCR interface is configured to find a match between a new dispatch record and an ePCR where a difference between the scene location information specified in the records is less than a threshold value. In another example, the ePCR interface is configured to find a match between a new dispatch record and an ePCR where a difference between the timestamps specified in the records is less than a threshold value. In yet another example, the ePCR interface is configured to find a match between a new dispatch record and an ePCR where a first difference between scene location information specified in the records is less than a first threshold value and a second difference between the timestamps specified inthe records is less than a second threshold value. In still another example, the ePCR interface is configured to find a match between a new dispatch record and an ePCR where there is no difference between the patient information specified in the records. In still yet another example, the ePCR interface is configured to find a match between a new dispatch record and an ePCR where there is no difference between the EMS crew identifiers specified in the records. Other examples will be apparent in view of this disclosure.

[0089] Continuing with the process 2000, the ePCR interface communicates one or more messages to an ePCR client (e.g., one of the ePCR clients 110 of FIG. 2) associated with a user (e.g., an EMS crew member) to request that the ePCR client make 2006 one or more CAD data field values available for importation into an open ePCR associated with the user. For instance, in some examples, the ePCR client responds to the messages by controlling its host device to make one or more user interface screens available for rendering in response to user input requesting importation of CAD data. These user interface screens may prompt the user to select a dispatch record of the subset of new dispatch records potentially associated with the open ePCR via execution of the operation 2004. In response to reception of such a selection, the ePCR client may store a perfected association between the dispatch record and the open ePCR. The user interface screens may further prompt the user to select one or more CAD data fields of the dispatch record for importation into corresponding ePCR data fields.

[0090] Continuing with the process 2000, the ePCR client receives 2008 selections of CAD data fields to import. For instance, in some examples, the ePCR client receives taps, clicks, or other user input that interacts with controls associated with identified CAD data fields. In these examples, in response to reception of this input, the ePCR client may communicate (e.g., via one or more API calls) a request to the ePCR interface to store 2010 values based on the selected CAD data fields in ePCR data fields that correspond to the selected CAD data fields. In some examples, the ePCR interface may, in turn, interoperate with the CAD interface to initiate the requested importation. It should be noted that, via execution of the process 2000, CAD data field values may be imported from a CAD system and may be eventually shared between agencies as cross-configuration ePCR data via processes that will now be described.

[0091] Turning now to FIG. 3A, a flow diagram of an ePCR notification process 300 is illustrated. The process 300 may be executed by an ePCR system (e.g., the system 106 of FIG.1) in some examples.

[0092] As shown in FIG. 3A, the process 300 starts with the ePCR system receiving 302 a notification of arrival of an EMS agency (e.g. the second EMS agency described above with reference to FIG. 1) at a patient encounter location. For instance, in some examples, a crew ofEMS caregivers associated with the EMS agency arrives at a scene of a patient who is the subject of an EMS call. In these and other examples, a member of the crew may interact with an ePCR client (e.g., one of the clients 110 of FIG. 1) hosted by a computing device (e.g., one of the computing devices 104 of FIG. 1) to create a new ePCRto document the crew’ s response to the EMS call. Within these interactions, the ePCR client may control its host device to render a plurality of user interface screens configured to receive input specifying ePCR data. FIGS. 4 and 5 illustrate examples of screens 400 and 500 that some examples of the ePCR client are configured to render via their host devices.

[0093] FIG. 4 is a front view of an ePCR user interface screen 400 configured to receive input specifying a scene location of a patient encounter. As shown in FIG. 4, the screen 400 includes a zone improvement plan (ZIP) code control 402, a city control 404, a state control 406, a county control 408, a street address control 410, a map service control 412, and a save control 414. In some examples, the ePCR client is configured to receive input specifying a ZIP code of the patient’s scene location via the control 402. The ePCR client may be further configured to receive input specifying the city, state, and county of the patient’s scene location via the controls 404, 406, and 408, respectively. Alternatively or additionally, the ePCR client may be further configured to automatically populate the controls 404, 406, and 408 in response to reception of input specifying a valid ZIP code via the the control 402. In certain examples, the ePCR client is configured to receive input specifying a street address of the patient’s scene location via the control 410. Further, in some examples, the ePCR client is configured to interoperate (e.g., via one or more public or partner API calls) with a third party map service (e.g., GOOGLE MAPS) in response to selection of the control 412. The map service may interact with the user to identify a mapped location for the scene, and the ePCR client may be configured to receive more precise or standardized scene location information from the map service upon completion of the map service’s interaction with the user. The ePCR client may be configured to populate or modify values of the controls 402-410 based on scene location information received from the map service. In some examples, the ePCR client is configured to stored, in response to reception of input selecting the control 414, the values of the controls 402-410 as ePCR data field values in associated ePCR data fields of the current ePCR.

[0094] FIG. 5 is a front view of an ePCR user interface dialog 500 and dialog box 504 configured to receive input specifying times at which certain events occur within an patient encounter. As shown in FIG. 5, the screen 500 includes an edit times control 502. In some examples, the ePCR client is configured to receive input selecting the control 502 and, inresponse to selection of the control 502, render (via its host device) the dialog box 504. As shown in if FIG. 5, box 504 includes a times control group 506 and a save button 508. In some examples, the ePCR client is configured to receive input, via members of the control group 506, specifying dates and times of certain events. In these examples, the ePCR client is further configured to store, within the member controls, date and time values specified by the input as the input is received. As shown, these events may include an onset event, a received event, and an on scene event, among other events. In some examples, the ePCR client is configured to store, in response to reception of input selecting the control 508, the values of the populated members of the control group 506 as ePCR data field values in associated ePCR data fields of the current ePCR.

[0095] Returning to the process 300 of FIG. 3 A, the ePCR client may also communicate a message to an ePCR interface (e.g., the interface 202 of FIG. 2) requesting creation of the new ePCR in an ePCR system data store (e.g., the data store 204 of FIG. 2). This message may include particular ePCR data specifying a variety of pertinent information, such as an identifier of the newly created ePCR, a timestamp indicating a date and time at which the ePCR was created the by the ePCR client, first location data specifying a scene location of the patient encounter, and / or second location data specifying a current location of the computing device hosting the ePCR client. Additionally or alternatively, in some examples, the ePCR client may create a local copy of the new ePCR and communicate with the ePCR interface to synchronize the local copy with a cloud-based copy of the ePCR stored in the ePCR system data store. In these examples, the ePCR client may store the local version within one or more JSON files and may periodically upload the JSON file to the ePCR interface for synchronization purposes. The ePCR interface, in turn, may be configured to parse the JSON files, extract the name-value pairs included therein, and store the extracted values within ePCR data fields associated (via the table 2107 of FIG. 21, as described above) with the names paired with the values.

[0096] Continuing with the process 300, the ePCR interface may receive and parse the message to extract the ePCR data stored therein. The ePCR interface may further record the creation of the new ePCR by storing the extracted ePCR data within a data store (e.g., the ePCR system data store 204 of FIG. 2). The ePCR interface may also communicate a message to an ePCR sharing service (e.g., the service 108 of FIG. 1) indicating the creation of the new ePCR. Alternatively or additionally, the data store may communicate a message to the ePCR sharing service indicating the creation of the new ePCR.

[0097] Continuing with the process 300, the ePCR sharing service may determine 304 whether one or more ePCRs generated by one or more other EMS agencies (e.g. the first EMSagency described above with reference to FIG. 1) exist for the patient encounter. For instance, in some examples, the ePCR sharing service may respond to a message indicating the creation of the new ePCR by interrogating the data store for other ePCRs with one or more ePCR data field values that match one or more ePCR data field values in the newly created ePCR. These other ePCRs may have been created, for example, via ePCR system interactions with users associated with other EMS agencies. In some examples, if the interrogation results in identification of one or more extant ePCRs with matching ePCR data field values, the process 300 may proceed to operation 306. If the interrogation produces no results, the process 300 may end. Examples of ePCR data fields that may be interrogated in the operation 304 include ePCR creation time fields, EMS provider arrival time fields, and scene location address fields, among others. In certain examples, the scene location address fields interrogated may include street address fields, zone improvement process (ZIP) code fields, and / or global positioning system (GPS) coordinate fields. Match determination within the operation 304 may require ePCR data field values to be identical (e.g., an exact match) or within a threshold similarity (e.g., a near match). In a particular example of the operation 304, if the interrogation results in identification of one or more extant ePCRs with a matching scene location that were created by users associated with other EMS agencies, the process 300 may proceeds to operation 306. In another particular example of the operation 304, if the interrogation results in identification of one or more extant ePCRs with a matching scene location and arrival time that were created by users associated with other EMS agencies, the process 300 may proceeds to operation 306.

[0098] Continuing with the process 300, the ePCR sharing service may determine 306 whether users associated with the EMS agency are authorized to access ePCR data generated by ePCR system interactions with users associated with other EMS agencies. For instance, in some examples, the ePCR sharing service may interrogate the data store for a crossconfiguration ePCR data sharing arrangement specifying that the first EMS agency has authorized the second EMS agency to access ePCR data generated by ePCR system interactions with users associated with the first agency. Alternatively or additionally, the ePCR sharing service may interrogate the data store for cross-configuration ePCR data sharing arrangement specifying that the second EMS agency has authorized computing devices of the second EMS agency to access ePCR data generated by ePCR system interactions with users associated with the first agency. Such cross-configuration ePCR data sharing arrangements may be created via the processes and user interface screens described further below with reference to FIGS. 16-18. If the interrogation activity results in identification of the sought after cross-configurationePCR data sharing arrangement, the process 300 may proceed to operation 310. If the interrogation produces no results, the process 300 may end.

[0099] Continuing with the process 300, the ePCR sharing service may notify 310 a user associated with the EMS agency of an extant ePCRs storing ePCR data that the user is authorized to access. For instance, in some examples, the ePCR sharing service may communicate a message to the host device of the ePCR client. The message may include one or more identifiers of one or more extant, authorized ePCRs and / or some or all of the ePCR data stored in the extant, authorized ePCRs. The ePCR client, in turn, may control the host device to render one or more user interface screens including controls configured to display content from the message or otherwise notify the user of the existence of the extant, authorized ePCRs and / or data stored within the extant, authorized ePCRs. FIG. 6, which is described further below, illustrates one example of a user interface screen 600 that the host device is configured to render for this purpose under control of the ePCR client in some examples. After completion of the operation 310, the process 300 may end.

[0100] FIG. 6 is a front view of an ePCR user interface screen 600 configured to indicate availability of ePCR data generated by a first EMS agency for importation into an ePCR created by a second EMS agency. As shown in FIG. 6, the screen 600 includes a sharing control 602. In some examples, the ePCR client is configured to render, via its host device, the control 602 within the screen 600 in response to reception of a message from the ePCR sharing service including one or more identifiers of extant, authorized ePCRs and / or some or all of the ePCR data stored in the extant, authorized ePCRs. As shown in FIG. 6, the control 602 may include a visual representation (“1”, in this example) of a number of distinct ePCRs available for sharing. In some examples, the control 602 is selectable to initiate a crossconfiguration ePCR data importation process, such as the cross-configuration ePCR data importation process 700 described below with reference to FIG. 7.

[0101] Turning now to FIG. 3B, a flow diagram of an ePCR notification process 350 is illustrated. The process 350 may be executed by an ePCR system (e.g., the system 106 of FIG.1) in some examples. As shown in FIG. 3B, the process 300 includes the operations 302, 304, and 306 of the process 300. Descriptions of these operations will not be repeated here, although it should be noted that if the interrogation executed within the operation 306 of the process 350 results in identification of the sought after cross-configuration ePCR data sharing arrangement, the process 350 may proceed to operation 308 rather than the operation 310.

[0102] Continuing with the process 350, the ePCR sharing service may determine 308 whether the EMS agency arrived in time to access ePCR data stored in the one or more extant,authorized ePCRs. For instance, in some examples, the ePCR sharing service may interrogate the data store for a new arrival time listed in the new ePCR and extant arrival times listed in the extant, authorized ePCRs and compare the new arrival time to each extant arrival time. Further in these examples, the ePCR sharing service may determine that the EMS agency arrived in time to access ePCR data stored in any extant, authorized ePCR where the extant arrival time falls within a threshold proximity (e.g., a time window) of the new arrival time. More specifically, in at least one example, the ePCR sharing service subtracts the new arrival time from each extant arrival time and determines that the EMS agency arrived in time to access ePCR data stored in any extant ePCR associated with a difference in arrival times that is less than a threshold value (e.g., 5 minutes, 10 minutes, 20 minutes, 30 minutes, 45 minutes, or an hour, in some examples). If the ePCR sharing service determines that the EMS agency arrived in time to access any extant, authorized ePCR, the process 350 may proceed to the operation 312. If the ePCR sharing service determines that the EMS agency did not arrive in time to access any extant, authorized ePCR, the process 350 may end.

[0103] Continuing with the process 300, the ePCR sharing service may notify 312 a user associated with the EMS agency of an extant ePCRs storing ePCR data that the user is authorized to access due, in part, to timely arrival. For instance, in some examples, the ePCR sharing service may communicate a message to the host device of the ePCR client. The message may include one or more identifiers of one or more extant, authorized ePCRs created in temporal proximity to the new ePCR and / or some or all of the ePCR data stored in the extant, authorized ePCRs. The ePCR client, in turn, may control the host device to render one or more user interface screens including controls configured to display content from the message or otherwise notify the user of the existence of the extant, authorized ePCRs and / or data stored within the extant, authorized ePCRs. FIG. 6, which is described above, illustrates one example of a user interface screen 600 that the host device is configured to render for this purpose under control of the ePCR client in some examples. After completion of the operation 312, the process 350 may end.

[0104] Turning now to FIG. 7, a flow diagram of a cross-configuration ePCR data importation process 700 is illustrated. The process 700 may be executed by an ePCR system (e.g., the system 106 of FIG. 1) in some examples.

[0105] As shown in FIG. 7, the process 700 starts with the ePCR system receiving 702 a selection of cross-configuration ePCR data for importation into a target ePCR. For instance, in some examples, a user associated with a second EMS agency may interact with an ePCR client (e.g., one of the clients 110 of FIG. 1) hosted by a computing device (e.g., one of the computingdevices 104 of FIG. 1) to select cross-configuration ePCR data for importation into a second, target ePCR created by interactions between the user and the ePCR client. This crossconfiguration ePCR data may be stored, for example, in a first ePCR created by interactions between another ePCR client and a user associated with a first EMS agency. More specifically, in some examples, the cross-configuration ePCR data may be stored in an extant, authorized ePCR as described above with reference to FIGS. 3A and 3B. Both the first and second ePCRs may be stored, for example, in an ePCR system data store (e.g., the data store 204 of FIG. 2).

[0106] In some examples, the ePCR client is configured to control its host device to render one or more user interface screens to facilitate selection of the cross-configuration ePCR data. One of these screens is described above with reference to FIG. 6. In certain examples, the ePCR client is configured to respond to selection of the control 602 illustrated in FIG. 6 by rendering the user interface screen 800 illustrated in FIG. 8. As shown in FIG. 8, the screen 800 includes an ePCR identification control group 802, an expand button 804, and a close button 806. The ePCR client may be configured to close the screen 800 in response to selection of the button 806. In some examples, the control group 802 includes individual controls configured to display information identifying an ePCR that is available for importation. As shown in FIG. 8, the control group 802 includes an agency control that displays an EMS agency associated with the ePCR, a category control that displays a category to which the ePCR belongs, a patient control that displays a name of a patient who is the subject of the ePCR, a DOB control that displays the date of birth of the patient, and a gender control that displays the gender of the patient.

[0107] Continuing with examples illustrated by FIG. 8, the ePCR client may be configured to respond to selection of the button 804 by rendering, via its host device, another user interface screen, such as the screen 850. As shown in FIG. 8, the screen 850 includes the control group 802, an import button 852, a dismiss button 854, and a close button 856. The ePCR client may be configured to close the screen 850 in response to selection of the button 856 or the button 854. In some examples, the button 852 is associated with an ePCR identified within the control group 802 proximal to (e.g. within the same row as) the button 852. The ePCR client may be configured to render, via its host device, the screen 800 in response to selection of the button 852.

[0108] Continuing with examples illustrated by FIG. 8, the ePCR client may be configured to respond to selection of the button 852 by rendering, via its host device, a user interface screen configured to receive input selecting ePCR data field values for importation, such as the screen 870. As shown in FIG. 8, the screen 870 includes controls configured to display ePCR datafield values from the ePCR associated with the selected button 852. A few examples of ePCR data illustrated in FIG. 8 include patient data fields and values, such as a date of birth -“1 / 1 / 1981 12:00”, gender - “Female”, weight - “90”, and type of weight measurement units -“kg”. Other examples of ePCR data illustrated in FIG. 8 include patient encounter data fields and values, such as a time at which vital signs were measured - “9 / 9 / 2024 12:00”, a patient heart rate - “90”, patient blood pressure “120 / 80”, a time at which an event occurred -“9 / 9 / 2024 12:26”, an an event type “Cardiac”. It should be noted that the scope of the examples disclosed herein is not limited to the particular examples of patient data and encounter data illustrated in FIG. 8. As such, some examples may include patient data fields configured to store other patient data (e.g., other demographic data) and encounter data fields configured to store other encounter data (e.g., other physiological measurements or EMS events).

[0109] As shown in FIG. 8, the screen 870 also includes data import controls 872A-872D, an import data button 874, and a close button 876. The ePCR client may be configured to close the screen 870 in response to selection of the button 876. In some examples, each of the controls 872A-872D may be associated with groups of ePCR data field values. For instance, as shown in FIG. 8, the control 872A is associated with patient data, the control 872B is associate with patient encounter data, the control 872C is associated with vital signs, and the control 872D is associated with the cardiac event. In some examples, the ePCR client may be configured to toggle on or off any one of the controls 872A-872D in response to reception of input selecting the control. In these examples, the ePCR client may be configured to toggle the controls 872C and 872D in response to selection of the control 872B. Further, in some examples where patient data is identified as default data, the control 872A is toggled on by default.

[0110] Continuing with examples illustrated by FIG. 8, the ePCR client may be configured to respond to selection of the button 874 by generating and communicating a message specifying ePCR data field values to be imported. This message may identify all ePCR data field values associated with any of the controls 872A-872D that are toggled on. Further, in some examples, the ePCR client may be configured to transmit the message to an ePCR sharing service (e.g., the service 108 of FIG. 1) via one or more API calls to an ePCR interface (e.g., the interface 202 of FIG. 2). In these examples, the operation 702 of FIG. 7 is complete upon reception of the message by the ePCR sharing service.

[0111] Returning to the process 700 of FIG. 7, the ePCR system may be configured to store 708 the selected cross-configuration ePCR data in the target ePCR. For instance, in some examples, the ePCR sharing service is configured to parse the message received from the ePCR client in the operation 702 to identify the ePCR data field values specified therein, generatecross-configuration ePCR data field values for the target ePCR based on the identified ePCR data field values, and store the cross-configuration ePCR data field values in the target ePCR. Further, in some examples, the ePCR sharing service is configured to store cross-configuration ePCR data field values in a data structure (e.g., a relational database table) separate from data structures housing other ePCR data field values (e.g., ePCR data field values generated via interaction between the ePCR system and users associated with the second ePCR). Storing cross-configuration ePCR data field values separately from other ePCR data enables easy identification of cross-configuration ePCR data fields, ePCR data field values, and configuration information (e.g., code table entries, which are described below with reference to FIG. 12).

[0112] Continuing with the process 700, the ePCR system marks 710 the cross-configuration ePCR data field values stored in the target ePCR as originating from an EMS agency other than an EMS agency associated with the target ePCR. For instance in some examples, the ePCR sharing service is configured to store a Boolean value within the cross-configuration ePCR data field values that indicates the cross-configuration ePCR data field values were entered prior to arrival of the computing device hosting the ePCR client at the scene location. After completion of the operation 710, the process 700 may end.

[0113] It should be noted that, in some examples, the operations 708 and 710 of the process 700 may be merged into a single operation. For instance, in some examples, the crossconfiguration ePCR data field values generated in the operation 708 may include the Boolean value indicating that the cross-configuration ePCR data field values originated from interactions between the ePCR system and a user not associated with the EMS agency associated with the target ePCR. In this case, the operation 710 is complete upon storage of the selected cross-configuration ePCR data in the target ePCR in the operation 708.

[0114] Subsequent to completion of the process 700, the ePCR client may control its host device to render a user interface screen that highlights cross-configuration ePCR data field values when displaying ePCR data. One example of such a user interface screen is illustrated in FIG. 8, as the screen 878. As shown in FIG. 8, the screen 878 includes PTA controls 880. The controls 880 indicate the patient encounter data displayed proximal to (e.g., in the same row as) the controls 880 was imported from an ePCR created by an EMS agency other than the EMS agency associated with the ePCR being displayed.

[0115] Turning now to FIG. 9 an ePCR user interface screen 900 configured to receive input selecting a first ePCR generated by a first EMS agency for importation into a second ePCR generated by a second EMS agency is illustrated. The screen 900 is similar to the screen 800described above. The screen 900 may be rendered by a computing device (e.g., one of the computing devices 104 of FIG. 1) under control of an ePCR client (e.g., one of the clients 110 of FIG. 1), in certain examples.

[0116] As shown in FIG. 9, the screen 900 includes an ePCR identification control group 902, an expand button 904, and a close button 906. The ePCR client may be configured to close the screen 900 in response to selection of the button 906. In some examples, the control group 902 includes individual controls configured to display information identifying an ePCR that is available for importation. As shown in FIG. 9, the control group 902 includes an agency control that displays an EMS agency associated with the ePCR, a category control that displays a category to which the ePCR belongs, a patient control that displays a name of a patient who is the subject of the ePCR, a DOB control that displays the date of birth of the patient, and a gender control that displays the gender of the patient. In certain examples, the ePCR client may be configured to respond to selection of the button 904 by rendering, via its host device, another user interface screen, such as the screen 1000 illustrated in FIGS. 10A and 10B.

[0117] As shown in FIGS. 10A and 10B, the screen 1000 is similar to the screen 870 of FIG.8 and includes control groups 1004 and 1006, which configured to display ePCR data field values from the ePCR associated with the selected button 904. In some examples, the control group 1004 includes controls configured to display patient data and the control group 1006 includes controls configured to display encounter data.

[0118] As shown in FIGS. 10A and 10B, the screen 1000 also includes a data import control 1002, a data import control group 1008, an import data button 1010, and close buttons 1012. The ePCR client may be configured to close the screen 1000 in response to selection of either of the buttons 1012. In some examples, the control 1002 may be associated with patient data and individual controls within the the control group 1008 may be associated with patient encounter data. In some examples, the ePCR client may be configured to toggle on or off any one of the control 1002 or individual members of the control group 1008 in response to reception of input selecting the control. In these examples, the ePCR client may be configured to toggle all members of the control group 1008 in response to selection of the top member of the control group 1008.

[0119] Continuing with examples illustrated by FIGS. 10A and 10B, the ePCR client may be configured to respond to selection of the button 1010 by generating and communicating a message specifying ePCR data field values to be imported. This message may identify all ePCR data field values associated with the control 1002 or any members of the control group 1008 that are toggled on. Further, in some examples, the ePCR client may be configured to transmitthe message to an ePCR sharing service (e.g., the service 108 of FIG. 1) via one or more API calls to an ePCR interface (e.g., the interface 202 of FIG. 2).

[0120] Turning now to FIG. 11, an ePCR user interface screen 1100 is illustrated. The screen 1100 may be configured to display ePCR data field values within a second ePCR created by a second EMS agency imported from ePCR data field values of a first ePCR generated by a first EMS agency. The screen 1100 is similar to the screen 878 described above. The screen 1100 may be rendered by a computing device (e.g., one of the computing devices 104 of FIG. 1) under control of an ePCR client (e.g., one of the clients 110 of FIG. 1), in certain examples. As shown in FIG. 11, the screen 1100 includes several ePCR control groups 1104 organized into rows and including PTA controls 1102A-1102F. The controls 1102A-1102F indicate the patient encounter data displayed proximal to (e.g., in the same row as) the controls 1102A-1102F was imported from an ePCR created by an EMS agency other than the EMS agency associated with the ePCR being displayed. As such, FIG. 11 represents a tabular chronology that includes a plurality of entries (e.g. rows) arranged in chronological order. In FIG. 11, each entry includes at least one ePCR data field value and an indication of an ePCR that originated the ePCR data field value.

[0121] Turning now to FIG. 12, processes and data stores involved in autonomous manipulation of an EMS agency’s configuration data are illustrated. These processes and data stores enable cross-configuration importation of ePCR data fields and ePCR data field values not previously authorized for use by an EMS agency.

[0122] As shown in FIG. 12, the system 106 includes the ePCR sharing service 108 of FIG.1 and the configurations 206A-206N of FIG. 2. In some examples illustrated by FIG. 12, the configuration 206 A includes an agency code table 1202 A and the configuration 206N includes an agency code table 1202N. Each of the tables 1202A-1202N is associated with an individual EMS agency. In general, an agency code table associated with an EMS agency stores configuration data for that EMS agency. This configuration data may specify, for example, ePCR data fields and / or ePCR data field values that an EMS agency has authorized and / or required for inclusion in ePCRs generated by users associated with the EMS agency. In some examples, entries within a code table authorize one or more ePCR data field values to be stored in corresponding, respective ePCR data fields. The ePCR data fields and ePCR data field values may be custom fields and values created by the EMS agency or common fields and values created by the ePCR system 106 and available for use by the EMS agency. In some examples, the ePCR data fields and ePCR data field values may include, or be associated with, standard fields and values prescribed by an EMS standard (e.g., NEMSIS) or non-standard fields notprescribed by, or associated with, any EMS standard. It should be noted that, in some examples, a code table may explicitly authorize or deny particular ePCR data field values by inclusion of an entry directed to the particular ePCR data field values. Alternatively or additionally, a code table may implicitly authorize or deny particular ePCR data field values by omission of an entry directed to the particular ePCR data field value. Use of explicit or implicit authorization or denial varies between examples of the ePCR system.

[0123] In at least some examples, each of the ePCR data fields and ePCR data field values that are authorized for use are associated with a record within an agency code table. In examples in which agency code tables are implemented within a relational database, these records may be stored as rows. As shown in FIG. 12, the agency code tables 1202A-1202N include code, value, hidden?, and standard code fields. The code field is configured to store an identifier the record. The value field is configured to store an identifier of an ePCR data field or an ePCR data field value that is the subject of the record. The hidden? field is configured to store a Boolean value that indicates whether the subject ePCR data field or ePCR data field value may be populated or entered by users associated with the agency. The standard code field is configured to store an identifier of an EMS standard (e.g., NEMSIS) data field or data field value to which the subject ePCR data field or ePCR data field value may be mapped.

[0124] As is further illustrated in FIG. 12, a first EMS agency associated with the configuration 206A has authorized use of ePCR data field values “televisit” and “radio call” for recordation within ePCR data fields that document types of medical directives received by EMS personnel. This authorization is recorded by storage of two records within the table 1202A. The record associated with the ePCR data field value “televisit” includes a record identifier of “123123” in the code field, a string “televisit” in the value field, a Boolean value of “N” in the hidden? field, and a standard (e.g., NEMSIS) data dictionary identifier of “1” in the standard code field. The combination of the record identifier and the string may be referred to as a key -value pair. It should be noted that, in some examples, the value of “N” in the hidden? field indicates that ePCR clients (e.g., the clients 110 of FIG. 1) may accept input selecting or specifying the “televisit” value for ePCR data fields that document types of medical directives received by EMS personnel. The record associated with the ePCR data field value “radio call” includes a record identifier of “123124” in the code field, a string “radio call” in the value field, a Boolean value of “N” in the hidden? field, and a standard (e.g., NEMSIS) data dictionary identifier of “1” in the standard code field. It should be noted that, in some examples, the values of “1” in the standard code fields of both records described above indicate that both “televisit”and “radio call” may be mapped to a common data field identified by “1” within a data dictionary of an applicable EMS standard.

[0125] Continuing with examples illustrated in FIG. 12, a second EMS agency associated with the configuration 206N has authorized use of ePCR data field values “televisit”, but not “radio call”, for recordation within ePCR data fields that document types of medical directives received by EMS personnel. This authorization is recorded by storage of one record within the table 1202N. The record associated with the ePCR data field value “televisit” includes a record identifier of “324234” in the code field, a string “televisit” in the value field, a Boolean value of “N” in the hidden? field, and a standard data dictionary identifier of “1” in the standard code field.

[0126] Continuing with examples illustrated in FIG. 12, if a first crew from the first EMS agency responds to an EMS call and records both “televisit” and “radio call” ePCR data field values in a first ePCR that is later selected for importation by a second crew from the second EMS agency, the lack of a record associated with “radio call” in the table 1202N would inhibit a complete cross-configuration importation of the first ePCR. In view of this technological issue, some examples of the service 108 are configured to autonomously generate and insert records into code tables during importation of cross-configuration ePCR data. FIG. 13, which is described further below, illustrates an autonomous setup process 1300 that the service 108 is configured to execute to autonomously generate and insert records in some examples. As shown in FIG. 12, upon successful completion of an autonomous setup process, such as the process 1300, the table 1202N includes a record associated with the ePCR data field value “radio call”. This record includes a record identifier of “568567” in the code field, a string “radio call” in the value field, a Boolean value of “Y” in the hidden? field, and a standard (e.g., NEMSIS) data dictionary identifier of “1” in the standard code field. It should be noted that, in some examples, the value of “Y” in the hidden? field indicates that ePCR clients (e.g., the clients 110 of FIG. 1), when interacting with users associated with the second EMS agency, may not prompt for or accept input selecting or specifying the “radio call” value for ePCR data fields that document types of medical directives received by EMS personnel. In some examples, records with a Boolean value of “Y” in the hidden? field may be referred to as hidden records. These hidden records authorize importation of ePCR data but not general use of the same. For instance, while the ePCR clients are configured to provide user interfaces to administrative users to enable editing of code tables, some implementations of the ePCR clients are configured to omit (e.g., hide) visualizations of the hidden records from these user interfaces, to prevent modification of the hidden records.

[0127] Turning now to FIG. 13, a flow diagram of the autonomous setup process 1300 is illustrated. The process 1300 may be executed by an ePCR system (e.g., the system 106 of FIG.1) in some examples. As shown in FIG. 13, the process 1300 includes the operations 702, 708, and 710 of the process 700 illustrated in FIG. 7. Descriptions of these operations will not be repeated here, although it should be noted that within the process 1300, the ePCR system proceeds from the operation 702 to operation 1304, rather than from the operation 702 to the operation 708 as occurs within the process 700. It should also be noted that within the process 1300, the ePCR system proceeds from operation 1306 to the operations 708 and 710 prior to termination.

[0128] Within the process 1300, an ePCR sharing service (e.g., the service 108 of FIG. 12) may be configured to determine 1304 whether the cross-configuration ePCR data selected for importation within the operation 702 includes importable ePCR data fields or ePCR data field values not authorized for use in the target ePCR. For instance, in some examples, the ePCR sharing service reads the selected ePCR data and creates a list (or other data structure) of ePCR data fields and ePCR data field values present within the selected ePCR data. Next, in these examples, the ePCR sharing service reads the configuration of the EMS agency associated with the target ePCR and flags any of these importable ePCR data fields or ePCR data field values in the list that are absent from the configuration. In these examples, if at least one entry in the list is flagged, the ePCR sharing service determines that the selected cross-configuration ePCR data includes unauthorized ePCR data. If the ePCR sharing service determines that crossconfiguration ePCR data includes ePCR data fields or ePCR data field values not authorized for use in the target ePCR, the ePCR sharing service proceeds to operation 1306. If the ePCR sharing service determines that cross-configuration ePCR data includes only ePCR data fields or ePCR data field values authorized for use in the target ePCR, the ePCR sharing service proceeds to operation 708.

[0129] Continuing with the process 1300, the ePCR sharing service autonomously adjusts 1306 the configuration of the EMS agency associated with the target ePCR. For instance, in some examples, the ePCR sharing service generates code table record for each ePCR data field and ePCR data field value flagged in the list and stores the generated code table records within the configuration of the EMS agency. Generation of the code table records may involve copying some or all of the code table records that authorize inclusion of the ePCR data fields and ePCR data field values flagged in the list. In some examples, the generated code table records may include a Boolean field (e.g., the hidden? field described above with reference to FIG. 12) set to a value of “Y” to signal ePCR clients (e.g., the ePCR clients of FIG. 1) to notprompt for or accept input selecting or specifying the ePCR data fields or ePCR data field values identified by generated code table records. Using this technique, the examples described herein enable an EMS agency to receive, accept, and report on cross-configuration ePCR data that includes unauthorized fields or values without authorizing the fields or values for users associated with the EMS agency.

[0130] Turning now to FIG. 14, an audit trail process 1400 is illustrated within a flow diagram. The process 1400 may be executed by an ePCR system (e.g., the system 106 of FIG.1) in some examples.

[0131] As shown in FIG. 14, the process 1400 starts with the ePCR system receiving 1402 input editing cross-configuration ePCR data stored in a target ePCR. For instance, in some examples, a user associated with a second EMS agency may interact with an ePCR client (e.g., one of the clients 110 of FIG. 1) hosted by a computing device (e.g., one of the computing devices 104 of FIG. 1) to edit cross-configuration ePCR data stored in a second ePCR. This cross-configuration ePCR data may have been created by interactions between another ePCR client and a user associated with a second EMS agency. More specifically, in some examples, the cross-configuration ePCR data may have originated from an extant, authorized ePCR as described above with reference to FIGS. 3A and 3B. Both the first and second ePCRs may be stored, for example, in an ePCR system data store (e.g., the data store 204 of FIG. 2).

[0132] In some examples, the ePCR client is configured to control its host device to render one or more user interface screens to facilitate editing of the cross-configuration ePCR data. One of these screens is illustrated in FIG. 15. As shown in FIG. 15, a vitals editing screen 1500 includes a vitals editing control group 1502, a save button 1504, a delete control 1506, and a cancel button 1508. The ePCR client may be configured to close the screen 1500 in response to selection of the button 1508. In some examples, the control group 1502 includes individual controls configured to display, and receive input specifying, information regarding various vital signs of a patient. As shown in FIG. 15, the control group 1502 includes controls configured to display date and time vital signs were taken, whether the vital signs are cross-configuration ePCR data, heart rate, method of heart rate measurement, blood pressure, method of blood pressure measurement, respiratory rate, and body temperature, to name a few controls. Other vital signs information that may be displayed or collected, and controls associated therewith, with be apparent in view of this disclosure.

[0133] In some examples, the ePCR client may be configured to control its host device to render ePCR data field values stored in the second ePCR via associated controls within the control group 1502. For instance, in certain examples, the ePCR client may be configured torender the screen 1500 in response to selection of an ePCR control group (e.g., the control group 1104 including control 1102A of FIG. 11). In these examples, the controls within the control group 1502 may be configured to display the ePCR data field values associated with the selected ePCR control group. Further, in these examples, the ePCR client may be configured to receive input specifying edits to ePCR data field values through user interaction with controls in the control group 1502. These edits may include edits to cross-configuration ePCR data, and the ePCR client may be configured to store edits specified by the input. Alternatively or additionally, the ePCR client may be configured to receive input specifying new ePCR data field values through user interaction with controls in the control group 1502 and to store the new ePCR data field values specified by the input.

[0134] Continuing with examples illustrated by FIG. 15, the ePCR client may be configured to respond to selection of either of the buttons 1504 or 1506 by communicating a message specifying ePCR data field values to be saved or deleted. If the button 1504 is selected, this message may identify ePCR data field values associated with any of the controls within the control group 1502. If the button 1504 is selected, this message may identify all ePCR data field values associated with the controls within the control group 1502. In either case, the ePCR client may be configured to transmit the message to an ePCR system interface (e.g., the interface 202 of FIG. 2) via one or more API calls. In these examples, the operation 1402 of FIG. 14 is complete upon reception of the message by the ePCR system interface.

[0135] Returning to the process 1400 of FIG. 14, the ePCR system may be configured to modify 1408 the edited cross-configuration ePCR data in the target ePCR. For instance, in some examples, the ePCR system interface is configured to parse the message received from the ePCR client in the operation 1402 to extract the ePCR data field values specified therein and store the extracted ePCR data field values in the target ePCR. The extracted ePCR data field values may include cross-configuration ePCR data field values. It should be noted that, in some examples, the ePCR system interface may be configured to associate cross-configuration ePCR data that is edited subsequent to importation with the EMS agency associated with the editor, rather than a user who originated the cross-configuration ePCR data. For instance, in examples where cross-configuration ePCR data is flagged to indicate an association between the cross-configuration ePCR data and a particular EMS agency, that flag may be removed, or replaced with a flag associated with the editor, if the cross-configuration ePCR data is edited.

[0136] Continuing with the process 1400, the ePCR system updates 1410 an audit trail including tracking information specifying manipulation (e.g., edits, insertions, deletions, etc.) of ePCR data field values. This tracking information may include identifiers of ePCR data fieldvalues manipulated, copies of original ePCR data field values before and / or after the manipulation, and identifiers of users whose interactions originated the manipulation, among other tracking information. Specific examples of tracking information may include timestamps recorded when ePCR data field values (including cross-configuration data field values) are stored within an ePCR, identifiers of ePCRs that originate cross-configuration ePCR data, identifiers of patients encountered at a scene location, identifiers of EMS providers at a scene location, and identifiers of computing devices that originate the message requesting creation of ePCRs, to name a few examples of tracking information. After completion of the operation 1410, the process 1400 may end.

[0137] It should be noted that audit trail processes, such as the process 1400, enable ePCR systems to produce reports detailing changes made to ePCR data field values and originators of the changes. This information can be particularly helpful when utilizing cross-configuration ePCR data to report on EMS agency performance and accountability.

[0138] It should also be noted that audit trail processes, such as the audit trail process 1400, may be implemented by ePCR systems to track other changes made to ePCR data. As such, in some examples, the tracking information produced by audit trail processes allow users with sufficient access to review each change made to ePCR data stored within the ePCR system and the user who initiated the change.

[0139] Turning now to FIG. 16, a cross-configuration authorization (or handshake) process 1600 is illustrated within a flow diagram. The process 1600 may be executed by an ePCR system (e.g., the system 106 of FIG. 1) in some examples.

[0140] As shown in FIG. 16, the process 1600 starts with the ePCR system receiving 1602 input from a user associated with a first EMS agency requesting adjustment of crossconfiguration ePCR data sharing with a second EMS agency. In certain examples, records of cross-configuration sharing arrangements are stored in a registry (e.g., the registry 212 of FIG.2) or other data store. In some examples, the operation 1602 may involve a user (e.g., an administrator) associated with a first EMS agency interacting with an ePCR client (e.g., one of the clients 110 of FIG. 1) hosted by a computing device (e.g., one of the computing devices 104 of FIG. 1) to request the adjustment to cross-configuration ePCR data sharing. In these examples, the ePCR client is configured to control its host device to render one or more user interface screens to facilitate entry of the input. One of these screens is illustrated in FIG. 17.

[0141] As shown in FIG. 17, a sharing setup screen 1700 includes add buttons 1702 and 1704 and delete controls 1706A-1706F. In certain examples, each of the buttons 1702 and 1704 is selectable to request authorization of a new ePCR data sharing arrangement. For instance,the control 1702 is selectable to request authorization of sharing of patient data created by “Heartland EMS” with another EMS agency, and the control 1704 is selectable to request authorization of sharing of encounter data created by “Heartland EMS” with another EMS agency. In some examples, each of the controls 1706A-1706F is selectable to request deauthorization of a currently authorized ePCR data sharing arrangement. For instance, the control 1706A is selectable to request deauthorization of sharing of patient data created by “Heartland EMS” with “Number 1 Agency”, and the control 1706B is selectable to request deauthorization of sharing of encounter data created by “Heartland EMS” with “Number 1 Agency”. Conversely, the control 1706C is selectable to request deauthorization of sharing of patient data created by “Number 1 Agency” with “Heartland EMS”, and the control 1706E is selectable to request deauthorization of sharing of encounter data created by “Number 1 Agency” with “Heartland EMS”. The control 1706D is selectable to request deauthorization of sharing of patient data created by “Number 2 Agency” with “Heartland EMS”. The control 1706F is selectable to request deauthorization of sharing of patient data created by “Number 3 Agency” with “Heartland EMS”. In some examples, the ePCR client is configured to retrieve information regarding currently authorized ePCR data sharing arrangements from the registry via one or more API calls to an ePCR interface (e.g., the interface 202 of FIG. 2).

[0142] Continuing with examples illustrated by FIG. 17, the ePCR client may be configured to respond to selection of any of the controls 1706A-1706F by communicating a message specifying an ePCR sharing arrangement to be deauthorized. For instance, in some examples, this message may identify an EMS agency to be deauthorized. In these examples, the ePCR client may be configured to transmit the message to an ePCR sharing service (e.g., the service 108 of FIG. 1) via one or more API calls to an ePCR interface. In these examples, the operation 1602 of FIG. 16 is complete upon reception of the message by the ePCR sharing service.

[0143] Alternatively or additionally, in some examples, the ePCR client may be configured to respond to selection of the control 1702 or the control 1704 by controlling its host device to render the agency selection screen 1708 illustrated in FIG. 17. As shown in FIG. 17, the screen 1708 includes an agency search control 1710, a results control 1712, a save button 1714, and a cancel button 1716. In some examples, the control 1710 is configured to receive input specifying a name or other identifier of an EMS agency with which the user wishes to establish a cross-configuration ePCR data sharing arrangement. In these examples, the ePCR client may be configured to respond to reception of input via the control 1710 by searching an ePCR system data store (e.g., the data store 204 of FIG. 2) for an EMS agency identified by the input. In some examples, the ePCR client executes this search by interoperating with the ePCRinterface via one or more API calls. Further, in these examples, the ePCR client may be configured to control its host device to display search results via the control 1712.

[0144] Continuing with examples illustrated by FIG. 17, the ePCR client may be configured to close the screen 1708 in response to selection of the button 1716. Further, in some examples, the ePCR client may be configured to respond to selection of the button 1714 by communicating a message specifying a request to establish an ePCR sharing arrangement between the EMS agency associated with the user and the EMS agency specified in the control 1712. In these examples, the ePCR client may be configured to transmit the message to the ePCR sharing service via one or more API calls to the ePCR interface. In these examples, the operation 1602 of FIG. 16 is complete upon reception of the message by the ePCR sharing service.

[0145] It should be noted that, in certain examples, the ePCR sharing service is configured to store the adjustment request with a status of “Pending” within the ePCR system data store in response to reception of the adjustment request. Further, in some examples, the ePCR sharing service is configured to acknowledge reception of the adjustment request in the operation 1602 by communicating (e.g., via one or more API calls to the ePCR interface) a message to the ePCR client that originated the adjustment request. In these examples, the ePCR client may be configured to render the screen 1720 of FIG. 17 in response to reception of the acknowledgement message. As shown in FIG. 17, the screen 1720 includes a new control group listing the EMS agency targeted for sharing, “Number 3 Agency” in this example, with a status of “Pending”. The new control group includes a delete control 1706Gto enable deletion, from the ePCR data store, of the pending adjustment request via message-coordinated execution of the ePCR client, the ePCR interface, and the ePCR sharing service.

[0146] Returning to the process 1600 of FIG. 16, the ePCR system may be configured to determine 1604 whether the adjustment requested in operation 1602 requires approval. For instance, in some examples, a request generated by a first EMS agency to deauthorize an ePCR sharing arrangement with a second EMS agency does not require approval of a second EMS agency, but a request generated by the first EMS agency to authorize an ePCR sharing arrangement with the second EMS agency does require approval of the second EMS agency. In these examples, the ePCR sharing service analyzes the requested adjustment and if the adjustment is a request to deauthorize an ePCR sharing arrangement, the ePCR sharing service proceeds to operation 1612. Further, if the adjustment is a request to authorize an ePCR sharing arrangement, the ePCR sharing service proceeds to operation 1606.

[0147] Continuing with the process 1600, the ePCR system may be configured to request 1606 approval of the adjustment request by the second EMS agency. For instance, in some examples, the ePCR sharing service generates and communicates (e.g., via the ePCR interface) a message to an ePCR client associated with a user of the second EMS agency. In certain examples, the ePCR client may be configured to control its host device to render the screen 1750 illustrated in FIG. 17 in response to reception of the message. As shown in FIG. 17, the screen 1750 includes an approval control 1752. In these examples, the operation 1606 is complete upon display of the control 1752.

[0148] Continuing with the process 1600, the ePCR system may be further configured to receive 1608 a response to the approval request from the second EMS agency. For instance, in some examples, the ePCR client is configured to record an approval of the adjustment request in response to a selection of the control 1752 and to record a disapproval of adjustment request in response to a selection of the control 1754. In certain examples, approval of the adjustment request may indicate that the second EMS agency authorizes the first EMS agency to read cross-configuration ePCR data generated by the second agency. In some examples, the ePCR client is configured to communicate to the ePCR sharing service, via one or more API calls to the ePCR interface, a message specifying whether the recordation request was approved or disapproved by the second EMS agency.

[0149] It should be noted that, in some examples of the operation 1608, the ePCR sharing service may confirm that the user who initiated the operation 1602 authorizes storage, in ePCRs associated with the first EMS agency, of cross-configuration ePCR data shared by the second EMS agency. For instance, in some examples, an ePCR client associated with the first EMS agency is configured to control its host device to render the dialog 1800 illustrated in FIG. 18 in response to a selection of the control 1752. As shown in FIG. 18, the dialog 1800 includes a cancel control 1802 and an OK control 1804. In these examples, the ePCR client is configured to record confirmation of the adjustment request in response to a selection of the control 1804 and to record a denial of the adjustment request in response to a selection of the control 1802. In certain examples, confirmation of the adjustment request may indicate that the first EMS agency authorizes users associated with the first EMS agency to store cross-configuration ePCR data generated by the second agency in ePCRs associated with the first agency . In some examples, the ePCR client is configured to communicate, via one or more API calls, a message specifying whether the recordation request was confirmed or denied by the first EMS agency to the ePCR sharing service via the ePCR interface.

[0150] Continuing with the process 1600, the ePCR system may be further configured to determine 1610 whether the adjustment request was approved and confirmed. For instance, in certain examples, the ePCR sharing service receives, via the ePCR interface, the messages generated in the operation 1608 specifying whether the recordation request was approved and confirmed. In these examples, the ePCR sharing service is configured to parse the messages to determine whether the adjustment request was approved and confirmed. If the ePCR sharing service determines that the adjustment request was approved and confirmed, the ePCR sharing service proceeds to the operation 1612. If the ePCR sharing service determines that the adjustment request was disapproved or denied, the ePCR sharing service may mark the pending adjustment request with a disapproved or denied status within the ePCR system data store, and the process 1600 may end.

[0151] Continuing with the process 1600, the ePCR system may be further configured to record 1612 the approved adjustment request. For instance, in some examples, the ePCR sharing service may store a record of the cross-configuration ePCR data sharing arrangement in the registry. The cross-configuration ePCR data sharing arrangement may specify, for example, both EMS agencies involved in the ePCR data sharing arrangement and whether the ePCR data sharing arrangement is a one-way arrangement or a two-way arrangement. Further, in certain examples, the ePCR data service may remove the pending status of the adjustment request in the ePCR system data store as part of the operation 1612. In this way, subsequent renderings of the screen 1720 of FIG. 17 will, for example, omit the string “Pending” from the new control group. Upon completion of the operation 1612, the process 1600 may end.

[0152] Turning now to FIG. 19, a flow diagram of an ePCR validation process 1900 is illustrated. The process 1900 may be executed by an ePCR system (e.g., the system 106 of FIG.1) in some examples.

[0153] As shown in FIG. 19, the process 1900 starts with a validation service (e.g., the service 214 of FIG. 2) receiving 1902 a request to close an ePCR. For instance, in some examples, an ePCR client (e.g., one of the clients 110 of FIG. 1) hosted by a computing device (e.g., one of the computing devices 104 of FIG. 1) receives input requesting closure of an ePCR. In these examples, the ePCR client is configured to generate and communicate, via one or more API calls, a message to an ePCR interface (e.g., the ePCR interface 202 of FIG. 2) requesting closure of the ePCR. The message may specify an identifier of the ePCR. Further, in these examples, the ePCR interface may parse the message to extract the identifier of the ePCR and communicate a message specifying the identifier to the validation service. The message may request validation the ePCR.

[0154] Continuing with the process 1900, the validation service reads 1904 the next, unprocessed ePCR data field value of the ePCR. For instance, in some examples, the validation service receives and parses the message from the ePCR interface to extract the identifier of the ePCR and interoperates with an ePCR data store (e.g., the data store 204) to retrieve the next, unprocessed ePCR data file value of the ePCR.

[0155] Continuing with the process 1900, the validation service determines 1906 whether a validation rule is invoked by the ePCR data field value. For instance, in some examples the validation service interrogates the data store for validation rules associated with the ePCR data field value and / or the ePCR data field that holds the ePCR data field value. In these examples, if the validation service identifies one or more validation rules associated with the ePCR data field and / or ePCR data field value, the validation service proceeds to operation 1908. Further, in these examples, if the validation service fails to identify one or more validation rules associated with the ePCR data field and / or ePCR data field value, the validation service proceeds to operation 1914.

[0156] Continuing with the process 1900, the validation service determines 1908 whether the ePCR data field value is a cross-configuration ePCR data field value. For instance, in some examples, the validation service checks for a flag, or other data element, that indicates the ePCR data field value is cross-configuration ePCR data. Such data elements may be read by the validation service as part of the operation 1904 described above. In certain examples, if the validation service determines that the ePCR data field value is cross-configuration ePCR data, the validation service proceeds to operation 1910. Further, in these examples, if the validation service determines that the ePCR data field value is not cross-configuration ePCR data, the validation service proceeds to operation 1912.

[0157] Continuing with the process 1900, the validation service skips 1910 validation of the ePCR data field value. For instance, in some examples, the validation service skips validation by not evaluating a validation rule associated with the ePCR data field value. In certain examples, the valuation service may skip a validation rule normally invoked by the ePCR data field value. In a specific example, the validation service may skip a validation rule that requires an ePCR data field identified by the rule to be populated if one or more ePCR data field values are present. In another specific example, the valuation service may skip a validation rule that requires an identified ePCR data field to be populated if an EMS call type identified in the ePCR matches a target EMS call type and the set of ePCR data field values comprises a value of NULL for the identified ePCR data field. Other examples will be apparent in view of thisdisclosure. In at least some examples, the validation service records whether a validation rule was skipped within a validation results data structure.

[0158] Continuing with the process 1900, the validation service attempts to validate 1912 the ePCR data field value. For instance, in some examples, the validation service evaluates a validation rule invoked by the ePCR data field value. The validation rule may require the ePCR and the ePCR data field values included in the rule to be in a state specified by the validation rule. In some examples, the validation rule evaluates to a Boolean value. In at least some examples, the validation service records success or failure of the attempted validation in the validation results data structure.

[0159] Continuing with the process 1900, the validation service determines 1914 whether ePCR data field values within the ePCR remain unprocessed by this instance of the process 1900. For instance, in some examples the validation service interrogates the data store to make this determination. In certain examples, if the validation service determines that unprocessed ePCR data field values remain, the validation service returns to operation 1904. Further, in these examples, if the validation service determines that no unprocessed ePCR data field values remain, the validation service proceeds to operation 1916.

[0160] Continuing with the process 1900, the validation service reports 1916 validation results to a subsequent process of the ePCR system, such as a process configured to close the ePCR.Example Computing and Medical Devices

[0161] Referring to FIG. 22, a block diagram of examples of computing and medical device components are shown schematically.

[0162] The medical device 132 can include a processor 2021, a memory 221, one or more output devices 2030, one or more user input devices 244, and a communications interface 245. The communications interface 245 can include any of a variety of transmitters and / or receivers. For instance, in some examples, the communications interface 245 includes one or more of an NFC tag, an RFID tag, a barcode, and a QR code.

[0163] In various implementations, the medical devices 132 can include a defibrillator, patient monitor, defibrillator / monitor, an automated compression device, a therapeutic cooling device, an extracorporeal membrane oxygenation (ECMO) device, a ventilation device, combinations thereof, or another type of medical device configured to couple to one or more therapy delivery components to provide therapy to the patient. In an implementation, the medical devices 132 can include an integrated therapy delivery / monitoring device within asingle housing 280. The single housing 280 can surround, at least in part, a patient interface device signal processor 2056 and / or a therapy delivery control 255.

[0164] The patient interface devices 1190 can include one or more therapy delivery component(s) 261a and / or one or more sensor device(s) 261b. The medical device 132 can be configured to couple to the one or more therapy delivery component(s) 261a. In combination, the medical device 132 and the one or more therapy delivery components can provide therapeutic treatment to a patient. In an implementation, the medical device 132 can include or incorporate the therapy delivery component(s) 261a. The therapy delivery component(s) 261a are configured to deliver therapy to the patient and can be configured to couple to the patient. For example, the therapy delivery component(s) 261a can include one or more of electrotherapy electrodes including defibrillation electrodes and / or pacing electrodes, chest compression devices (e.g., one or more belts or a piston), ventilation devices (e.g., a mask and / or tubes), drug delivery devices, etc. The medical device 132 can include the one or more therapy delivery component(s) 261a and / or can be configured to couple to the one or more therapy delivery component(s) 261a in order to provide medical therapy to the patient. The therapy delivery component(s) 261a can be configured to couple to the patient. For example, a care provider may attach the electrodes to the patient, and the medical device 132 (e.g., a defibrillator or defibrillator / patient monitor) may provide electrotherapy to the patient via the defibrillation electrodes. These examples are not limiting of the disclosure as other types of medical devices, therapy delivery components, sensors, and therapy are within the scope of the disclosure.

[0165] The medical devices 132 can include, for example, a therapeutic medical device capable of delivering a medical therapy. For example, the medical therapy can be electrical therapy (e.g. defibrillation, cardiac pacing, synchronized cardioversion, diaphragmatic or phrenic nerve stimulation) and the medical devices 132 can include a defibrillator, a defibrillator / monitor and / or another medical device configured to provide electrotherapy. As another example, the medical therapy can be chest compression therapy for treatment of cardiac arrest and the medical device 132 can be a mechanical chest compression device such as a beltbased chest compression device or a piston-based chest compression device. As other examples, the medical therapy can be ventilation therapy, therapeutic cooling or other temperature management, invasive hemodynamic support therapy (e.g. Extracorporeal Membrane Oxygenation (ECMO)), etc. and the medical device 132 can be a device configured to provide a respective therapy. In an implementation, the medical device 132 can be a combination of one or more of these examples. The therapeutic medical device can includepatient monitoring capabilities via one or more sensors. These types of medical therapy and devices are examples only and not limiting of the disclosure.

[0166] The medical devices 132 can include, incorporate, and / or be configured to couple to the one or more sensor(s) 261b which can be configured to couple to the patient. The sensor(s) 261b are configured to provide signals indicative of sensor data to the medical device 132. The sensor(s) 261b can be configured to couple to the patient. For example, the sensor(s) 261b can include cardiac sensing electrodes, a chest compression sensor, and / or ventilation sensors. The one or more sensors 261b can generate signals indicative of physiological parameters of the patient. For example, the physiological parameters can include one or more of at least one vital sign, an ECG, blood pressure, heart rate, pulse oxygen level, respiration rate, heart sounds, lung sounds, respiration sounds, tidal CO2, saturation of muscle oxygen (SMO2), arterial oxygen saturation (SpO2), cerebral blood flow, electroencephalogram (EEG) signals, brain oxygen level, tissue pH, tissue fluid levels, physical parameters as determined via ultrasound images, parameters determined via near-infrared reflectance spectroscopy, pneumography, and / or cardiography, etc. Additionally or alternatively, the one or more sensors 261b can generate signals indicative of chest compression parameters, ventilation parameters, drug delivery parameters, fluid delivery parameters, etc.

[0167] In addition to delivering therapy to the patient, the therapy delivery component(s) 261a can include, be coupled to, and / or function as sensors and provide signals indicative of sensor data (e.g., second sensor data) to the medical device 132. For example, the defibrillation electrodes can be configured as cardiac sensing electrodes as well as electrotherapy delivery devices and can provide signals indicative of transthoracic impedance, ECG, heart rate and / or other physiological parameters. As another example, a therapeutic cooling device can be an intravenous cooling device. Such a cooling device can include an intravenous (IV) device as a therapy delivery component configured to deliver cooling therapy and sense the patient’s temperature. For example, the IV device can be a catheter that includes saline balloons configured to adjust the patient’s temperature via circulation of temperature controlled saline solution. In addition, the catheter can include a temperature probe configured to sense the patient’s temperature. As a further example, an IV device can provide therapy via drug delivery and / or fluid management. The IV device can also monitor and / or enabling monitoring of a patient via blood sampling and / or venous pressure monitoring (e.g., central venous pressure (CVP) monitoring).

[0168] The medical devices 132 can be configured to receive the sensor signals (e.g., from the therapy delivery component(s) 261a and / or the sensor(s) 261b) and to process the sensorsignals to determine and collect the patient data. The patient data can include patient data which can characterize a status and / or condition of the patient (e.g., physiological data such as ECG, heart rate, respiration rate, temperature, pulse oximetry, non-invasive hemoglobin parameters, capnography, oxygen saturation (SpO2), end tidal carbon dioxide (EtCO2), invasive blood pressure (IBP), non-invasive blood pressures (NffiP), tissue pH, tissue oxygenation, Near Infrared Spectroscopy (NIRS) measurements, etc.). Additionally or alternatively, the patient data can characterize the delivery of therapy (e.g., chest compression data such as compression depth, compression rate, etc.) and / or the patient data can characterize a status and / or condition of the medical equipment used to treat the patient (e.g., device data such as shock time, shock duration, attachment of electrodes, power-on, etc.).

[0169] In some examples, the components of 2021, 221, 2030, 244, 245, and 255 of the medical device 132 are communicatively coupled (directly and / or indirectly) to each other for bi-directional communication.

[0170] Although shown as separate entities in FIG. 22, the one or more of the components of the medical device 132 can be combined into one or more discrete components and / or can be part of the processor 2021. The processor 2021 and the memory 221 can include and / or be coupled to associated circuitry to perform the functions described herein.

[0171] In an implementation, the medical devices 132 can include a therapeutic medical device configured to deliver medical therapy to the patient. Thus, the medical devices 132 can optionally include the therapy delivery control module 255. For example, the therapy delivery control module 255 can be an electrotherapy delivery circuit that includes one or more capacitors configured to store electrical energy for a pacing pulse or a defibrillating pulse. The electrotherapy delivery circuit can further include resistors, additional capacitors, relays and / or switches, electrical bridges such as an H-bridge (e.g., including a plurality of insulated gate bipolar transistors or IGBTs), voltage measuring components, and / or current measuring components. As another example, the therapy delivery control module 255 can be a compression device electro-mechanical controller configured to control a mechanical compression device. As a further example, the therapy delivery control module 255 can be an electro-mechanical controller configured to control drug delivery, temperature management, ventilation, and / or other type of therapy delivery. Alternatively, some examples of the medical devices 132 may not be configured to deliver medical therapy to the patient but can be configured to provide patient monitoring and / or diagnostic care. As shown in FIG. 22, in some examples, the therapy delivery control 255 exchanges messages 1180 with the charting device 175 (e.g., the patient charting device). These messages can include patient data descriptive oftherapy provided to the patient or other patient data stored on the medical devices 132. This patient data can be used by an ePCR application in generating an ePCR documenting a dispatched EMS event.

[0172] The medical devices 132 can incorporate and / or be configured to couple to one or more patient interface devices 1190. The patient interface devices 1190 can include one or more therapy delivery component(s) 261a and one or more sensor(s) 261b. The one or more therapy delivery component(s) 261a and the one or more sensor(s) 261b sensor can provide one or more signals to the medical devices 132 via wired and / or wireless connect! on(s).

[0173] The one or more therapy delivery component(s) 261a can include electrotherapy electrodes (e.g., the electrotherapy electrodes 266a), ventilation device(s) (e.g., the ventilation devices 266b), intravenous device(s) (e.g., the intravenous devices 266c), compression device(s) (e.g., the compression devices 266d), etc. For example, the electrotherapy electrodes can include defibrillation electrodes, pacing electrodes, and / or combinations thereof. The ventilation devices can include a tube, a mask, an abdominal and / or chest compressor (e.g., a belt, a cuirass, etc.), etc. and combinations thereof. The intravenous devices can include drug delivery devices, fluid delivery devices, and combinations thereof. The compression devices can include mechanical compression devices such as abdominal compressors, chest compressors, belts, pistons, and combinations thereof. In various implementations, the therapy delivery component(s) 261a can be configured to provide sensor data and / or be coupled to and / or incorporate sensors. For example, the electrotherapy electrodes can provide sensor data such as transthoracic impedance, ECG, heart rate, etc. Further the electrotherapy electrodes can include and or be coupled to a chest compression sensor. As another example, the ventilation devices can be coupled to and / or incorporate flow sensors, gas species sensors (e.g., oxygen sensor, carbon dioxide sensor, etc.), etc. As a further example, the intravenous devices can be coupled to and / or incorporate temperature sensors, flow sensors, blood pressure sensors, etc. As yet another example, the compression devices can be coupled to and / or incorporate chest compression sensors, patient position sensors, etc. The therapy delivery control module 255 can be configured to couple to and control the therapy delivery component(s) 261a.

[0174] In various implementations, the sensor(s) 261b can include one or more sensor devices configured to provide sensor data that includes, for example, but not limited to ECG, blood pressure, heart rate, pulse oxygen level, respiration rate, heart sounds, lung sounds, respiration sounds, tidal CO2, saturation of muscle oxygen (SMO2), arterial oxygen saturation (SpO2), cerebral blood flow, electroencephalogram (EEG) signals, brain oxygen level, tissue pH, tissue fluid levels, images and / or videos via ultrasound, laryngoscopy, and / or other medicalimaging techniques, near-infrared reflectance spectroscopy, pneumography, cardiography, and / or patient movement. Images and / or videos can be two-dimensional or three-dimensional.

[0175] The sensor(s) 261b can include sensing electrodes (e.g., the sensing electrodes 262), ventilation sensors (e.g., the ventilation sensors 264), temperature sensors (e.g., the temperature sensor 267), chest compression sensors (e.g., the chest compression sensor 268), etc. For example, the sensing electrodes can include cardiac sensing electrodes. The cardiac sensing electrodes can be conductive and / or capacitive electrodes configured to measure changes in a patient’s electrophysiology, for example to measure the patient’s ECG information. In an implementation, the sensing electrodes can be configured to measure the transthoracic impedance and / or a heart rate of the patient. The ventilation sensors can include spirometry sensors, flow sensors, pressure sensors, oxygen and / or carbon dioxide sensors such as, for example, one or more of pulse oximetry sensors, oxygenation sensors (e.g., muscle oxygenation / pH), 02 gas sensors and capnography sensors, and combinations thereof. The temperature sensors can include an infrared thermometer, a contact thermometer, a remote thermometer, a liquid crystal thermometer, a thermocouple, a thermistor, etc. and can measure patient temperature internally and / or externally. The chest compression sensor can include one or more motion sensors including, for example, one or more accelerometers, one or more force sensors, one or more magnetic sensors, one or more velocity sensors, one or more displacement sensors, etc. The chest compression sensor can be, for example, but not limited to, a compression puck, a smartphone, a hand-held device, a wearable device, etc. The chest compression sensor can be configured to detect chest motion imparted by a rescuer and / or an automated chest compression device (e.g., a belt system, a piston system, etc.). The chest compression sensor can provide signals indicative of chest compression data including displacement data, velocity data, release velocity data, acceleration data, compression rate data, dwell time data, hold time data, blood flow data, blood pressure data, etc. In an implementation, the sensing electrodes and / or the electrotherapy electrodes can include or be configured to couple to the chest compression sensor.

[0176] Continuing with FIG. 22, examples of components of the charting device 175 are shown schematically. In an implementation, the charting device 175 can be configured as a computing device. The charting device 175 can include a processor 427, a memory 421, one or more output devices 437, one or more user input devices 447, and a communications interface 445. In some examples, the charting device may further include a global position system (GPS) receiver or other subsystem configured to generate location and time data based on interactions with GPS satellites. FIG. 22 also illustrates schematic examples of componentsof the computing device 107. As shown in FIG. 22, the computing device 107 can include a processor 2020, a memory 321, one or more output devices 330, one or more user input devices 344, and a communications interface 345. FIG. 22 further illustrates schematic examples of components of the server(s) 2108. As shown in FIG. 22, the server(s) 2108 can include a processor 520, a memory 521, one or more output devices 530, one or more user input devices 544, and a communications interface 545.

[0177] Each of the charting device 175 (e.g., the charting device) and the computing device 107 can be a computer system, such as a desktop, notebook, mobile, portable, or other type of computing system. Each of these devices 175 and 107 can include server(s) and / or access server(s) via a monitor and / or other connected user interface device. Although described as server(s), the server(s) 2108 can be another type of computing system including for example a desktop, notebook, mobile, portable, or other type of computing system.

[0178] As shown in FIG. 22, each of the devices 175 and 107, along with the server(s) 2108 and the medical devices 132, includes a bus or other interconnection mechanism that communicably couples the processor, memory, output devices, input devices, and communication interface included therein. The bus can include a PCI / PCI-X or SCSI based system bus depending on the storage devices used, for example.

[0179] The processors 2021, 2020, 427, and 520 can each include a processor, such as, but not limited to, an Intel® Itanium® or Itanium 2® processor(s), or AMD® Opteron® or Athlon MP® processor(s), or any of a Motorola ® line of processors. The communication interfaces 245, 345, 445, and 545 can each be any of an RS-232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, or a Gigabit port using copper or fiber, for example. The communication interfaces 245, 345, 445, and 545 may be chosen depending on a network(s) such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the medical devices 132, the charting device 175, the computing device 107, and / or the server(s) 2108 may connect. The memories 221, 321, 421, and 521 can be Random Access Memory (RAM), Read Only Memory (ROM), Flash memory, and / or another dynamic volatile and / or non-volatile storage device(s). The memories 221, 321, 421, and 521 can be used to store information and instructions. For example, hard disks such as the Adaptec® family of SCSI drives, an optical disc, an array of disks such as RAID (e.g. the Adaptec family of RAID drives), or any other mass storage devices may be used. The components described above are meant to exemplify some types of possibilities. In no way should the aforementioned examples limit the scope of the disclosure. The memories 221, 321, 421, and 521 can further include removable storage media such as external hard-drives, floppy drives, flash drives, IOMEGA®Zip Drives, Compact Disc - Read Only Memory (CD-ROM), Compact Disc - Re-Writable (CD-RW), or Digital Video Disk - Read Only Memory (DVD-ROM), for example.

[0180] Continuing with FIG. 22, the server(s) 2108 can include, for example, the one or more storage server(s) and one or more application server(s). In some examples, the server(s) 2108 are configured to exchange messages 1170 with the computing device 107. These messages can include charting and / or case data as described above. In some examples, the server(s) 2108 are configured to exchange messages 1160 with the charting device 175 via an ePCR API. These messages can include data descriptive of ePCRs generated by the charting device 175. In some examples, the server(s) 2108 are configured to exchange messages 1195 with the medical devices 132. These messages can include data descriptive of a patient being treated via the medical device and / or treatment being delivered by the medical devices 132.

[0181] Some examples of the present disclosure include various steps, some of which can be performed by hardware components or can be embodied in machine-executable instructions. These machine-executable instructions can be stored on a non-transitory data storage medium and can be used to cause a general-purpose or a special-purpose processor programmed with the instructions to perform the steps. The non-transitory data storage medium can further store an operating system and the machine-executable instructions can be included within one or more software applications or programs, such as the ePCR application. These programs can implement the features disclosed herein and the methods that they execute. Alternatively, the steps can be performed by a combination of hardware, software, and / or firmware, on one device and / or distributed across multiple devices and / or processors. In addition, some examples of the present disclosure can be performed or implemented, at least in part (e.g., one or more modules), on one or more computer systems, mainframes (e.g., IBM mainframes such as the IBM zSeries, Unisys ClearPath Mainframes, HP Integrity NonStop server(s), NEC Express series, and others), or client-server type systems. In addition, specific hardware aspects of examples of the present disclosure can incorporate one or more of these systems, or portions thereof.

[0182] Various modifications and additions can be made to the exemplary embodiments discussed without departing from the scope of the present disclosure. For example, while the embodiments described above refer to particular features, the scope of the disclosure also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present disclosure is intended to embrace all such alternatives, modifications, and variations as fall within the scope of the claims, together with all equivalents thereof.

[0183] It should be noted that the devices described herein can be used in medical settings other than EMS. For instance, some examples can be useful in hospital, clinic, military medical treatment, home, and other non-EMS settings. It should also be noted that EMS care can include both emergency care (e.g., car accident, cardiac arrest, overdose, etc.) and scheduled non-emergency care like a transport for dialysis, chemotherapy, physical therapy, and the like.

[0184] Having thus described several aspects of at least one example, it is to be appreciated that various alterations, modifications, and improvements will readily occur to those skilled in the art. For instance, examples disclosed herein can also be used in other contexts. Such alterations, modifications, and improvements are intended to be part of this disclosure and are intended to be within the scope of the examples discussed herein. Accordingly, the foregoing description and drawings are by way of example only.

Claims

CLAIMS1. A system for sharing patient care record (ePCR) data between emergency medical services (EMS) agencies, the system comprising:a memory storinga first EMS system configuration of a first EMS agency, anda second EMS system configuration of a second EMS agency, the first EMS system configuration being distinct from the second EMS system configuration; at least one network interface; andat least one processor coupled with the at least one network interface and the memory and configured toreceive, via the at least one network interface, a message requesting creation of a second ePCR associated with a scene location and the second EMS system configuration,identify a first ePCR created before the second ePCR and associated with the scene location and the first EMS system configuration,determine that the second EMS system configuration authorizes access to ePCR data associated with the first EMS system configuration, andstore a set of cross-configuration ePCR data field values from the first ePCR within the second ePCR.

2. The system of claim 1, wherein to identify the first ePCR comprises to compare at least one first ePCR data field value recorded in the first ePCR to at least one second ePCR data field value recorded in the second ePCR.

3. The system of claim 2, wherein:the at least one first ePCR data field value is a time of arrival at the scene location recorded in the first ePCR;the at least one second ePCR data field value is a time of arrival at the scene location recorded in the second ePCR; andto compare comprises to determine whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the arrival at the scene location recorded in the second ePCR transgresses a threshold value.

4. The system of claim 2, wherein:the at least one first ePCR data field value is a time of arrival at the scene location recorded in the first ePCR;the at least one second ePCR data field value is a time of ePCR creation recorded in the second ePCR; andto compare comprises to determine whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the ePCR creation recorded in the second ePCR transgresses a threshold value.

5. The system of claim 2, wherein:the at least one first ePCR data field value is a first address of the scene location; the at least one second ePCR data field value is a second address of the scene location; andto compare comprises to determine whether the first address matches the second address.

6. The system of claim 5, wherein:the first address is a first text string; andthe second address is a second text string.

7. The system of claim 6, wherein:the first text string comprises a first zone improvement project (ZIP) code and a first street address; andthe second text string comprises a second ZIP code and a second street address.

8. The system of any of claims 2-7, further comprising a user interface configured to receive input specifying the second ePCR data field value.

9. The system of claim 8, wherein to receive the input comprises to receive gesture-based alphanumeric input.

10. The system of claim 2, wherein:the first ePCR data field value is a first set of global positioning system (GPS) coordinates;the second ePCR data field value is a second set of GPS coordinates; andto compare comprises to determine whether the first set of GPS coordinates matches the second set of GPS coordinates.

11. The system of claim 2, further comprising a computer-aided dispatch (CAD) system, wherein the at least one processor is configured to:receive, via the at least one network interface, one or more messages from the CAD system;parse the one or more messages to extract a CAD data field value; andstore the CAD data field value in the second ePCR as the at least one second ePCR data field value.

12. The system of claim 1, wherein:the at least one processor is configured to receive one or more selections of one or more ePCR data fields from the first ePCR; andto store the set of cross-configuration ePCR data field values comprises tostore, within the second ePCR, first cross-configuration ePCR data field values from a default set of ePCR data fields in the first ePCR, andstore, within the second ePCR, second cross-configuration ePCR data field values from the one or more ePCR data fields.

13. The system of claim 12, wherein:the default set of ePCR data fields comprises patient data fields; andthe one or more ePCR data fields comprises one or more encounter data fields.

14. The system of claim 13, wherein the one or more encounter data fields comprise one or more of physiological measurement data fields and EMS event data fields.

15. The system of claim 1, wherein to store the set of cross-configuration ePCR data field values comprises to flag each ePCR data field value of the set as originating from the first ePCR.

16. The system of claim 15, further comprising a user interface configured to provide the set of cross-configuration ePCR data field values for editing.

17. The system of claim 16, wherein the user interface is configured to remove a flag for each ePCR data field value that is edited.

18. The system of claim 16, wherein the user interface is configured to record an audit trail of events associated with the set of cross-configuration ePCR data field values.

19. The system of claim 18, wherein the audit trail comprises one or more of a timestamp recorded when the set of cross-configuration ePCR data field values was stored within the second ePCR, an identifier of the first ePCR, one or more identifiers of one or more patients encountered at the scene location, an identifier of an EMS provider at the scene location, and an identifier of a computing device that originated the message requesting creation of a second ePCR.

20. The system of claim 1, further comprising a user interface configured to provide a tabular chronology that comprises a plurality of entries arranged in chronological order, each entry of the plurality of entries indicating an ePCR that originated the entry and being representative of either an ePCR data field value of the set of cross-configuration ePCR data field values or another ePCR data field value stored in the second ePCR.

21. The system of claim 1, wherein the at least one processor is further configured to determine that at least one importable ePCR data field value from the set of crossconfiguration ePCR data field values is absent from the second EMS system configuration.

22. The system of claim 21, wherein:the second EMS system configuration stores a code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the second ePCR;the importable ePCR data field value is authorized for storage within a respective ePCR data field of the first ePCR according to the first EMS system configuration and unauthorized for storage within a respective ePCR data field of the second ePCR according to the second EMS system configuration; andthe at least one processor is configured to add at least one hidden record to the code table specifying that the importable ePCR data field value is authorized for importation into the respective ePCR data field of the second ePCR.

23. The system of claim 22, wherein:the code table is a second code table;the first EMS system configuration stores a first code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the first ePCR; and to add the at least one hidden record to the second code table comprises to identify at least one existing record in the first code table specifying the importable ePCR data field value,copy at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, andmark the at least one new record in the second code table as hidden.

24. The system of claim 21, wherein:the second EMS system configuration stores a code table specifying ePCR data fields authorized for inclusion within the second ePCR;the set of cross-configuration ePCR data field values from the first ePCR comprises at least one ePCR data field for an ePCR data field not specified within the code table; and the at least one processor is configured to add at least one hidden record to the code table specifying that the at least one ePCR data field is authorized for importation into the second ePCR.

25. The system of claim 24, wherein:the code table is a second code table;the first EMS system configuration stores a first code table specifying ePCR data fields authorized for inclusion within the first ePCR; andto add the at least one hidden record to the second code table comprises to identify at least one existing record in the first code table specifying the at least one ePCR data field,copy at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, andmark the at least one new record in the second code table as hidden.

26. The system of any of claims 22-25, further comprising a user interface configured to provide access to the code table for editing.

27. The system of claim 26, wherein the user interface is configured to omit visualizations of hidden records.

28. The system of claim 1, wherein:the memory stores a registry with one or more records that authorize the second EMS agency toread the ePCR data associated with the first EMS agency, and store the ePCR data within the second ePCR; andto determine that the second EMS agency is authorized to access the ePCR data associated with the first EMS agency comprises toidentify the one or more records within the registry,determine, from the one or more records, that the second EMS agency is authorized to read the ePCR data associated with the first EMS agency, and determine, from the one or more records, that the second EMS agency is authorized to store the ePCR data within the second ePCR.

29. The system of claim 28, further comprising a user interface configured to:provide the registry for editing to a user associated with the first EMS agency; and receive input authorizing the second EMS agency to read the ePCR data associated with the first EMS agency.

30. The system of claim 28, further comprising a user interface configured to:provide the registry for editing to a user associated with the second EMS agency; and receive input authorizing the second EMS agency to store the ePCR data associated with the first EMS agency.

31. The system of claim 1, wherein the at least one processor is configured to:receive, via the at least one network interface, a message requesting closure of the second ePCR;validate the second ePCR; andclose the second ePCR in response to validation success.

32. The system of claim 31, wherein to validate the second ePCR comprises to skip validation of one or more ePCR data field values of the set of cross-configuration ePCR data field values.

33. The system of claim 31, wherein to validate the second ePCR comprises to skip at least one validation rule invoked by presence of one or more ePCR data field values of the set of cross-configuration ePCR data field values.

34. The system of claim 33, wherein the at least one validation rule requires an identified ePCR data field to be populated if one of the one or more ePCR data field values is present.

35. The system of claim 33, wherein:the at least one validation rule requires an identified ePCR data field to be populated if an EMS call type identified in the second ePCR matches a target EMS call type; and the set of cross-configuration ePCR data field values comprises a value of NULL for the identified ePCR data field.

36. A method implemented by a computing device for sharing patient care record (ePCR) data between emergency medical services (EMS) agencies, the method comprising:receiving, via at least one network interface, a message requesting creation of a second ePCR associated with a scene location and a second EMS system configuration of a second EMS agency,identifying a first ePCR created before the second ePCR and associated with the scene location and a first EMS system configuration of a first EMS agency, the first EMS system configuration being distinct from the second EMS system configuration,determining that the second EMS system configuration authorizes access to ePCR data associated with the first EMS system configuration, andstoring a set of cross-configuration ePCR data field values from the first ePCR within the second ePCR.

37. The method of claim 36, wherein identifying the first ePCR comprises comparing at least one first ePCR data field value recorded in the first ePCR to at least one second ePCR data field value recorded in the second ePCR.

38. The method of claim 37, wherein:the at least one first ePCR data field value is a time of arrival at the scene location recorded in the first ePCR;the at least one second ePCR data field value is a time of arrival at the scene location recorded in the second ePCR; andcomparing comprises determining whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the arrival at the scene location recorded in the second ePCR transgresses a threshold value.

39. The method of claim 37, wherein:the at least one first ePCR data field value is a time of arrival at the scene location recorded in the first ePCR;the at least one second ePCR data field value is a time of ePCR creation recorded in the second ePCR; andcomparing comprises determining whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the ePCR creation recorded in the second ePCR transgresses a threshold value.

40. The method of claim 37, wherein:the at least one first ePCR data field value is a first address of the scene location; the at least one second ePCR data field value is a second address of the scene location; andcomparing comprises to determining whether the first address matches the second address.

41. The method of claim 40, wherein:the first address is a first text string;the second address is a second text string; anddetermining whether the first address matches the second address comprises determining whether the first text string matches the second text string.

42. The method of claim 41, wherein:the first text string comprises a first zone improvement project (ZIP) code and a first street address; andthe second text string comprises a second ZIP code and a second street address; and determining whether the first text string matches the second text string comprises determining whether the first ZIP code matches the second ZIP code, and determining whether the first street address matches the second street address.

43. The method of any of claims 37-42, further comprising receiving, via a user interface, input specifying the second ePCR data field value.

44. The method of claim 43, wherein receiving the input comprises receiving gesture-based alphanumeric input.

45. The method of claim 37, wherein:the first ePCR data field value is a first set of global positioning system (GPS) coordinates;the second ePCR data field value is a second set of GPS coordinates; and comparing comprises determining whether the first set of GPS coordinates matches the second set of GPS coordinates.

46. The method of claim 37, further comprising:receiving, via the at least one network interface, one or more messages from a computer-aided dispatch (CAD) system;parsing the one or more message to extract a CAD data field value; andstoring the CAD data field value in the second ePCR as the at least one second ePCR data field value.

47. The method of claim 36, further comprising:receiving one or more selections of one or more ePCR data fields from the first ePCR, whereinstoring the set of cross-configuration ePCR data field values comprisesstoring, within the second ePCR, first cross-configuration ePCR data field values from a default set of ePCR data fields in the first ePCR, andstoring, within the second ePCR, second cross-configuration ePCR data field values from the one or more ePCR data fields.

48. The method of claim 47, wherein:storing the first ePCR data field values from the default set comprises storing the first ePCR data field values from patient data fields; andstoring the second ePCR data field values from the one or more ePCR data fields comprises storing the second ePCR data field values from one or more encounter data fields.

49. The method of claim 48, wherein storing the second ePCR data field values from the one or more encounter data fields comprises storing one or more of physiological measurement data fields and EMS event data fields.

50. The method of claim 36, wherein storing the set of cross-configuration ePCR data field values comprises flagging each ePCR data field value of the set as originating from the first ePCR.

51. The method of claim 50, further comprising providing, via a user interface, the set of cross-configuration ePCR data field values for editing.

52. The method of claim 51, further comprising removing a flag for each ePCR data field value that is edited.

53. The method of claim 51, further comprising recording an audit trail of events associated with the set of cross-configuration ePCR data field values.

54. The method of claim 53, wherein recording the audit trail comprises recording one or more of a timestamp recorded when the set of cross-configuration ePCR data field values was stored within the second ePCR, an identifier of the first ePCR, one or more identifiers of one or more patients encountered at the scene location, an identifier of an EMS provider at the scene location, and an identifier of a computing device that originated the message requesting creation of a second ePCR.

55. The method of claim 36, further comprising providing, via a user interface, a tabular chronology that comprises a plurality of entries arranged in chronological order, each entry of the plurality of entries indicating an ePCR that originated the entry and being representativeof either an ePCR data field value of the set of cross-configuration ePCR data field values or another ePCR data field value stored in the second ePCR.

56. The method of claim 36, further comprising determining that at least one importable ePCR data field value from the set of cross-configuration ePCR data field values is absent from the second EMS system configuration.

57. The method of claim 56, wherein:the second EMS system configuration stores a code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the second ePCR;the importable ePCR data field value is authorized for storage within a respective ePCR data field of the first ePCR according to the first EMS system configuration and unauthorized for storage within a respective ePCR data field of the second ePCR according to the second EMS system configuration; andthe method further comprises adding at least one hidden record to the code table specifying that the importable ePCR data field value is authorized for importation into the respective ePCR data field of the second ePCR.

58. The method of claim 57, wherein:the code table is a second code table;the first EMS system configuration stores a first code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the first ePCR; and adding the at least one hidden record to the second code table comprises identifying at least one existing record in the first code table specifying the importable ePCR data field value,copying at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, andmarking the at least one new record in the second code table as hidden.

59. The method of claim 56, wherein:the second EMS system configuration stores a code table specifying ePCR data fields authorized for inclusion within the second ePCR;the set of cross-configuration ePCR data field values from the first ePCR comprises at least one ePCR data field for an ePCR data field not specified within the code table; andthe method further comprises adding at least one hidden record to the code table specifying that the at least one ePCR data field is authorized for importation into the second ePCR.

60. The method of claim 59, wherein:the code table is a second code table;the first EMS system configuration stores a first code table specifying ePCR data fields authorized for inclusion within the first ePCR; andadding the at least one hidden record to the second code table comprises identifying at least one existing record in the first code table specifying the at least one ePCR data field,copying at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, andmarking the at least one new record in the second code table as hidden.

61. The method of any of claims 57-60, further comprising providing, via a user interface, access to the code table for editing.

62. The method of claim 61, further comprising omitting visualizations of hidden records.

63. The method of claim 36, wherein:determining that the second EMS agency is authorized to access the ePCR data associated with the first EMS agency comprisesidentifying one or more records within a registry, the registry storing one or more records that authorize the second EMS agency to read the ePCR data associated with the first EMS agency, and store the ePCR data within the second ePCR;determining, from the one or more records, that the second EMS agency is authorized to read the ePCR data associated with the first EMS agency; and determining, from the one or more records, that the second EMS agency is authorized to store the ePCR data within the second ePCR.

64. The method of claim 63, further comprising:providing, via a user interface, the registry for editing to a user associated with the first EMS agency; andreceiving input authorizing the second EMS agency to read the ePCR data associated with the first EMS agency.

65. The method of claim 63, further comprising:providing, via a user interface, the registry for editing to a user associated with the second EMS agency; andreceiving input authorizing the second EMS agency to store the ePCR data associated with the first EMS agency.

66. The method of claim 36, further comprising:receiving, via the at least one network interface, a message requesting closure of the second ePCR;validating the second ePCR; andclosing the second ePCR in response to validation success.

67. The method of claim 66, wherein validating the second ePCR comprises skipping validation of one or more ePCR data field values of the set of cross-configuration ePCR data field values.

68. The method of claim 66, wherein validating the second ePCR comprises skipping at least one validation rule invoked by presence of one or more ePCR data field values of the set of cross-configuration ePCR data field values.

69. The method of claim 68, wherein skipping the at least one validation rule comprises skipping one or more validation rules that require one or more identified ePCR data fields to be populated if one or more of the one or more ePCR data field values is present.

70. The method of claim 68, wherein skipping the at least one validation rule comprises skipping one or more validation rules that require one or more identified ePCR data fields to be populated if an EMS call type identified in the second ePCR matches a target EMS call type.

71. One or more non -transitory computer-readable media storing sequences of instructions executable by a processor to share patient care record (ePCR) data between emergency medical services (EMS) agencies, the sequences of instructions comprising instructions to:receive, via at least one network interface, a message requesting creation of a second ePCR associated with a scene location and a second EMS system configuration of a second EMS agency,identify a first ePCR created before the second ePCR and associated with the scene location and a first EMS system configuration of a first EMS agency, the first EMS system configuration being distinct from the second EMS system configuration,determine that the second EMS system configuration authorizes access to ePCR data associated with the first EMS system configuration, andstore a set of cross-configuration ePCR data field values from the first ePCR within the second ePCR.

72. The one or more non-transitory computer-readable media of claim 71, wherein the instructions to identify the first ePCR comprise instructions to compare at least one first ePCR data field value recorded in the first ePCR to at least one second ePCR data field value recorded in the second ePCR.

73. The one or more non-transitory computer-readable media of claim 72, wherein:the at least one first ePCR data field value is a time of arrival at the scene location recorded in the first ePCR;the at least one second ePCR data field value is a time of arrival at the scene location recorded in the second ePCR; andthe instructions to compare comprise instructions to determine whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the arrival at the scene location recorded in the second ePCR transgresses a threshold value.

74. The one or more non-transitory computer-readable media of claim 72, wherein:the at least one first ePCR data field value is a time of arrival at the scene location recorded in the first ePCR;the at least one second ePCR data field value is a time of ePCR creation recorded in the second ePCR; andthe instructions to compare comprise instructions to determine whether a difference between the time of the arrival at the scene location recorded in the first ePCR and the time of the ePCR creation recorded in the second ePCR transgresses a threshold value.

75. The one or more non-transitory computer-readable media of claim 72, wherein:the at least one first ePCR data field value is a first address of the scene location; the at least one second ePCR data field value is a second address of the scene location; andthe instructions to compare comprise the instructions to determine whether the first address matches the second address.

76. The one or more non-transitory computer-readable media of claim 75, wherein:the first address is a first text string;the second address is a second text string; andthe instructions to determine whether the first address matches the second address comprise instructions to determine whether the first text string matches the second text string.

77. The one or more non-transitory computer-readable media of claim 76, wherein:the first text string comprises a first zone improvement project (ZIP) code and a first street address;the second text string comprises a second ZIP code and a second street address; and the instructions to determine whether the first text string matches the second text string comprise instructions todetermine whether the first ZIP code matches the second ZIP code, and determine whether the first street address matches the second street address.

78. The one or more non-transitory computer-readable media of any of claims 72-77, further comprising instructions to receive, via a user interface, input specifying the second ePCR data field value.

79. The one or more non-transitory computer-readable media of claim 78, wherein the instructions to receive the input comprise instructions to receive gesture-based alphanumeric input.

80. The one or more non-transitory computer-readable media of claim 72, wherein:the first ePCR data field value is a first set of global positioning system (GPS) coordinates;the second ePCR data field value is a second set of GPS coordinates; andthe instructions to compare comprise instructions to determine whether the first set of GPS coordinates matches the second set of GPS coordinates.

81. The one or more non-transitory computer-readable media of claim 72, further comprising instructions to:receive, via the at least one network interface, one or more messages from a computer-aided dispatch (CAD) system;parse the one or more message to extract a CAD data field value; andstore the CAD data field value in the second ePCR as the at least one second ePCR data field value.

82. The one or more non-transitory computer-readable media of claim 71, further comprising instructions to:receive one or more selections of one or more ePCR data fields from the first ePCR, whereinthe instructions to store the set of cross-configuration ePCR data field values comprise instructions tostore, within the second ePCR, first cross-configuration ePCR data field values from a default set of ePCR data fields in the first ePCR, andstore, within the second ePCR, second cross-configuration ePCR data field values from the one or more ePCR data fields.

83. The one or more non-transitory computer-readable media of claim 82, wherein:the instructions to store the first ePCR data field values from the default set comprise instructions to store the first ePCR data field values from patient data fields; andthe instructions to store the second ePCR data field values from the one or more ePCR data fields comprise instructions to store the second ePCR data field values from one or more encounter data fields.

84. The one or more non-transitory computer-readable media of claim 83, wherein the instructions to store the second ePCR data field values from the one or more encounter data fields comprise instructions to store one or more of physiological measurement data fields and EMS event data fields.

85. The one or more non-transitory computer-readable media of claim 71, wherein the instructions to store the set of cross-configuration ePCR data field values comprise instructions to flag each ePCR data field value of the set as originating from the first ePCR.

86. The one or more non-transitory computer-readable media of claim 85, further comprising instructions to provide, via a user interface, the set of cross-configuration ePCR data field values for editing.

87. The one or more non-transitory computer-readable media of claim 86, further comprising instructions to remove a flag for each ePCR data field value that is edited.

88. The one or more non-transitory computer-readable media of claim 86, further comprising instructions to record an audit trail of events associated with the set of cross-configuration ePCR data field values.

89. The one or more non-transitory computer-readable media of claim 88, wherein the instructions to record the audit trail comprise instructions to record one or more of a timestamp recorded when the set of cross-configuration ePCR data field values was stored within the second ePCR, an identifier of the first ePCR, one or more identifiers of one or more patients encountered at the scene location, an identifier of an EMS provider at the scene location, and an identifier of a computing device that originated the message requesting creation of a second ePCR.

90. The one or more non-transitory computer-readable media of claim 71, further comprising instructions to provide, via a user interface, a tabular chronology that comprises a plurality of entries arranged in chronological order, each entry of the plurality of entries indicating an ePCR that originated the entry and being representative of either an ePCR data field value of the set of cross-configuration ePCR data field values or another ePCR data field value stored in the second ePCR.

91. The one or more non-transitory computer-readable media of claim 71, further comprising instructions to determine that at least one importable ePCR data field value from the set of cross-configuration ePCR data field values is absent from the second EMS system configuration.

92. The one or more non-transitory computer-readable media of claim 91, wherein:the second EMS system configuration stores a code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the second ePCR;the importable ePCR data field value is authorized for storage within a respective ePCR data field of the first ePCR according to the first EMS system configuration and unauthorized for storage within a respective ePCR data field of the second ePCR according to the second EMS system configuration; andthe instructions further comprise instructions to add at least one hidden record to the code table specifying that the importable ePCR data field value is authorized for importation into the respective ePCR data field of the second ePCR.

93. The one or more non-transitory computer-readable media of claim 92, wherein:the code table is a second code table;the first EMS system configuration stores a first code table specifying ePCR data field values authorized for storage within respective ePCR data fields of the first ePCR; and the instructions to add the at least one hidden record to the second code table comprise instructions toidentify at least one existing record in the first code table specifying the importable ePCR data field value,copy at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, andmark the at least one new record in the second code table as hidden.

94. The one or more non-transitory computer-readable media of claim 91, wherein:the second EMS system configuration stores a code table specifying ePCR data fields authorized for inclusion within the second ePCR;the set of cross-configuration ePCR data field values from the first ePCR comprises at least one ePCR data field for an ePCR data field not specified within the code table; andthe instructions further comprise instructions to add at least one hidden record to the code table specifying that the at least one ePCR data field is authorized for importation into the second ePCR.

95. The one or more non-transitory computer-readable media of claim 94, wherein:the code table is a second code table;the first EMS system configuration stores a first code table specifying ePCR data fields authorized for inclusion within the first ePCR; andthe instructions to add the at least one hidden record to the second code table comprise instructions toidentify at least one existing record in the first code table specifying the at least one ePCR data field,copy at least a portion of the at least one existing record in the first code table to at least one new record in the second code table, andmark the at least one new record in the second code table as hidden.

96. The one or more non-transitory computer-readable media of any of claims 92-95, further comprising instructions to provide, via a user interface, access to the code table for editing.

97. The one or more non-transitory computer-readable media of claim 96, further comprising instructions to omit visualizations of hidden records.

98. The one or more non-transitory computer-readable media of claim 71, wherein:the instructions to determine that the second EMS agency is authorized to access the ePCR data associated with the first EMS agency comprise instructions toidentify one or more records within a registry, the registry storing one or more records that authorize the second EMS agency to read the ePCR data associated with the first EMS agency, and store the ePCR data within the second ePCR;determine, from the one or more records, that the second EMS agency is authorized to read the ePCR data associated with the first EMS agency; and determine, from the one or more records, that the second EMS agency is authorized to store the ePCR data within the second ePCR.

99. The one or more non-transitory computer-readable media of claim 98, further comprising instructions to:provide, via a user interface, the registry for editing to a user associated with the first EMS agency; andreceive input authorizing the second EMS agency to read the ePCR data associated with the first EMS agency.

100. The one or more non-transitory computer-readable media of claim 98, further comprising instructions to:provide, via a user interface, the registry for editing to a user associated with the second EMS agency; andreceive input authorizing the second EMS agency to store the ePCR data associated with the first EMS agency.

101. The one or more non-transitory computer-readable media of claim 71, further comprising instructions to:receive, via the at least one network interface, a message requesting closure of the second ePCR;validate the second ePCR; andclose the second ePCR in response to validation success.

102. The one or more non-transitory computer-readable media of claim 101, wherein the instructions to validate the second ePCR comprise instructions to skip validation of one or more ePCR data field values of the set of ePCR data field values.

103. The one or more non-transitory computer-readable media of claim 101, wherein the instructions to validate the second ePCR comprise instructions to skip at least one validation rule invoked by presence of one or more ePCR data field values of the set of crossconfiguration ePCR data field values.

104. The one or more non-transitory computer-readable media of claim 103, wherein the instructions to skip the at least one validation rule comprise instructions to skip one or more validation rules that require one or more identified ePCR data fields to be populated if one or more of the one or more ePCR data field values is present.

105. The one or more non-transitory computer-readable media of claim 103, wherein the instructions to skip the at least one validation rule comprise instructions to skip one or more validation rules that require one or more identified ePCR data fields to be populated if an EMS call type identified in the second ePCR matches a target EMS call type.

Images