Systems and methods of producing patient encounter records

Abstract

A system for consolidating medical data from multiple devices involved in a patient encounter is provided. The system includes a mobile computing device that acquires, via a medical device interface, identifiers of each medical device, generates association information including the one or more identifiers, and transmits the association information to a server. The server receives and stores one or more medical device case files from the medical devices, receives the association information from the mobile computing device, associates the one or more medical device case files with one another, and produces an integrated data source encounter structure including case data from the one or more medical device case files for subsequent processing.

Description

SYSTEMS AND METHODS OF PRODUCING PATIENT ENCOUNTER RECORDS BACKGROUND {0001] Emergency care providers utilize a variety of specialized medical devices to treat the patients they encounter. These specialized medical devices can inclade defibrillators, ventilators, and automated resuscitation devices, among others. Defibrillators can be used to treat patients who suffer from a shockable cardiac archythmia, such as ventricular fibrillation or pulseless ventricular tachycardia. Ventilators can be used to supply oxygen to patients who have difficulty or are unable to breathe unassisted. Some automated resuscitation devices can perform cardiopulmonary resuscitation (CPR) chest compressions on patients who suffer sudden cardiac arrest, especially where such patients need to be moved to other locations for continued treatment. 0002] Medical device case Ties arise us a byproduct of treating patients with computerized medical devices, such as those described above. Medical device case files can document medical device operation during a patient encounter, treatments delivered during the patient encounter, and values of patient parameters measured by the medical device during the patient encounter. Medical device case files may be reviewed by healthcare providers during or after patient encounters {to gain insight into patient ailments and ultimately improve patient Quicomes. SUMMARY 10003] In at least one example, a system for consolidating medical data from multiple devices involved in an encounter between a patient and an emergency healthcare provider is provided. The system includes a plurality of medical devices each having one or more identifiers. Each of the plurality of medical devices is configured to oblain case data related to the encounter between the patient and the emergency healthcare provider and transmit the obtained case data 10 a server as one or more medical device case files. The system further includes a mobile computing device having a medical device interface and a user interface. The mobile computing device is configured to acquire, via the medical device interface, one or more representations of the one or more identifiers of each medical device of the plurality of medical devices, generate association information including the one or more identifiers, and transmit the association information to the server. The server inches at least one processor and memory to execute instructions for associating the one or more medical device case files. The server is configured to be comnuumicatively coupled with the plurality of medical devices and the mobile computing device. The server is farther configured to receive and store the one or more medical device case files fom the plurality of medical devices, receive the association formation from the mobile computing device, generate at least one search criterion based at Teast in pari on the association information to relate the one or more medical device case files {0 one another, identify the related one or more medical device case files based on the generated at least one search criterion, cousolidate the one or more medical device case files to produce an integrated data source encounter structure including case data from the related one or more medical device case files, and transmit the integrated data source encounter structure for review of the encounter between the patient and the emergency healthcare provider to a receiving computing device. {0004} In the system, the receiving computing device can include the mobile computing device. The mobile computing device can be further configured to render at least a portion of ihe integrated data source encounter structure via the user interface. The integrated data source encounter structure can include information other than patient information. 0008] In the sysiem, the receiving computing device can include at least one medical device of the plurality of medical devices. The receiving computing device can include a computing device within an emergency response center. The association information can include a token 10 access the integrated data source encounter structure. The server can be farther configured {0 receive the token from the computing device within the emergency response cenler. In the system, to transmit can include to awtomatically wransmit the integrated data source encounter structure to the computing device in response to reception of the token. The mobile computing device can be configured to transmit the token to the computing device within the emergency TeSpONSE center, {0006] In the system, to transmit the one or more medical device case files can include to {ransmit ong or more sirearus of the obiained case data to the one or more medical device case files. The integrated data source encounter structure can include the one or more streams of the obtained case data from the one or more medical device case files. 10007] The system can further include a computing device including at least one user interface. The computing device can be configured to receive the integrated data source encounter structure; and render, subsequent to the encounter, at least a portion of the integrated data source encounter structure via the at least one user interface. In the system, the plurality of medical devices can include one or more of: a defibrillator, a patient monitor, an automated external defibrillator, a ventilator, an automated chest compression device, and a wearable defibrillator. 10008] In the systen, the association information can include patient information. The patient information can include one or more of patient name, patient identifier, age, gender, weight, height, and past medical history. The association information can include timestamp information indicating when at least a portion of the one or more medical device case files was created. The association information can include timestamp information indicating when the one or more representations of the one or move identifiers of each medical device were acquired. The association information can include geolocation information indicating where the mobile computing device was located when the one or more representations of the one or more identifiers of each medical device were acquired. The association information can include geolocation information indicating where the mobile computing device was located when the one or more representations of the one or more identifiers of each medical device were acquired. The association information can include geolocation information indicating where the mobile computing device was located during the encounter. 0009] tn the system, the medical device interface can include at least one of: a camera, a near- field communication sensor, a radio frequency identification sensor, a universal serial bus connector, an infrared sensor, a personal area network sensor, a proximity detector, @ geolocation detector, and a wireless network connector. The medical device interface can include a camera, and the one or more identifiers can inchede one or more of a quick response code, a bar code, and a device identifier. 0010] tn the system, the one or more identifiers of each medical device correspond to one or more unique device identifiers. The mobile computing device can be further configured to generate one of more log entries of the encounter. The mobile computing device can be configured to transmit the one or more log entries to the server for inclusion in the integrated data source encounter structure. The server can be remote from the mobile computing device. {0011} In the system, the obtained case data can include physiological data inchuling one or more of? ECG data such as 12-lead BCG data, oxygen saturation data, capnographic data, and blood pressure data. The obtained case data can include treatment data including one or nore of: defibrillation data, drug infusion data, chest compression data, and ventilation data. The obtained case data can include performance data including one or more of: chest compression performance data and ventilation performance date. The obtained case data can include protected health information. {0012] In af least one example, an associating server for consolidating medical data from an encounter between a patient and an emergency healthcare provider is provided. The server includes a memory, a networking interface, and ot least one processor communicatively coupled with the memory and the network interface. The memory stores at least one database configured to store case data from a plurality of medical device case files recorded during the encounter between the patient and the emergency healthcare provider. The at least one processor is configured to receive, via the network interface, the plurality of medical device case files from a plurality of medical devices used to treat the patient during the encounter, store the case data from the plurality of medical device case files in the at least one database, receive, via the network interface, association information from a niobile computing device, the association information including at least one identifier of each medical device of the plurality of medical devices, generate at least one search criterion based at least in part on the association information to relate the plurality of medical device case files to one another, identity the related plurality of medical device case files based on the generated at least ong search criterion, consolidate the related plurality of medical device case files to produce an integrated data source encounter structure including at least a portion of the case data from the plurality of medical device case files from the at least one database, and transmit the integrated data source encounter steacture for review of the encounter between the patient and the emergency healthcare provider 1 a receiving computing device. {0013] In the associating server, to transmit the integrated data source encounter structure can include to transmit ihe integrated data source encounter structure to the mobile computing device. The integrated data source encounter structure can include information other than patient information. To transmit the integrated data source encounter structure can include to transmit the integrated data source encounter structure to at least one medical device of the plurality of medical devices. To transmit the integrated data source encounter structure cen include to ransinit the integrated data sowrce encounter structure to a computing device within an emergency response center. {0014} In the associating server, the association information can include a token to access the integrated data source encounter structure and the at least one processor can be further configured to receive the token from the computing device within the emergency response center, To transruit can include to antomatically wansmit the integrated data source encounter structure to the computing device in response to reception of the token. To receive the plurality of medical device case files can include to receive a plurality of streams of case data from the plurality of medical devices. The integrated data source encounter structure can include the plurality of sireams of case data from the plurality of medical devices.

[0015] In the associating server, the association information can include patient information. The patient information can include oue or more of patient name, patient identifier, age, gender, weight, height, and past medical history. The association information can include timestamp information indicating when at least a portion of the plurality of medical device case files was recorded. The association information can include timestamp information indicating when one of more representations of the at least one identifier of each medical device were acquired. The association information can include geolocation information indicating where the mobile computing device was located when the one or more representations of the at least one identifier of each medical device were acquired. The association information can include geolocation information indicating where the mobile computing device was located when one or more representations of the at least one identifier of each medical device were acquired. The association information can include geolocation information indicating where the mobile computing device was located during the encounter. The one or more identifiers of each medical device can correspond 0 one or more unique device identifiers. {0016} The associating server can be remote from the mobile computing device. In the associating server, the case data can include physiological data include one or more of: ECG data, oxygen saturation data, capuographic data, and blood pressure data. The case data can include treatment data including one or more of: defibrillation data, drug infusion data, chest compression data, and ventilation data, The case data can include performance data including one or more of: chest compression performance data and ventilation performance data. The case data can include protected health information. 0017] in at least one example, a mobile computing device for consolidating case data from an encounter between a patient and an emergency healthcare provider is provided. The mobile computing device includes a memory, a user interface configured to receive user input concerning the encosnter, a medical device interface configured w acquire a representation of an identifier of a medical device, a network interface, and at least one processor communicatively coupled with the user interface, the medical device interface, the network interface, and the memory. The at least one processor is configured to receive, via the user interface, input to acquire a plurality of representations of a plurality of identifiers of a plurality of medical devices involved in the encounter, store the acquired plurality of representations of the plasality of identifiers in the memory, generate association information including the plagality of identifiers, and transmit the association information to a server for associating and consolidating the case data from at least one medical device case file generated by the plurality of medical devices during the encounter.

[0018] In the mobile computing device, the at least one processor can be further configured to receive, via the netwark interface, an integrated data source encounter structure including at least a portion of the case data from the at least one medical device case file; and render, via the user interface, at least a portion of the integrated data source encounter structure. The integrated data source encounter structure can include information other than patient information. The portion of the case data can include physiological data including one or mors of: ECG data such as 12-lead ECG data, oxygen saturation data, capnographic data, and blood pressure data. The portion of the case data can include treatment data including one or more of: defibrillation data, drug infusion data, chest compression data, and ventilation data. The portion of the case data can include performance data including one or more of: chest compression performance data and ventilation performance data. The portion of the case data can include protected health information. {0019] In the mobile computing device, the association information can include patient information. The patient information can include one or more of: patient name, patient identifier, age, gender, weight, height, and past medical history, The association information can include timestamp information indicating when at least a portion of the at least one medical device case file was generated. The association information can include timesiamp information indicating when the plurality of representations of the plurality of identifiers of the plurality of medical devices were acquired. The association information can include geolocation information indicating where the mobile computing device was located when the plurality of representations of the plurality of identifiers of the phurality of medical devices were acquired. The association information can include geolocation information indicating where the mobile computing device was located when the plurality of representations of the plurality of identifiers of the plurality of medical devices were acquired. The association information can include geolocation information indicating where the mobile computing device was located during the encounter. The association information can include a token to access an integrated data source encounter structure include at Jeast a portion of the case data from the at least ong medical device case file and the at least one processor can be configured to transmit the token 10 a computing device within an emergency response center. 0026] tn the mobile computing device, the medical device interface can include at least one oft a camera, a near-field communication sensor, a radio frequency identification sensor, a universal serial bus connecior, an infrared sensor, a personal area network sensor, a proximity detector, a geolocation detector, and a wireless network connector. The medical device interface can include a camera, and the plurality of identifiers can include one or more of: a quick response code, a bar code, and a device identifier. The plurality of identifiers of the plurality of medical devices can correspond to one or more unique device identifiers. The at feast one processor can be farther configured to generate one or move log entries of the encounter. The at least one processor can be configured to transmit the one or more log entries to the server for inclusion in an integrated data source encounter structure including at feast a portion of the case data from the at least one medical device case tile. The mobile computing device can be remote from the server. 0021] In at least one example, a computer implemented process for consolidating case data from an encounter between a patient and an emergency healthcare provider is provided. The computer implemented process includes receiving, vig a user interface, input to acquire a plurality of representations of a plurality of identifiers of a plurality of medical devices involved in the encounter, storing the acquired plurality of representations of the plurality of identifiers in a memory of the computer, yeneraling association information comprising the plurality of identifiers, and wangmitting, via a network interface of the computer, the association information to a server for associating and consolidating the case data from at least one medical device case file generated by the plurality of medical devices during the encounter. 0022] The computer implemented process can further include receiving, via the network interface, an integrated data source encounter structure including at least a portion of the case data from the at least one medical device case file; and rendering. via the user interface, at least a portion of the integrated data source encounter structare. In the computer implemented process, receiving the integrated data source encounter structure can include receiving information other than patient information. The computer implemented process can further include receiving, via the network interface, an integrated data source encounter structure comprising at least a portion of the case data from the at least one medical device case file and rendering, via the user interface, at least a portion of the integrated date source encounter structure.

[0023] In the computer implemented process, receiving the integrated data source encounter stracture can include receiving information other than patient information. Rendering the at least a portion of the case data can include rendering physiological data comprising one or more of: ECG data such as 12-lead ECG data, oxygen saturation data, capnographic data, and blood pressure data. Rendering the at least a portion of the case data can include rendering treatment data comprising one or more of: defibrillation data, drug infusion data, chest compression data, and ventilation data. Rendering the at least a portion of the case data can include rendering performance data comprising one or more of chest compression performance data and ventilation performance data. Rendering the at least a portion of the case data can include rendering protected health information. 10024] In the computer implemented process. transmifting the association information can include transmitting patient information. Transmitling the patient information can include transmitting one or more of: patient name, patient identifier, age, gender, weight, height, and past medical history. Transmitling the association information can include transmitting timestamp information indicating when af least a portion of the al least one medical device case file was generated. Transmitting the association information can include transmitting timestamp information indicating when the plurality of representations of the plurality of identifiers of the phurality of medical devices were acquired. Transmitting the association information can include transmitting geolocation information indicating where the mobile computing device was located when the plurality of representations of the plurality of identifiers of the plurality of medical devices were acquired. Transmitting the association information can include wansmitting geolocation information indicating where the mobile computing device was located when the plurality of representations of the plurality of identifiers of the plurality of medical devices were acquired. Transmitting the association information can include teansmiting geolocation information indicating where the mobile computing device was located during the encounter. Transmiiting the association information can include transmitting a token to access an integrated data source encounter structurs including at least a portion of the case data from the at least one medical device case file and the computer implemented process farther comprises transmitting, via the network interface, the token to a computing device within an emergency response center. 0025] In the computer implemented process, receiving input to acquire the plurality of representations can include receiving input via at least one off a camers, a near-field communication sensor, a radio frequency identification sensor, a universal serial bus connector, an infrared sensor, a personal area network sensor, a proximity detector, a geolocation detector, and a wireless network connector. Receiving input to acquire the plurality of representations can include receiving input via a camera, and the plurality of identifiers comprises one or more of a quick response code, a bar code, and a device identifier. Receiving input to acquire the plurality of representations of the plurality of identifiers can include receiving input to acquire a plurality of representations of a phurality of unique medical device identifiers. {0026] The computer implemented process can farther include generating one or more log entries of the encounter. The computer implemented process can further include transmitting the one or more log entries to the server for inclusion in an integrated data source encounter stracture inclading at least a portion of the case data from the at least one medical device case file. 10027] In at least one example, a non-tramsitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium stores instructions configured to execute the computer implemented process described above. In some examples, the non- iransiiory computer-readable siorage medium is incorporated into a mobile computing device remote [rom the server referenced in the computer implemented process. BRIEF DESCRIPTION OF THE DRAWINGS 10028] Various aspects of the disclosure are discussed below with reference fo the accompanying figures, which are not intended to be drawn 10 scale. The figures are included to provide an illustration and a further understanding of various examples and are incorporated in and constitute a part of this specification but are not intended to limit the scape of the disclosure. The drawings, 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 component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every figure. A quantity of each component in a particular figure is an example only and other quantities of each, or any, component could be used. {0029] FIG. 1 is a schematic block diagram of a medical records system in accordance with at least one example disclosed herein.

[0030] FIG. 2 is a record layout diagram of one example of association information in accordance with at feast one example disclosed herein. 10031] FIGS. 3A and 3B are diagrams illustrating emergency medical scenes in which a healthcare provider acquires of representations of medical device identifiers from various medical devices in accordance with at least one example disclosed herein, {0032] FIG. 3C is a data flow diagram illustrating the flow of medical device case files and data from a plurality of medical devices to a medical device case file data store. 0033] FIG. 3D is a data flow diagram illustrating the processing and flow of case data from the medical device case file data store of FIG. 3C to an integrated data source encounter structure. {0034] FIG. 4 is a flow diagram illustrating a case file consolidation process in accordance with at least one example disclosed herein. {0035] FIG. 5A is a flow diagram of a case file consolidation process executed by a patient encounter data source integration service in accordance with at least one example disclosed herein. 10036] FIG. SB is a flow diagram of a case file consolidation process executed by a patient encounter data source integration service in accordance with an example implementation that identities a medical device case file that includes medical device identifiers that match medical device identifiers included in association information.

[0037] FIG. 5C is a flow diagram of a case file consolidation process executed by a patient encounter data source integration service in accordance with an example implementation that identifies medical device case files that include a case start time and a case end time that ave within a torget time range that is defined based on case start and end times included in association information. 10038] FIG. SD is a flow diagram of a case file consolidation process executed by a patient encounter data source integration service in accordance with an example implementation that identifies medical device case files that include (3) medical device identifiers that match medical device identifiers included in gssociation information, and (b) a case start time and a case end time that are within a target time range that is defined based on case start and end times included in association information. {0039] FIG. 6 is a Now diagram of a case file data source integration process executed by a patient encounter data source integration service in accordance with at least one example disclosed herein, 10040] FIG. 7 is a {low diagram of case file dala source integration process executed by a patient encounter data source integration service in accordance with at least one example disclosed herein. 10041] RIG. & is a flow diagram of a consolidation process executed by a medical device, a charting device, and a patient encounter data source iniegration service in accordance with at least one example disclosed herein,

[0042] FIG. 9 is a view of a user interface screen provided by an ePCR application to request confirmation of one or more medical device case files in accordance with at least one example disclosed herein. 0043] FIG. 10 is a flow diagram of a case file consolidation process executed by a charting device and a patient encounter data source integration service in accordance with at least one example disclosed herein. {0044] FIG. 11 is a flow diagram of a consolidation process with user confirmation executed by a charting device and a patient encounter data source integration service in accordance with at least one example disclosed herein. 0045] FIG. 12 is a flow diagram of a case file data source integration process executed by a patient encounter data source integration service in accordance with at least one example disclosed herein. {0046] FIG. 13 is a fJow diagram of a case file data source integration process executed by a patient encounter data source integration service in accordance with ai least one example disclosed herein. 10047] FIG. 14 is a {low diagram of a case file data source integration process executed by a patient encounter data source integration service in accordance with at least one example disclosed herein. 10048] FIG. 15 is a flow diagram of a case file associating process executed by a patient encounter data source integration service in accordance with at least one example disclosed herein. 10049] FIG. 16 is a flow diagram of a case file data source integration process executed by a patient encounter data source integration service in accordance with at least one example disclosed herein. {0050] FIG. 17 is a flow diagram of a consolidated data sharing process executed by a patient encounter data source integration service in accordance with at least one example disclosed herein. {0051] FIG. 18 is a schematic block diagram of examples of computing and medical device components with which at least one example disclosed herein may be implemented. 0052] FIG. 19 is a schematic block diagram of a medical environment for transmitting data records, in accordance with at least one example disclosed herein. {0083] FIG. 20 is a schematic block diagram of another medical environment for transmitting data records, in accordance with at least one example disclosed herein,

[0054] FIG. 21 is a schematic block diagram of another medical environment for transmitting data records, in accordance with at least one example disclosed herein.

[0085] FIG. 22 is a view of a user interface screen provided by a local data collection application in accordance with at least one example disclosed herein. {0056] FIGS. 23A, 23B, and 24 are views of user interface screens provided by a remote data collection application in accordance with at feast one example disclosed herein {0057] FIG. 25 is a flow diagram of data record transmission between local and remote devices in accordance with at least one example disclosed herein. DETAILED DESCRIPTION 10088] Medical device case files generated during the course of a medical emergency encounter come in a variety of forms generated from different sources and include a wealth of medical data that can inform patient treatment and improve patient outcomes by providing healthcare providers with a more complete perspeciive regarding any given patient encounter. However, practical limitations to the convenience, accessibility and ultimate use of medical device case files exist, especially within the field of emergency medical services. In accordance with embodiments of the present disclosure, a healthcare provider may be able to gain access toan integrated data structure that incorporates the medical data (or other relevant data) sourced from multiple devices {e.g delibrillator / monitor, ventilator, documenting device, etc.) associated with the same patient encounter, while the patient encounter is happening and / or after the encounter has finished. This real-time consolidation of data into an integrated data structure of the encounter may be particularly advantageous for the healthcare provider(s) to assess the overall state of care for the patient and make appropriate adjustments. In various embodiments, more specifically, a healthcare provider may use a mobile computing device to effectively associate together multiple devices used at the scene of a patient encounter. These associations may be sent to a server executing a data source integration service, which is also receiving medical dasa from the multiple devices, to use the device associations and produce an integrated data structure that consolidates together the received medical data from the multiple device sources. The integrated data structure may be continuously updated over time as the case encounter progresses, and further transmitted to the mobile computing device(s) of the healthcare provider(s) and / or another remote computing device (e.g., for telemedicine, telehiealth purposes). {0089] For example, consider an illustrative scenario of a crew of emergency medical services (EMS) healthcare providers 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, ec.) and to transport the patient fo a hospital. During the course of this emergency encounter, the treatment provided by healthcare providers is sometimes administered via one or more computerized medical devices. These medical devices can record and locally store case files as open data siructures that include case data (e.g. streaming in real-time and / or for post-case review} that documents significant events within, and other relevant information regarding, the encounter. This case data for real-time streaming and / or post-case review can include physiological parameters of the patient acquired by sensors accessible by the medical devices during the encounter, data regarding treatment administered to patients via therapeutic devices controllable by the medical devices during the encounter. data regarding performance of the EMS healthcare providers, protected health information (PHI), and data regarding important milestones (e.g, codefevent markers) within the encounter. Examples of physiological parameters stored within case data for real-time streaming and / or post-case review include heart rate, electrocardiogram (BCG) traces, blood pressure data, capnographic data, temperature, blood-oxygen data, and the like. Examples of treatment data stored within case data for real-time streaming and / or posi-case review include defibrillation data, drug infusion data, chest compression data, and ventilation data. Examples of performance data stored within case data include chest compression performance data, ventilation performance data, and timely drug infusion information, amongst others. As this illustrative scenario makes clear, a wide variety of valuable case data can be generated by a variety of medical devices involved in a patient encounter. However, accessing this case data, particularly in real-time as the patient encounter unfolds, can be impractical for EMS and other healthcare providers because the medical device case files containing the medical data are scattered across multiple devices and lack organization for immediate access by the relevant henithcare providers. {0060] While some medical devices are capable of transmiiting the medical device case files (e.g. data structures in & real-time streaming format) they generale to 8 centralized storage {ocation (¢.8.. a server), establishing a linkage between medical device case files documenting a particular patient encounter can be troublesome, particalarly while the encounter is happening or immediately after the encounter. There ave a wide variety of computerized medical devices in use with varying degrees of openness and interoperability. Moreover, for some EMS agencies the number of medical device case [iles, which are continuously being updated, may be large even within a relatively short time window. For example, an EMS agency in a major metropolitan area may have on the order of 100 defibrillators deployed with 10-20 or more concurrent patient encounters. {0061} Given the life or death importance and level of stress associated with some patient encounters, establishing an immediate, real-time link between medical device case files (which may include continuously sireaming data structures for mid-case review during the patient encounter) can be a powerful way to enhance the overall experience of the healthcare provider particularly during the case encounter, and ultimately the quality of patient care. Thus, at least some of the examples disclosed herein enable a healthcare provider to use a mobile computing device configured with a patient encounter device association application to locally associate {ogether each of a plurality of medical devices used to provide treatment to the same patient, and as a resull, upon communicating with a server based patient encounter data source integration service, produce an integrated data source encounter structure that includes all or at feast a portion of the medical data relevant io ihe particular patient that is generated from each of the phurality of medical devices. As discussed herein for various embodiments. the integrated data source encounter structure may include a consolidated data structure that integrates medical data generated from different device sources at the same time, all corresponding to the same patient encounter. This allows a healthcare provider to view relevant data arising from multiple devices associated with the patient encounter in a real-time streaming context and / or during posi-case review, {0062] As described in further detail below, a healthcare provider located at an emergency scene may use a mobile computing device to effectively associate data generated from multiple medical devices, which associated data can subsequently be integrated into a single integrated data source encounter structure upon rANSMISSion to a server executing a service configured to generate encounter structures. Thus, an integrated patient encounter structure consolidating data from the multiple medical devices can be made available for the healthcare provider located at the scene and / or healthcare providers located remotely, over the course of the emergency event and / or for post-case review. As an example, the healthcare provider may use his / her mobile computing device to acquire an identifier, or a representation thereof, of each of a plurality of medical devices usedfocated at the scene. The mobile device executing a patient encounter device association application may then associate each of the plurality of medical devices together using the identifying information, and transmit association information (0 a server sysiem executing an encounter data source integration service, which can be one or more computing devices located at a remote location. This association information can include a variety of informational elements, such as a token that uniquely identifies the patent encounter, the identifiers of the medical devices, timestamp information associated with the patient encounter, geolocation information that identifies a geographical location of the patient encoanter, and potentially other information associated with the patient encounter. The server system may separately receive medical device case files (which may be continuously updated in real-time) from each of the medical devices located at the emergency scene and which are associated with the patient encounter. The server system may also happen to receive other medical device case files generated from other sources that are nol associated with the patient encounter. Based on a generated search criterion that links the association information uploaded by the encounter device association application of the mobile computing device, the server sysiem may search amongst the repository of medical case files / information and identify ihe related medical device case files associated with the particular patient encounter. From the identified related medical device case files, the server may produce a single integrated data source encounter structure for immediate review of the relevant data / events, for example, by the healthcare provider located at the emergency scene andfor another relevant healthcare provider (e.g., clinician available via telemedicine). As such, the integrated data source encounter structure may be reviewable via, for example, a user interface of the mobile computing device, a user interface of one of the medical devices, or a user interface of a computing device remote from the scene. Accordingly, the healthcare provider does not have 10 request or otherwise find the medical data associated with the patient encounter either at the server or at each of the plurality of medical devices. Rather, the relevant medical date may be made immediately available to the healthcare provider upon using his‘her mobile device to effectively link the appropriate medical devices and their relevant case file data together. {0063] FIG. 1 illustrates a medical records system 100 that includes and implements a patient encounter data source integration service 130 and device association generators 142A and 1428 as part of respective patient encounter device association application(s) 130A and 150B of the mobile computing devices 104 in accordance with some examples. The system 100, according to examples of the present disclosure, can associate case files from multiple, different medical devices 102A-102N to one another 10 generate Integrated data source structures of patient encounters. These consolidated medical records not only document patient encounters but also provide healthcare providers with information needed to improve patient outcomes. Ag shown in FIG. 1, the medical records system 100 includes one or more medical device(s) 102A-102N, one or more mobile computing devices 104A-104C, a remote computing device 106, and one or more server(s) 108 coupled to one another via a network 112. Each of the medical device(s) 102A~102N is configured to couple to one or more patient interface device(s) 190A-190N that are, in turn, configured to couple to a patient 116 during 8 patient encounter. For ease of reference, each of the medical device(s)102A-102N, the mobile computing device(s} 104A-104C, the patient encounter device association application(s) 150A-150B, and the patient interface device(s) 190A-190N may be referred to herein collectively as the medical devices 102, the mobile computing devices 104, and the patient interface devices 190. Individual members of these collectives may be referred to generically as a medical device 102, a mobile computing device 104, a patient encounter device association application 150, and patient interface devices 190. {0064] The system 100 further includes server(s) 108, which may be located remotely from the mobile computing devices 104 and the medical devices 102. For instance, the server(s) 10& may be housed in a datacenter that provides power and network connectivity to the server(s) 108. As shown in FIG. 1, the server(s) 108 can be configured to host one or more oft a medical device case application programming interface (API) 126, an ePCR API 128, a patient encounter data source integration service 130, a medical device case data store 132, a patent charting data store 134, a criteria data store 136, an event log API 144 and an event Jog data store 146. The remote computing device 106 can be configured to host a health records data store 110, which can receive and store medical data for a patient's medical record. In at least one example, an associating server of the server(s) 108 hosts the patient encounter data source integration service 130. 10068] At Jeast some of the system IH} advantageously leverage aspects of association information to identify case data. In embodiments of the present disclosure, a mobile computing device 104 may include a patient encounter device association application 150 that includes association generator(s) to generate the association information. As such, to aid the reader's understanding, a description of association information and the parts of the medical records system 100 that originate association information is provided prior to a description of the data source integration processes executed by the patient encounter data source integration service 130 and other parts of the system 100. {0066] In some examples, association information includes any element of data useful to determine whether two or more medical device case files were penerated within a particular patient encounter. As seach, a wide variety of data can be characterized as association information, in various examples. For instance, in some examples, association information can include one or more identifiers of a medical device 102 that generated a case file, information regarding a patient treated during a patient encounter {e.g., patient name or other identifier of a patient, age, gender, weight, height, andor past medical history), timestamp information recorded during the patient encounter {e.g., a timestamp indicating when at least a portion of a medical device case file was created and / or a timestamp indicating when the one or more identifiers of the medical device 102 were acquired), geolocation information recorded during the patient encounter (e.g, a geotay identifying a geographic location where the mobile computing device 104 acquired the one or more identifier of the medical device 102, and / or a token by the patient encounter device association application 150 of the mobile computing device 104 during the patient encounter (e.g. a universally unique identifier (UUID) or data that uniquely identifies the patient encounter). Association information can alse include portions of event log data and / or charting data, which are discussed in further detail below, {0067] Association information can originate from a wide variely of sources. For insiance, in some examples, the association generators 142A and 142B of the respective encounter device association applications 150 are configured to generate association information npon request. In some examples, the requests can be embeddad within system messages received from other processes hosted by the system 100 (e.g., the ePCR application 122 and / or the event log application 140). In these examples, the association generators 142A and 142B are configured io generate requested element(s) of association information (e.g., a token identifying a particular putient encounter) and return the requested element(s) of association information to the requesting process. In some examples, requests for association information can also be input received from a user interface of a mobile computing device 104. In these examples, the association generators 142A and 142B are configured io generate the requested association information and store the association information locally for subsequent processing. Alternatively or additionally, in some examples, the ePCR application 122 and / or the event log application 140 are configured to penerale association information via execution of their encounter documentation processes. Examples of association information generated by the ¢PCR application 122 and / or the event log application 140 can include patient demographic and / or physiologic information, among other types of information collected by the ePCR application 122 and / or the event log application 140 as discussed herein. {0068] FIG. 2 illustrates one example of a record of association information that the association generators 142A and 142B are configured to generate individually, or in collaboration with the ePCR application 122 and / or the event log application 140. As shown in FIG. 2, the association information record includes an encounter ID field 202, a first medical device ID field 204, a first timestarap field 206, a second medical device 1D Held 208, and a second timestamp field 210. In this example, the encounter 1D {eld 202 is configured to store a token (here a UUTD), the first and second medical device ID fields 204 and 208 are configured to store medical device serial numbers, and the first and second timestamp fields 206 and 210 are configured to store timestamps that may be used to associate case files relevant to the same patient encounter together. As will be understood in view of FIG. 2, the association information record 200 relates the first and second medical devices and their respective timestamps with the patient encounter uniquely identified by the encounter 1D) 202, Further, as will be explained in detail below, each «medical device 1D, timestamp> value pair within the association information record 200 provides the patient encounter data source integration service 130 with the information needed to identify, with high confidence, the medical device case files generated during the patient encounter identified by the encounter 1D 202, {0069] Returning to FIG. 1, in some examples, the patient encounter data source integration service 130 is configured to mouitor for and receive association information. For instance, in some examples, the patient encounter data source integration service 130 is configured to monitor the charting data store 134 and / or the event log data store 146 for bound association information received via the network 112. Alternatively or additionally, the patient encounter data source integration service 130 can be configured to receive messages from the ePCR API 128 and / or the event log API 144 comprising association information received via the network 112. Regardless, the inbound association information can be, for example, sowed from one or move new or modified ePCRs or event logs generated and transmitted by a mobile computing device 104. Alternatively or additionally, the inbound association information can be sourced from discrele messages transmitted, for example, by one of the association generators 1424 and / or 142B. The operation of these programs within the context of a realistic usage scenario is described in more detail below. {0070] To handle the inbound association information, the patient encounter data source integration service 130 is configured to execute one or more processes that attempt to identify case data within the case data store 132 that originated from one or more case files generated during a patient encounter associated with the inbound association information. Examples of these processes are described in defail below with reference to FIGS. 4-17. The patient encounter data source integration service 130 can be configured to take one or more of several actions io response to identifying case data that was generated during the patient encounter associated with the inbound association information. These actions may include producing consolidated medical data inclading the case data and / or combining the case data with charting data andor event log data, storing the consolidated medical data (¢.g.. in the charting data store 134 andéor the event log data store}, transmitting messages including the consolidated medical data in the form of an integrated data source encounter structure or portions thereof, and / or transmitting messages including the case data or identifiers of the case data. These messages can be transmitted to a mobile computing device 104, a medical device 102, and / or the remote computing device 106 (e.g., for storage in the health records data store 110) via the network 112 and one or more of the PCR API 128, the event log API 144, and the case API 126. These and other actions that the patient encounter data source integration service 130 may be configured to take in response to identifying corresponding case data ave also described in detail below with reference to FIGS. 4-17. EMS Example {0071] In some examples, the healthcare provider 118A, whe for example may be an EMS technician, can aitach the patient interface device(s) 190A-190N (e.g. physiological sensors, ECG sensors, SpO2 sensors, capnography sensors, blood pressure sensors, etc.) coupled to one or more of the medical devices 102 to the patient 116 to mounilor and / or treat the patient 116. This treatment may involve the medical devices 102 and certain aspects such as events and other information may be documented by the healthcare provider 118A via the ePCR application 122 and / or the event log application 140 of one of the mobile computing devices 104. 10072] As discussed herein, a number of different types of medical devices 102 may be employed, such as those more specifically illustrated in FIGS. 3A-3C. For example, as discussed herein, a defibrillator / monitor 302B may collect a variety of different types of data including patient information (e.g.. name, gender, size, weight, age, height, medical history, etc), physiological information (e.g. ECG waveform, ECG snapshots before and / or after certain notable events that are marked / annotated for review, heart rate, oxygen saturation data, CO2 data, blood pressure data, amongst others), treatment information (e.g., drug infusions, electrotherapy events, start of chest compressions, start of ventilations), and healthcare provider performance information (e.g., average chest compression depth, average chest compression rate, percentage of chest compressions in target for depth / rate, average release velocity, pre-shock CPR pause, post-shock CPR pause, venulation dal volume data, ventilation minute volume daa, ventilation rate data, drug infusion timing, etc.), to name a few. The ECG waveform and / or ECG snapshots may be captured using 10 or more electrodes coupled to the patient's body to generate a standard 12 lead report. A portion or all of the information collected by the defibrillator / monitor 302B may be uploaded as it is acquired to one or more server(s) via a network (e.g. the server(s) 108 and network 112 of FIG. 1, continuously, regularly, and / or post-case), as medical device case files, which may be updated at periodic intervals, Each medical device case file can have identifying information, for example, an identifier of the device from which the case file originated, timestamp data relevant {0 the dart, end, length of time of the patient encounter, and / or geolocation information of the device during the patient encounter. An example of an appropriate defibrillatormonitor is the X Series® defibrillator / monitor, provided by ZOLL Medical Corporation, although other suitable defibrillator / monitor devices may be used in accordance with the present disclosure. 10073] As iHustrated in FIG. 3A, other medical devices located al a scene sending continuous real-time data to the server(s} 108 for consolidation with other case files relevant to the patient encounter may include, for example, a ventilator 302C, an automated chest compressor 302A, and / or other medical devices. For instance, the ventilator 302C may collect and send to the server(s) 108 (continuously, regularly, and / or post-case) various types of data as it is acquired including patient information (e.g., name, gender, size, weight, age, height, medical history, ele), physiological information (e.g., heart rate, oxygen saturation data, CO2 data, amongst others), treatment information (e.g. fraction of inspired oxygen, pesk inspiratory pressure settings, tidal volume, minute volume, ventilation rate). and / or other relevant information, In various examples, the ventilaior 302C may have fanctionality similar to that of the Z Vent® Ventilator, provided by ZOLL Medical Corporation, but other ventilators may be employed. ‘The automated chest compressor 302A may also transmit (continuously, regularly, and / or post- case} cenain types of data as it is acquired including patient information, physiological information, treatment information such as chest compression settings (e.g. depth, rate, duty cycle, eic.), andor other relevant information. In certain examples, the automated chest compressor 302A may have functionality similar (o that of the AutoPulse™ chest compression device, provided by ZOLL Medical Corporation, but other suitable chest compression devices nay be used. Sinular to the defibrillator / monitor 3028, such devices may transmit a portion or all of the information collected to the server(s) 108 as medical device case files, each with their own identifying information. As a result, the information pertinent to the particular medical emergency may be grouped and consolidated together, with the original healthcare provider that started to the association having real-time access to the information, along with other appropriate personne! either located at or remote from the scene.

[0074] As shown in FIG. 3A, during an emergency medical event, the healthcare provider 118A employs the automated chest compressor 302A, the defibrillator / monitor 302B, and the ventilator 302C on a single patient (e.g. the patient 116 of FIG. 1). As discussed herein, the automated chest compressor 302A may be used to administer chest compressions to the patient according fo specified compression depth and rate parameters, without requiring the healthcare provider to provide manual compressions. The defibrillator / monitor 3028 may be connected to the patient via defibriliation electrodes and / or other patient sensors for collecting physiological information and {o monitor the patient, for example, in assessing whether the patient is suffering from a life-threatening cardiac arrhythmia. The ventilator 302C may provide oxygen to the patient through an intubation tube or mask. Each of these medical devices 302A, 3028, 302C is configured to collect data relevant to the patient encounter and may upload this data, for further processing, fo a large central repository of case files stored on the server(s) 108, {0075] The healthcare providers | 18A located at the scene of the patient eucounter may further be using their respective mobile computing devices to generate other information, such as creating log entries of notable events through a documentation tool and / or entering in patient information via a charting tool for ePCR. Such records may also be uploaded along with the other medical device case files to the central repository of the server(s) 108. Normally, another user would have to sift through this repository of case files and match information from the various files with one another for further viewing, however, examples of the present disclosure allow for the case [ies pertinent to the particular patient encounter to be associated or otherwise tinked together and consolidated into a single record, for viewing real-time, during and / or after the patient encounter,

[0076] For instance, as illustrated in FIG. 3A, the healthcare provider { {8A located on scene uses the mobile computing device 1{(4B executing an encounter device association application {e.g., a patient encounter device association application 150 of FIG. 1) to generate association information that may be used by the server(s) 108 to piece together the case {iles of the patient encounter. For example, the healthcare provider 118A can, before, during, or afler the patient encounter, move from medical device to medical device to acquire representations of each medical device using a medical device interface included with the mobile computing device 1048. For instance, the healthcare provider 118A can scan {e.g., acquire an image of) a first quick response (QR) code affixed to the defibrillator / monidior 302B using a camera that is part of the mobile computing device 1048 running the encounter device association application. Or, the healthcare provider 118A can position a near-field communication (NFC) reader included in the mobile computing device 104B executing the encounter device association application proximal to an NFC tag affixed to or housed within the defibriilatormonitor 302B 10 acquire 8 magnetic signature that identifies the defibrillator / monitor 302B. Next, the healthcare provider 118A can move to the automated chest compressor 302A and interact with the mobile computing device 104B executing the encounter device association application to scan a quick response (QR) code affixed to the automated chest compressor 302A. Or, the healthcare provider 118A can position the NFC reader included in the mobile computing device 1048 executing the encounter device association application proximal to an NFC tag affixed {0 or housed within the apiomated chest compressor 302A to acquire a magnetic signature that identifies the automated chest compressor 302A. Lastly, as shown in FIG. 3A, the healthcare provider 118A can move to the ventilator 302C and position the NFC reader included in the mobile computing device 104B executing the encounter device association application proximal to an NFC tag affixed to or housed within the ventilator 302C {o acquire a magnetic signature that identifies the ventilator 302C. Alternative to the NFC tag, the healthcare provider 118A can use the mobile computing device 104B executing the encounter device association application to scan a quick response (QR) code affixed to the ventilator 302C. It should be noted that the image and magnetic signature acquisition described above is quick and lightweight by design, as time is of the essence in some emergency patient encounters. In these situations, the healthcare provider 118A may not be able or willing to establish a robust, bi- directional, and fully authenticated network communication session with each medical device involved in a patient encounter. In addition, these lightweight communication mechanisms provide additional security to the medical devices, in that they cannot be wtilized to hack the medical device due 10 the unidirectional communication and limited functionality they provide. 10077] Alternatively or additionally, in some examples illustrated by FIG. 3A with combined reference fo FIG. 1, the healthcare provider 118A can use the mobile computing device 1048 executing the encounter device association application to acquire the representations of the identifiers of the medical devices by supplying appropriate input to a user interface provided by any of the event log application 140, the ePCR application 122, or either of the association generators 142A and 142B. In various examples, each of these programs is configured to receive input indicating a request to acquire a representation of an identifier of a medical device and to respond to such a request by controlling the medical device interface to scan for or otherwise obtain representations of identifiers. The QR codes scanned {or relevant identifying tags obtained) in this manner can be stored in association information along with a token identifving this particular patient encounter and timestamps that indicate the time at which the represenfations were acquired. Other information that can be stored in the association information includes a geotag indicating the geolocation of the mobile computing device 104B at the time of acquisition of each representation. After the association information is complete, the program responsible for its creation can store the association information locally (e.g., within local event log data, charting data, or as distinct association information) and / or transmit the association information to the server(s) 108 via an appropriate interface (e.g. the ePCR API 128 and / or the event log API 144} as distinct association information or in association with and / or embedded in charting data and / or event log dala. It should be noled that the representations of the medical devices can be acquired at any iime during a patient encounter or, in some case, even before or after the patient encounter. In some examples, the user provides a confirmation to the mobile computing device 1048 to generate and transmit the association information to the appropriate servei(s), for associating case files relevant to the particular patient encounter {0078] In some examples, after acquiring representations, converting them to data that identifies the medical devices 302A-302C, and receiving user confirmation, the mobile device 104B executing the encounter device association application generates association information (e.g. as illustrated in FIG. 2) and transmits the association information to the server(s) 108 via the network 112. In some examples, the mobile computing device 104B can receive from the server(s) 108 via the network 112, in real-time, an integrated data source encounter structure that includes information from medical device case files generated by the medical devices 302A-302C during their weatment of the patient 116. In these examples, the server(s) 10& providing the encounter data source integration service are configured io generate and transmit the integrated data source encounter structure automatically in response to reception of the association information. 10079] In addition, as shown in FIG. 3A, the server(s) 108 can be configured (o transmit the integrated data source encounter sgructure to the mobile computing device 104C to enable the healthcare provider 118B to provide support to the healthcare provider 118A, to prepare to receive the patient 116, and / or for telemedicine purposes. in some examples, the encounter review application 148 is configured to receive the integrated data source encounter structure from the server(s) 108 and provide the healthcare provider 1 188 with the integrated data source encounter structure via a user interface of the mobile computing device 104C. In at least some examples, the encounter review application 148 can include RescueNet® Code Review provided by ZOLL Medical Corporation. In some embodiments, the encounter review application 148 may be coincident with the encounter device association application, in that the same software application may be used to both generate association information and to review consolidated data of the Integrated data source encounter siructure. {00801 tn addition, examples of the present disclosure may allow for data generaied from medical devices that are applied to the patient at different times during the emergency to be consolidated. FIG. 3B illustrates an example in which the emergency encounter is segmented into three distinct phases 315A, 315B, and 315C. In phase 315A, a patient (e.g., the patient 116), who is not currently in the hospital, suffers from a medical emergency. such as sudden cardiac atrest. In such a situation, it is rarely the case that a large swath of appropriate medical devices is immediately present. In fact, it is more likely that only a bystander 300 with very little medical experience is available 10 help. The bystander 300 may have the presence of mind 10 find a public access automated external defibrillator (AED) 302D, for example, stored in a nearby wall cabinet and to call emergency medical services (EMS). The bystander 300 may then apply defibrillation electrode pads to the victim and administer CPR, according to step- by-step instructions provided by the AED, examples of which may include the AED Plus® or ZOLL AED 3% public access AEDs, provided by ZOLL Medical Corporation. In some examples, the AED 302D may collect data such as ECG waveforms of the victim, number of defibrillation shocks provided, ECG snapshots associated with the defibrillation shocks, and chest compression performance information, and may upload such information to the server(s) 108 with associating capabilities, as further described herein, {0081] Once EMS arrives in phase 3158, the healthcare provider 118A can use the mobile compaiing device 104 executing a patient enconmter device association application to quickly acquire a representation of an identifier of the AED 302D (e.g., scan QR code identifier, obtain NFC or radio frequency identification (RFID) tag identifier} seeking to access the case data stored therein via the mobile computing device 104 according to the examples described herein. In addition, the healthcare provider 1184, who has more medical training, may employ a professional grade defibrillator / monitor 302B and attach ECG electrodes (e.g. 12-lead, 3- lead), along with other sensors such as blood pressure and SpO2 sensors, for more advanced care and physiological monitoring. Upon arrival, the more advanced defibriliator / monitor 302B may also collect data such as, for example, heart rate, ECG waveforms of the victim, number of defibrillation shocks provided, ECG snapshots associated with the defibrillation shocks, blood pressure readings / trends, oxygen saturation readingsitrends, drug infusions, chest compression and ventilation performance information, amongst others. Such information may be uploaded to the appropriate server(s) 108 with associating capability on a continuous and / or regular basis as data is updated over time during the patient encounter. In accordance with aspects of the present disclosure, the healthcare provider 118A may use a mobile computing device 104 executing the encounter device association application to obtain identifiers (e.g. scanned QR / bar codes, acquisition via NFC connection or RFID) of the AED 3020 and the defibrillatorsmonitor 3028, for the encounter data source integration service to associate the two devices and the corresponding case files / data containing the relevam patient and treatment information with the specific emergency event, {0082] In phase 315C, EMS may decide that the victim requires immediate hospital care, and thus may begin transport via an ambulance that is further equipped with the automated chest compressor 302A and the ventilator anit 302C for care en route to the hospital. As discussed herein, in various examples, the automated chest compressor 302A way provide chest compressions according to pre-specified parameters, and the ventilator unit 302C may monitor oxygen saturation and heart rate levels of the victim and administer automated ventilations, for example, with user assistance. The healthcare provider 118A may further use the mobile computing device 104A executing the encounter device association application to obtain identifiers {e.g., scanned QR / bar codes, acquisition vig NFC connections) of the automated chest compressor 302A and the ventilator 302C, so that the encounter data source integration service is able to associate an additional two devices and the respective case files containing patient and treatment information with this particular emergency event. The healthcare provider 118A may further request using the mobile device 104 for the encounter data source integration service to associate together the information generated by the four separate devices for the particular emergency victim / event, where the server(s) 108 with associating ability can consolidate the medical data provided from the uploaded case files inio an integrated daa source encounter structure. The resulting integrated data source encounter structure may then include ail of the pertinent data relating to the patient 116 who was treated by the bystander 31 and by EMS, and even further by the hospital {not specifically elucidated in this example) which may employ even more medical devices in the emergency. In various examples, this integrated data source encounler structure could be sent to the appropriate healthcare provider(s), located either in proximity or remotely from the victim, for real-time andior post- case review, FIGS. 3C and 3D, which is described further below, illustrates an example flow of data in some of these examples. 10083] More specifically, FIG. 3C is a daa flow dingram that illustrates transmission and storage activities of some examples. As show in FIG. 3C, the medical devices 302A-304D each generate respective case files 304A-304D, which may be updated on a continuous andor regular basis over the course of the patient encounter. Each of the case files 304A-304D includes case data generated by its associated medical device during an encounter with the patient 116, for example, as illustrated in FIGS. 3A and 3B. For example, the case file 304A stores case data recorded by the awomatic chest compressor 302A. The case file 304A includes case data records that document an wlentifier of the automatic chest compressor 302A, events detected by the automatic chest compressor 302A, details regarding those events, and timestamps that indicate the time when each event was detected. As illustrated in FIG. 3C, the types of events that automatic chest compressor 302A detects and records in the case file 304A include start‘power on events, end / power off events, and configuration of automated compression settings. The automated compression settings can include depth, rate, and duty cycle, among other settings. In various embodiments, the device 302A continuously updates the case file 304A as it acquires data, which is in turn uploaded to the server executing the patient encounier data source integration service. {0084] Continuing with FIG. 3C, the case file 304B stores case data recorded by the defibriliator / monitor 302B, which may be updated on a continuous and / or regular basis over the course of the patient encounter. The case file 304B includes case data records that document an identifier of the defibritlator / monitor 302B, events and parameters detected by the defibriliator / monitor 3028, details regarding those events and parameters, and {imestamps that indicate the time when each event or parameter was detected. As illustrated i FIG. 3C, the types of events and parameters that defibrillaior / monitor 3028 detects and records in the case file 3048 include start‘power on events, end / power off events, measurements of the patient's blood pressure (invasive and non-invasive), pulse oximetry of the patient {instantaneous and trends), end-tidal carbon dioxide readings of the patient {instantaneous and trends), therapy pad attachment events, information regarding the therapy pads attached to the patient, information descriptive of electrotherapeutic shocks delivered to the patient, data descriptive of manual CPR compressions delivered to the patient, data descriptive of manual ventilations administered to the patient, ECG snapshots descriptive of the patients cardiac activity recorded proximal to {e.g., within 10 seconds before and after) an electrotherapeutic shock, a mode of operation (automatic or manual) of the defibrillator / monitor 3028, ECG information of the patient recorded independent of electrotherapeutic shock delivery, capnography information of the patient, and therapy pad detachment events. The ECG information and / or ECG snapshots may be used to create a 12-lead ECG report associated with defibrillator / monitor 3028. Accordingly, the patient record (e.g., that includes case file 3(4B) may include the 12-lead ECG report. The blood pressure measurenient can be systolic andfor diastolic. The information regarding the therapy pads can include the make, model, type, and impedance of the therapy pads. The information descriptive of the electrotherapentic shocks can include the number of joules delivered end the impedance encountered. The data descriptive of the manual compressions can include average depth and average rate. The data descriptive of the manual ventilations can include average tidal volume and average vent rate. In various embodiments, the device 30128 continuously updates the case file 304B as it acquires data, which is in um uploaded to the server execnting the patient encounter data source integration service. 10085] Continuing with FIG, 3C, the case file 304C stores case data recorded by the ventilator 302C, which may be updated on a continuous and / or regalar basis over the course of the patient encounter. The case file 304C includes case data records thai document an identifier of the ventilator 302C, events and parameters detected by the ventilator 302C, details regarding those events aud parameters, and timestamps that indicate the time when each event or parameter was detected. As illustrated in FIG. 3C, the types of events and parameters that ventilator 302C detects and records in the case file 304C include start / power on events, end / power off events, configuration of ventilator settings, pulse oximetry of the patient (instantaneous and trends), end-tidal carbon dioxide readings of the patient {instantaneous and frends), and capnography information of the patient. The ventilation seitings can inclade tidal vohume, rate, peak inspiratory pressure, peak end-expiratory pressure, and fraction of inspired oxygen. In various embodiments, the device 302C continuously updates the case file 304C as it acquires data, which is in fur uploaded io the server executing the patient encounter data source integration service. {0086] The case file 304D stores case data recorded by the AED 302D. The case fils 304D includes case data records that document an identifier of the AED 302D, events and parameters detected by the AED 302D, details regarding those events and parameters, and timestamps that indicate the time when each event or parameter was detected. As illustrated in FIG, 3C, the types of events and parameters that AED 302D detects and records in the case file 304D include stari / power on events, end / power off events, therapy pad attachment and detachment events, information regarding the therapy pads attached to the patient, information descriptive of electrotherapeutic shocks delivered to the patient. The information descriptive of the electrotherapeutic shocks can include the member of joules defivered and the impedance encountered. 10087] fu combination, the case files J04A-304D a chronology of care received by the patient 116 during the patient encounter. The case data stored in the case files 304A~304D is provided for purposes of illustration only, and the examples described herein are not limited 10 this or any other type of case data. 0088] In some examples, each of the case files 304A-304D is parsed and imported into a case data store (e.g. the case data store 132 of FIG. 1). This parsing and importation process accounts for the many differences in format and content between the various case files 304A- 304D and stores the case data included in the case files, and / or copies of the case files themselves, in the case data store. As shown in FIC. 3C, the case files and / or case data can be stored according to any of a variety of data types, models, and formats, Also as shown in FIG. 3C, the case data store can store case files and data {rom various other medical devices 306. While this standardized and centralized source of case files and data provides many advantages, the inclusiveness of the case daia store also gives rise to a need for a mechanism io efficiently search for, and find, case files and data with particular commonalities of interest, such as case liles and data having originated from a single patient encounter. 0089] FIG. 3D is a data flow diagram that illustrates associating, integration / consolidation, and reporting activities of some examples. As illustrated in FIG. 3D, a patient encounter data source integration service (e.g., the patient encounter data source integration service 136 of FIG. 1) can be configured to utilize association information to search for, and find, case files and data generated during a particular patient encounter and stored within the case data store 311. The case data store 311 is one, non-limiting example of the case data store 132 of FIG. 1. As shown in FIG. 3D, the case data store 311 inclades a table 307 that lists case files imported and stored in the case data store 311. This table stores identifiers of the medical devices that originated the case files, a timestamp information with the medical device case file, a unique identifier of the case file and a copy of the case file stored as a binary large object (blob). The case data store 311 also includes additional tables that store case data parsed from the case files for easy, rapid, and standardized access. Table 309 illustrates one example of such a table, which stores configuration setting used by an automated chest compressor, according to one example. Other table layouts and overall database schema can be used with the various examples disclosed herein, which are not limited to a particular approach to organizing case data. {0090] As shown in FIG. 3D, the patient encounter data source integration service is configured 10 receive and parse association information 3¢t1. In these examples, the patient encounter data source integration service can be further configured 10 use the parsed association information (2.8. device identifiers and timestamps) to search for and identify, within the case data store 132, the medical devices involved in a patient encounter corresponding to, and identified by the association information. The patient encounter data source integration service can be further configured to associate case files generated by the identified medical devices to one another and {o generate an integrated data source encounter structure 308 that includes case data from the various, associated, case files and / or copies of the case files themselves. Details of the operation of the patient encounter data source integration service 130 are provided further below, but as illustrated in FIG. 3D, the integrated data source encounter structure 308 generated in some examples includes at least a portion of the case data from each associated case file. Using this integrated data source encounter structure, healthcare providers, such as the healthcare provider 118C can review, for example, shocks administered while the patient 116 was being treated by the bystander 300, shocks administered while the patient 116 was being freated by the healthcare provider 118A on scene, and other treatment provided to the patient } 16 while en route 10 a hospital. 0091] FIGS. 3A-3D generally illustrate some examples of using a mobile device to identify multiple medical devices and receive data from the multiple devices that can be combined into an integrated case data report. However, it should be understood that other pre-generated data records and / or data reports may be received by any mobile computing devices on-scene with the patient 116, as well as by any remote mobile computing devices, such as those used by healthcare professionals at a hospital. Examples of such pre~generated data records include 12- lead ECG reports that may be generated by the defibrillator / monitor 3028. Generally, a 12- tead RCG report provides a picture of the electrical conduction within a patient's heart based on electrical measurements from 12 leads placed on the patient's body. Six of the 12 leads are considered “limb leads™ because they are placed on the arms and / or legs of the patient. The other six leads are considered “precordial leads” because they are placed on the torso {precordium). 10092] The 12-lead ECG report may include electrical waveforms collected from each of the 12 leads on the patient. In some examples the 12-lead ECG report also includes one or more interpretations of the waveforms to provide fast and convenient analysis for the user. These one or more interpretations may involve pattern recognition from amongst the different waveforms, which may generate alerts or indicators if a particular portion of a waveform has an abuormal pattern suggesting some forms of heart damage, In some examples, the 12-lead ECG report is one part of the integrated case data report, as described above.

[0093] FIGS. 19-21 illustrate example medical environments that involve communication of patient data between medical devices used at a particular location, such as an ambulance 1902, and the remote computing devices 1914. The data transfer may be facilitated by software applications installed on both local computing devices 1906 and remote computing devices 1914, as will be discussed in more detail herein, Example user interface screens for the software applications are discussed with reference to FIGS. 22 24. {0094] FIG. 19 illustrates one example medical environment 1900 that involves wireless local area network (e.g., WIFI) communication of patient data between one or more medical devices and a local computing device 1906, and also the data communication with remote computing devices 1914. Any number of remote computing devices 1914 may receive medical-related data via the network 1912, Tn the illustrated example, n remote computing devices (labeled 1914-1 to 1914-n) are identified, each having a remote data collection application 1916-1 to 1916-n, Returning to the site where a patient may be located, a focal computing device 1906 having a local data collection application 1908 is used fo collect data from one or more local medical devices. In the illustrated example, a defibritlator / monitor 1904 has been set up to mouitor a physiological state of a patient, The monitoring can involve the collection of various types of data, inclading collecting ECG data {rom a 12-lead measurement. An example of an appropriate defibrillator / monitor is the X Series® defibrillator / monitor, provided by ZOLL Medical Corporation, although other suitable defibrillator / monitor devices may be used in accordance with the present disclosure.

[0095] Any of the local computing device 1906 or the remote computing devices 1914 can include a tablet, smartphone, wearable device, and / or other mobile computing device andor a combination of mobile devices that can execule applications described herein and communicate wirelessly with other communication devices over short-range or long-range wireless networks. The local computing device and / or the remote computing devices 1914 may have the sare components as described above for the mobile computing devices 104A — 104C, In some examples, the local computing device 1906 represents a tablet or smariphone used by a paramedic or other similar first-respouder that is assisting a patient within the ambulance 1902 or at any location where the patient is. Tn some examples, the remote computing devices 1914 represent tables, smartphones, or PCs used by medical professionals at a remote location, such as at a hospital or clinic. {0096] Data collected by the defibrillator / monitor 1904 may be formatted as a record or report to provide meaningful information to both local and remote users. In some examples, the defibrillator / monitor 1904 generates a 12-lead BCG report to provide waveforms andfor analysis of waveforms collected from a 12-lead apparatus. In the illustrated medical environment 1900, this report is transmitted via wireless communication protocol to a local wireless router 1910. Any other local computing devices having the local date collection app 1908 installed may also conumunicate wirelessly with the router 1910 to receive the 12-fead ECG report. In some examples, the 12-lead ECG report is encrypted to ensure confidentiality of the medical data and is decrypied at the mobile computing device 1906 using the local data collection app 1908 or stand-alone decryption software. Once received, the 12-lead BCG report may be viewed on the local computing device 1906. In some examples, the local data collection app 1908 also facilitates the transfer of the 12-lead ECG report to the one or more remote computing devices 1914 via the network 1912. For example, the 12-lead ECG report may first be transmitted via a wireless communication protocol to the router 1910, or to any other router in the vicinity of the local computing device 1906, and then transmitted from the router 1910 0 the remote computing devices 1914 via the network 1912.

[0097] In some examples, the router 1910 is password-protected io ensure that only authorized devices can connect with router 1910 and receive data reports generated by the defibrillator / monitor 1904. For example, for the local computing device 1906 to communicate with the router 1910 to receive the data reports, if must first provide the requisite password to establish the wireless connection with the router 1904, Once the password is entered once, it may be remembered for future engagements such that it does not need to be entered again to establish the connection with the router 1910 when the local computing device 1906 is within range of router the 1910. 10098] Although description above has primarily discussed the acquisition and transmission of a 12-lead ECG report, it should be undersiood that any measured patient parameters can be acquired and tansmitted by the defibrillator / monitor 1904 to the local computing device 1906. Additionally, in some examples, any other measured patient parameters can be organized into one or more reports or records. Some examples of other measured patient parameters include respiration / breath rate, heart’pulse rate, blood-oxygen (SpQ2) saturation, methemoglobin (SpMET) saturation, carboxyhemoglobin (SpCO} saturation, end-tidal CO: (ETCOz) value, fractional inspired carbon dioxide (FiCQ:) value, temperature, and invasive or non-invasive blood pressure. The transmitted data may include waveform snapshots of particular relevant events based on the measured data. 0099] In some examples, data reporis or records generated by the defibrillator’ monitor 1904 are transmitted automatically to the local computing device 1906 upon being generated. In other words, there is no waiting for a request to be received for the data before transmitting it. Accordingly, any local computing devices having the local data collection app 190% installed will receive any transmitted data reports or records generated by the defibrillator / monitor 1904 without any interaction required by the user. In some examples, a user may opt out of receiving the data repouis or records using the local data collection app 1908. {01080] In some examples, the network 1912 can include one or more communication networks through which the router 1910 and the remote computing devices 1914 can send, receive, and / or exchange data, In various implementations, the network 1912 can include a cellular communication network andfor a computer network. In some examples, the network 1912 includes and supports wireless network andor wired connections. For instance, in these examples, the network 1912 may support one or more networking standards such as GSM, CMDA, USB, BLUETOOTH, CAN, ZigBee®, Wireless Ethernet, Ethernet, and TCP / IP, among others. The network 1912 may include both private networks, such as local area networks, and public networks, sach as the Internet. It should be noted that, in some examples, the network 1912 may include one or more intermediate devices involved in the routing of packets from one endpoint to another. However, in other examples. the network 1912 can involve only two endpoints that each have a network connection directly with the other. In some examples, the network 1912 includes one or more server devices that may act as intermediary checkpoints for the medical data, records, or reports transferred from the router 1910 to the one or more remote computing devices 1914. For example, an ECG medical report refated to a particular patient may be received by a server hosted in a secure domain. The server may store the received medical report as part of a larger medical record for the given patient that includes other data previously stored regarding the patient. The server may pass on either the received ECG medical report or the larger medical record to sy of the one or more remote computing devices 1914. {0101] In some examples, the remote computing devices 1914 include the remote data collection app 1916 to receive medical data, records, and / or reports via the network 1912. The remote data collection app 1916 may include much of the same functionality described above for the local data collection app 1908. For example, the remote data collection app 1916 may receive medical data measured from the defibrillator / monitor 1904 as a report or record that can be displayed to a user with nunimal or no interaction required by the user. In some examples, the remote data collection app 1916 may provide an alert or notification to a user whenever a new data report is received. The alert may change depending on determined characteristics of the data report. For example, when a new 12-lead ECG data report is received, the alert may have an increased volume or a different tone to signify woubling patterns detected in one or more of the waveforms that demand immediate attention by the user. The troubling patterns may be detected using one or more pattern delection algorithms that compare the detected waveforms to predefined waveforms known to represent some form of heart damage or abnormality.

[0102] In some examples, the remote data collection app 1916 facilitates the storage of multiple data reports for one or more different patients and allows a user to access any of the stored data reports. Once selected, one or more of the data reports may be shown on a display associated with any of the remote computing devices 1914, For example, 12-lead ECG data reports may be periodically generated and timestaraped based on the time of the creation. Each of these reports may be collected by the remote data collection app 1916 and listed for a user {0 select a particular 12-lead ECG data report to view. The listing may be sorted or organized based on the timestamp associated with each of the 12-lead ECG data reports.

[0103] In some examples, defibrillator / monitor 1904 generates a case file, such as case file 3048, that includes one or more 12-lead ECG reports, The full case file may then be received by local data collection app 1908 and ultimately transmitted to remote data collection app 1916. In some examples, one or more 12-lead ECG data reports generated by defibrillator / monitor 1904 are part of an integrated data source encounter structure as described, for example, with velerence to FIG. §. {0104] FIG. 20 illustrates another example medical environment 2000 that volves local personal area network (e.g., BLUETOOTH network} communication of patient data between ane or more medical devices and the local computing device 1906, and also data communication with the remote computing devices 1914. The local computing device 1906 having the local data collection application 1908 is used to collect data from one or more local medical devices, such as the defibrillator / monitor 1904, {0105] The medical environment 2000 is similar to the medical environment 1900 described with reference to FIG. 19, however, one difference fies in how the medical data reports are transferred between the delibrillator / monitor 1904 and the local computing device 1906, and between the local computing device 1906 and the remote computing devices 1914. In the medical environment 2000, medical data, reports, and / or records measured / generated by the defibriliator / monitor 1904 are vansferred to the local computing device 1906 via a secure personal area network connection. In some examples, the defibritfator / monitor 1904 generates a 12-lead ECG report to provide waveforms and / or analysis of waveforms collected froma 12- lead apparatus. Any other local computing devices having the local data collection app 1908 installed may also conununicate wirelessly via the personal area network to receive the 12-lead ECG report. In some examples, data reports or records generated by the defibrillator / menitor 1904 are transmitted automatically to the local computing device 1906 upon being generated. Tn other words, there is no waiting for a request 10 be received for the data before transmitting it. In some examples, the 12-lead ECG report is encrypted to ensure confidentiality of the medical data and is decrypted at the local computing device 1906 using the local data collection app 1908 or stand-alone decrypiion software. Once received, the 12-lead ECG report may be viewed on the local computing device 1906. In some examples, a pairing process between the local computing device 1906 and the defibrillator / monitor 1904 must first be performed to establish the personal area network connection. This pairing process may involve manually accepting the connection with the local computing device 1906 on the defibrillator / monitor 1904. {0106] In some examples, the local data collection app 1908 also facilitates the transfer of the 12-lead ECG report lo the one or more remote computing devices 1914 via the network 1912. This data transfer may occur using long-range wireless communication, such as cellular comnwnication, between the local computing device 1906 and the network 1912. 10107] FIG. 21 illusivales another example medical environment 2100 that involves direct communication between one or more medical devices and the remote computing devices 1914 vig a network 2102, Unlike the example medical environments 1900 and 2000, the medical environment 2100 does not involve computing devices local to the defibrillator / monitor 1904 in the transfer of medical data, records, or repons measured / gencrated by the defibriliator / monitor 1904. 10108] In some examples, the defibrillator / monitor 194 uses one ot both of short-range and long-range communication to transfer medical data via the network 2102 10 the remote computing devices 1914. Example short-range communication technologies include BLUETOOTH or WIFI while example long-range technologies include cellular communication. 10109] In some examples, the network 2102 shares the same characteristics described above for the network 1912. In the illustrated example, the network 2102 includes ut least a fivst server 2104 and a second server 2106. In some examples, the first server 2104 is configured io receive medical data, records, and / or reports from the defibrillator / monitor 1904 and provides a gateway of sorts for collecting and organizing the data, In some examples, the first server 2104 is hosted on a secure network. The first server 2104 may hand off the received medical data, records, and / or reports to the second server 2106, which disseminates the received data, records, andfor reports to the remote computing devices 1914. Tn some examples, the first server 2104 may be a centralized data server configured to receive medical data [rom a plurality of different medical devices operated by different hospital networks, and the second server 2106 may be a server hosted on a particular hospital network and designed to transmit the received medical data, records, and / or reports to the remote computing devices 1914 thatare a part of the particular hospital network.

[0110] In some examples, the first server 2104 sends the received medical data, records, andior reports out to an email distribution list stored within the first server 2104. The distribution list may be updated and modified to add or delete particular email addresses that are to receive data associated with a particular the defibviliatov / monitor 1904. fn some examples, individual email addresses in the distribution list may be configured (© receive only particular types of data reports (such as only receiving 12-fead ECG reports), or only receiving data reports generated during a particular timeframe. In some examples, different distribution lists may be created having one or more associated account codes. Each of the account codes may be related to one or more defibrillator devices or to a particular hospital network. 10111] In the example medical environments described above, medical reports such as 12-lead ECG reporis are generated by the defibrillator / monitor 1904. However, in some examples, medical data is collected by the defibrillator / monitor 1904 and transferred to the local computing device 1906, and the local computing device 1906 generates a medical report based on the received data. The medical repori may be generated using the local data collection app 1908. In some other examples, medical reports are generated by any of the one or more remote computing devices 1914 after receiving the medical data either directly from the defibrillator / monitor 1904 or from the local computing device 1906. The medical report may be generated using the remote data collection app 1916. {0112] FIG. 22 illustrates an example user interface screen 2200 that is part of the local data collection app 1908. The user interface screen 2200 may be presented {o a user on any type of display device and allows for a user to interact, via for example a touch interface, with the data being collected from the defibrillator / monitor 1904. Additionally, the user interface screen 2200 presents an example interface for viewing data records, such as ECG records, collected from the defibrillator / monitor 1904. It should be understood that the relative size and placement of the various regions andor graphical objects on the user interface screen 2200 may be different than the particular ilfustrated example. In some examples, user interface screen 2200 provides a dedicated interface for the purpose of immediately presenting newly acquired data reports. The data reports appear on the screen as they are received, and in a listed order as more and more reports gre received. In some examples, the list of received data reports can be scrolled through, sorted, or filtered. 0113] The user interface screen 2200 displays information regarding a given medical device that it i$ receiving data from. For example, a region 2202 may include details like name, serial number, and / or unit ID for a given medical device, such as the defibrillator / monitor 1904. The user interface screen 2200 may inclade tabs in some examples io switch between different medical devices that are in the vicinity of the local computing device 1906. Accordingly, the region 2202 may include descriptive details regarding the current medical device for which data is being displayed, In some examples, a status indicator 2204 is provided to indicate whether a successful connection has been established with the medical device indicated in the region 2202,

[0114] In some examples, the user interface screen 2200 includes a button 2206 that is used to hait any polling for further data from the medical device. For example, the defaalt setting when establishing a connection with a given medical device is io continuously check for new data from the medical device and receive any new dala being transmitted from the given medical device. The button 2206 in essence allows a user to opt out from receiving any further medical data, records, or reports from the given medical device. {0115] In some examples, the user interface screen 2200 includes a data report 2208 received from the given medical device. In some examples, a list of data veports may be provided in chronological order from when they ave received. In some examples, the list of data reports may be sorted by time, name, or user-defined characteristics within the reports. As seen in the illustrated example, the displayed data report may include some descriptive details such as the date and time that the report was generated, a serial number associated with the medical device that generated the report and a unit 1D of the medical device. In some examples, a user may click on or touch the displayed data report 2208 to view the report in further detail. {0116] In some examples, a history bution 2210 may be provided to access archived data reports generated by the given medical device. The archived reports may be organized by patient or by given time periods of data collection. For example, 12-lead ECG medical reports nay be organized by the day or week that they were collected. 10117] FIG. 23A illastrates an example user interface screen 2300 that is pari of the remote data collection app 1916. The user interface screen 2300 may be presented to a user on any type of display device and allows for a user fo interact, via for example a touch interface, with the data being coflected from the defibrillatormonitor 1904. Additionally, the user interface screen 2300 presents an example interface for viewing data records, such as 12-lead ECG records, collected from the defibrillator / monitor 1904. Tt should be understood that the relative size and placement of the various regions and / or graphical objects on the user interface screen 2300 may be different than the particular illustrated example. {0118] The user interface screen 2300 includes controls 2302A - 2302E for accessing a plurality of received data reports collected from a given medical device, according to some examples. Although five 12-Jead ECG dala reports ave illustraied, any number of data reports can be listed and scrolled through. For ease of discussion herein, any of the controls 23024 ~ 2302E for accessing data reports may be identified with the more general label 2302, Each of the listed data reports may include some descriptive details such as the date and time that the report was generated, a serial number associated with the medical device that generated the report and a unit ID of the medical device. In some examples, the controls 2302 may be listed in chronological order of receipt of their corresponding data reports. In some examples, the controls 2302 may be sorted and / or filtered by time, name, or user-defined characteristics within their corresponding reports by activating a sort button 2304. In some other examples, the controls 2302 may be sorted and / or filtered based on the medical device that generated their corresponding reports, based on a given patient, or any other user-defined criteria. {0119] In some examples, the data reports come from any number of different medical devices. Accordingly, the reports can include different types of data depending on the device that generated them. For example, some of the data reports may be from a defibrillator / monior {such as defibrillaior / monitor 302B), some dafa reporis may be from a ventilator {such as ventilator 302C), and some data reports may be from an automated chest compressor (such as sutomaled chest compressor 302A). FIG. 23B illuswates another example user interface screen 2301 that is part of the remote data collection app 1916. User interface screen 2301 presents an example interface with controls 2303A-2303E for viewing data reports collected from different medical devices associated with the sane patient encounter. Such data reports received from different medical devices may be listed separately (as shown in FIG. 23B), or they may be combined into an integrated data source encounter stractare {asing, for example, a patient encounter data source integrated service 130 as described in FIG. 3D), and different ones of integrated data source encounter structures are listed instead. In the illustrated example, data reports have been received at different times from medical devices 302A - 302D as described with reference to FIGS. 3B and 3C. {0120} FIG. 24 illustrates another example user interface screen 2400 that is part of the remote data collection app 1916. The user interface screen 2400 provides an example view of a given data report 2302 after it has been selected, for example, from the user interface screen 2300. Selection of a given data report 2302 may change the view to show the details of the report to the user, In the illustrated example of the user interface screen 2400, a 12-lead ECG report has been selected and the details of the report are shown. {0121] In some examples, the user interface screen 2400 includes a patent details region 2402 that includes various detailed regarding the patient associated with the medical report. As sesn in the example. the patient’s details may include the patient's name, patient ID, age, and sex. Further medical details ascertained from the medical device may be provided as well, such as the patient's heart rate, PR interval, QRS duration, QT / QTx, and P-R-T axis, In some examples, the patient details region 2402 also includes notes that have been added to the medical report from: another caregiver, such as from a user of the local data collection app 1908 at the scene with the patient. {0122] In some examples, the user interface screen 2400 displays particular waveforms from various leads of a 12-lead ECG measurement. For example, waveforms collected from each of the V1 ~ V6, I II, 11, aVR, aVL, and aVF leads may be displayed. The data may be presented in a landscape view as illustrated in FIG. 24. 10123] nu some examples, devices from any of medical environment 1900, 2000, or 2100 are configured lo execute a variety of processes thal transmit and receive medical data records, such as ECG records or integrated data source encounter structures, FIG. 25, for instance, illustrates a data record transmission process 2500 that is executed by a medical device (e.g., defibrillator / monitor 1904 of FIG. 19), one or more local computing devices (e.g., local computing device 1906 of FIG. 19), and one or more remote computing devices (e.g. remote computing device 1914 of FIG. 19). In some examples, the operations attributed to the one or more focal computing devices in FIG. 25 are executed by one or more local data collection apps (e.g. the local data collection app 1908 of FIG. 19) hosted by the one or more local computing devices. {0124] Data record transmission process 2500 begins with collecting 2502 data from a patient using the medical device, in accordance with some examples. The data may be collected via one or more patient interface devices (e.g., physiological sensors, ECG sensors, SpO2 sensors, capnography sensors, blood pressure sensors, ete.} as described with reference to FIGS. 1 and 18. In some examples, the patient interface device includes 12-lead ECG sensors for collecting a 12-lead ECG of the patient. {0125] After collecting the patient data. the medical device generates 2504 one or more data reports, such as a 12-ead ECG report. The 12-lead ECG report may include electrical waveforms collected from each of the 12 leads on the patient. Int some examples the 12-lead ECG report also includes one or more interpretations of the waveforms to provide fast and convenient analysis for the user. These one or more interpretations may involve pattern recognition from amongst the different waveforms, which may generate alerts or indicators if’ a particular portion of a waveform has an abnormal patiern suggesting some form of heart damage. Tn some examples, the one or more data reports include at least one case file, such as case file 304B, that includes }2-lead FCG data. The case file may be one case file of an integrated data source encounter structure. Accordingly, data reports may be generated from a plurality of medical devices and combined to create the integrated data source encounter structure as generally discussed with reference to FIGS. 3C and 3D, 10126] The medical device wansmits 25006 one or more data reports (which may be included in one or more case files or integrated data source encounter structures) to one or move local computing devices. In some examples, data reports or records generated by the medical device are transmitied automatically (pushed) to the one or more local computing devices upon being generated. In other words, there is no waiting for a request te.g., a poll) to be received for the data before transmitting it. Accordingly, any local computing devices configured 10 receive the data via, for example, the local data collection app. will automatically receive 2308 any transmitted data reports or records generated by the medical device without any interaction required by the user. In some examples, a user may opt out of receiving the daa reports or records using the local data collection app. For example, the local data collection app can receive an input from the user that ceases automatically receiving any further data reports from a given medical device or from any medical devices. The medical device may transmit the one or more dala reports using any known wireless conmmunication interface such as WIFI, BLUBTQOTH, or cellular. In some examples, the received one or mote data reports are decrypted by the local computing device. {0127] Any of the one or more local computing devices can provide access 2510 to the one or more received data reports. In some examples, access to the one or more received data reports includes viewing the contents of one or more integrated data source encounter siractures. This access may include displaying a list of received reports along with the medical device they were received from. The displayed list may be automatically updated with any received data reports at the time that they are received. The list of reports may be sorted using various criteria such as by time received, time report was generated, medical device that transmitted the report, or certain parameters present in the medical report. According to some examples, at least one of the data reports is a 12-lead ECG report. An example of a user interface screen for providing one ar mare received data reports via a local computing device is illustrated in FIG. 22.

[0328] The local computing device is also configured to transmit 2512 any of the one or more received data reports to ong or more remote computing devices. This data transmission may oceur via any number of wireless pathways as generally illustrated in the medical environment 1900 or 2000. In some examples, the one or move received data reports are transmitted directly by the local computing device via cellular communication via a network, such as network 1912 from FIG. 19. In some examples, the one or more received data reports are transmitted across the network via a router within range of the local computing device. Regardless of the transmission technique used, one or more remote computing devices receive 2514 the one or nore data reports. which may include at least one {2-lead ECG report. 0129] The one or more remote computing devices are configured to provide 2316 access to the ane or move data reports. In some examples, access to the one or more received data reports includes viewing the contents of one or more integrated data source encounter structures. The one or more temole computing devices ray display a list of received reports along with the medical device or local computing device they were received from. The list of reports may be sorted using various criteria such as by time received, time report was generated, medical device that transmitted the report, or certain parameters present in the medical repon. According to some examples, at least one of the data reports is a 12-lead ECG report. Example user interface screens for providing one or more received data reports via a remote computing device are illustrated in FIGS. 23 and 24. {0130] Returning fo FIG. 1, In some examples, the healthcare providers 118A and 1188 can each be associated with the mobile computing devices 104 by, for example, being authenticated 10 an operating system and / or patient encounter device association application 150 executing on the mobile computing devices 104. As iflustraied in FIG. 1, in some examples the mobile computing devices 104 may be configured to commumicably coupled to the medical devices 102, although in some examples of the present disclosure, the mobile computing devices 104 are not hecessatily in direct communication with the medical devices 102 but rather, the mobile computing devices 104 and the medical devices 102 are separately in communication with the server(s) 108 through the network 112,

[0131] fn some examples, the mobile computing device 104A may be a device used by the healthcare provider 118A to generate the ePCR and / or other records and / or notes about the condition of the patient 116 and / or weatments applied to the patient 116. Similarly, in some examples, the mobile computing device 104B may be a device used by the healthcare provider 118A to generate an event log documenting specific treatment procedures (2.8., execution of a cardiac code) applied to the patient 116 such as the RescueNet® CodeWriter documentation mobile application, provided by ZOLL Medical Corporation, which allows for documentation of critical information of a code in an easy, intuitive manner. Although the ePCR application 122 and the event log application 140 are hosted by distinct mobile computing devices 104 in FIG. 1, the examples disclosed herein are not limited to this configuration. For instance, in some examples, a single mobile computing device 104 hosts both the ePCR application 122 and the event log application 140.

[0132] In some examples, the event log application 14( is configured to provide a set of user interface screens that are tailored to essily, quickly, conveniently, and accurstely record events and sometimes determine additional event details encountered during the emergency medical weaument. These interface screens can be provided, for example, via a touchscreen of the mobile computing device 104 executing the event log application 140, {0133] More specifically. in some examples, the event log application 140 is configured to provide screens including controls that are labeled and associated with events commonly encountered during emergency medical treatment. For instance, evenis such as administration of CPR, epinephrine (EPT), and / or electrotherapeutic shocks are commonly encountered while running a code blue and examples directed toward documenting a code blue have controls dedicated to recording these evenis. Many of these processes calminate in the storage of a date / time stamped entry that documents occurrence of specific events in an event log. The event log, in tum, documents the treatment provided to a patient andior events that have occurred daring the course of a patieni encounter. {0134} In some examples, the event log application 140 is further configured to respond to input selecting a control by executing a process that is associated with the control. For instance, in some examples, controls associated with administration of CPR, EPI, and shocks include timers and / or counters that are reset andéor incremented via execution of the process associated with the control. Further these processes can provide notifications after a threshold amount of {ime has elapsed since the control was last selected. For instance, the event log application 140 can provide, via the CPR control, a notification (e.g., {lashing icon, color change, textual prompt) after 2 minutes has passed since CPR chest compressions were started or after 10 seconds has elapsed since CPR was paused. This notification after a predefined period of time, typically 2 minutes, of chest compressions is to remind the user that an inferval of CPR has passed and that another phase in treating the patient may be required, such as a period of ECG analysis to determine whether the patient is in need of electrotherapy (e.g., defibrillation shock) or a short pause for one or more positive pressure ventilation breaths to be applied. Once this pause {e.8.. for ECG analysis and / or ventilations) has passed, then chest compressions should immediately resume. Accordingly, the notification after 10 seconds of a pause in chest compressions may be appropriate to remind the user that chest compressions should resume. Similarly, in some examples, the event log application 14{1 can provide, via the EPI control, a notification after 3 minates has passed since EPL was last adoninistered. Such a notificadon may be appropriate to remind the user that a subsequent dosage of EPI is to be administered. These notifications can include causing the contro! to flash, become highlighted, change color, prompt with text, and / or provide another visual indication. Or, in some cases, an audible and / or haptic notification may be provided by the mobile computing device. 0135] In some examples, to further ease treatment documentation in specific situations, the event log application 140 is configured to provide controls that enable a healthcare provider to change the documentation mode of the event log application 140 to either adult mode or pediatric mode. While operating in adult mode, the event log application 140 alters features of certain screens and controls to facilitate log eniries that mark events directed to events encouniered when treating an adult. For instance, controls associated and labeled with approaches 10 CPR that are only available to adults are visible only while the event log application 140 is operating in adult mode. Conversely, while operating in pediatric mode, the event log application 140 alters features of certain screens and controls fo facilitate log entries that mark events directed to events encountered when resting a child. For instance, controls associated with approaches to CPR that are only available to children are visible only while the event log application 140 is operating in pediairic mode. {0136] In certain examples, the event log application 140 is configured with controls to display a variety of information before, during. and afier emergency treatment of a patient. For instance, in some examples, once the appropriate connections are made to acquire the relevant information, the event log application 140 is configured to display patient identification information to the healthcare provider via a patient information screen. Further, in at least ong example, the event log application 140 is configured to display CPR quality metrics (e.g. chest compression metrics such as percentage of chest compressions that fall within a target depth, percentage of compressions that fall within a target rate, an average depth of compressions, an average rate of compressions, gic.) to the healthcare provider via a screen of the user interface. Further, in some examples, the event log application 140 is configured to provide screens with controls to receive MEWS factors and display MEWS scores calculated based on the MEWS factors, Further these screens may include a control that responds to input selecting the control by calling a rapid response or code team to, for example, the location of the mobile computing device. 0137] The ePCR application 122 can vender visual, andio, haptic, and / or tactile coment, including content relating to ePCR generation. Thus the ePCR application 122 can receive input or provide output, thereby enabling a user to interact with the mobile computing device 104. The ¢PCR application 122 can be configured to receive charting data via various mechanisms, including, but not limited to, touchscreen, voice recognition, and scanner. For example, a patient may say his / her name and the ePCR application 122 can capture the patient name and store it as a portion of charting data. The ePCR application 122 can include a camera‘scanner through which patient's driver license may be acquired / scanned and relevant information about the patient, such as name, address, age, can be stored as charting data. The healthcare provider 118A may dictate data or findings when examining the patient 116 via the PCR application 122. Such dictation can be captured and saved as charting data, according to same examples. In certain examples, the ePCR application 122 utilizes the input devices 444 and / or the output devices 430 of FIG. 18. {0138] In some examples, the ePCR application 122 implemented by a mobile computing device 104 can interoperate with a touchscreen andior a flat panel PC or some other user interface hardware and a software stack configured to drive the hardware. Portions ofthe ePCR application 122 can be stored in the memory of the mobile computing device 104 as an Android™ application, an Apples application, or other native application, and executed by the processor to interact with the healthcare provider 118. Alternatively or additionally, the memory of the mobile computing device 104 may store a browser, or some other execution environment, configured to receive and render portions of the ePCR application 122 from one or more webserver(s), 10139] In sore examples, the ePCR application 122 can generate charting data to be stored in the charting data store 134. For instance, the ePCR application 122 can include a graphical user interface, which pennits the user to select different subsets and / or display modes of the information gathered from and / or sent to other devices, according to examples of the present disclosure. In one example, the ePCR application 122 can be used to note a dosage of medicine, CPR compression depth, or other treatment parameters given to the patient at a particular time. ‘The ePCR application 122 can also be used to record biographic and / or demographic and / or historical information about a patient, for example the patient's name, identification number, height, weight, and / or medical history, according to examples of the present disclosure. The types of charting data received via the ePCR application 122 can also include patient physiologic parameters, documented events, and the like. Charting data can include, but is not limited to, patient information (c.g. name, age, gender, weight, and / or other identification andior demographic information), medical event specific information {e.g., type of service requested, disposition), and / or clinical information (e.g., patient assessment, patient blood pressure). Charting data can further include any data from the patient care record, data from physician’s chart, data from electronic health records, data from one or more health information exchanges, data from hospital charts, in addition to data from ePCRs. 0140] In some examples, each of the association generators 142A and 142B is configured to process requests to generate information that associates one or more of the medical devices 120 with a particular patient encounter. In some examples, each association generator 142A and 142B exposes and implements a software interface (e.g, an APT) configured to receive the requests to generate association information. In these examples, the ePCR application 122 and the event log application 140 are each configured to generate requests 1o generate association and to communicate the requests to the locally hosted association generator 142A or 1428. The ePCR application 122 and the event log application 140 may be configured to, for example, generate requests in response lo receiving input from the healthcare provider 118A. This input may indicate initiation of a patient encounter, termination of a patient encounter, or simply that a patient encounter is in process. Alternatively or additionally, in some examples, each association generator 142A and 142B implements a user interface configured to receive the requests to generate association information. This user interface can include controls configured (o receive input specifying initiation of a patient encounter, thai # patient encounter is in process, and / or that a patient encounter has been completed. Further, the user interface can include controls configured to receiving input to initiate acquisition of representations of identifiers of medical devices and / or to receive other elements of association information as discussed herein, In addition, the user interface can include controls configured to receive input fo initiate storage and transmission of the association information to the server(s) 108. {0141] With continued reference to FIG. 1, the mobile computing devices 104 can include a combination of devices, according to some examples. For instance, the mobile computing devices 104 can each include a processor coupled with memory configured to store data manipulated by the processor. Each of the mobile computing devices 104 may have a clock, which can be synchronized with an external time source such as a network resource or a satellite to prevent the healthcare provider 118A from having to manually enter a time of treatment or observation (or having to attempt to estimate the time of treatment for charting purposes long after the treatment was administered), according to examples of the present disclosure. Each of the mobile computing devices 104 can include one or more systems, medical device(s), and / or network interfaces configured to receive andor send data from and / or to other devices like the medical devices 102. In some examples, each of the mobile computing devices 104 can utilize these system(s), medical device(s), and / or network interfaces to communicate with another device or system (e.g, the remote computing device 106, another mobile computing device 104, and / or the server(s) 108) that aggregates of otherwise receives data from other devices, such as the medical devices 102. Alternatively or additionally, each of the mobile computing devices 104 can communicate with devices, such as the medical devices 102, by establishing of joining a previous established local network including data entry devices as well ag diagnostic and / or therapeutic medical devices. This local network can be established in an ad- hoc manner at the time of treatment of a patient or patients in the field and can include two or more proximally located devices. {0142] In various implementations, each of the mobile computing devices 104 can receive, organize, store, share, distribute, and display data from the other devices (e.g.. the medical devices 102 and other mobile computing device 104) to farther enhance the usefulness of the devices and to make it easier for the healthcare provider 118A to perform certain tasks that would normally require the healthcare provider 118A to divert visual and manual attention to the other devices separately, according to examples of the present disclosure. In other words, each of the mobile computing devices 104 can centralize, organize, and share information that might otherwise be de-centralized and disorganized, according to examples of the present disclosure, However, it should be noted that robust, bi-directional, fully authenticated network connections can require substantial computing resources and time to establish and maintain. As a consequence, at least some examples avoid these sorts of network connections. 10143] In certain examples, each of the mobile computing devices 14 can share information received from the server(s) 108 with the other devices. For instance, in one example, the mobile computing device 104A can receive information from the server(s) 108 and can share (e.g., iransmit via a local network) such information with the medical device 102A. Alternatively or additionally, if’ the medical device 102N takes an ECG reading of the patient 116, or if the medical device 102N administers a treatment (such as medication, chest compression, veutilation, defibrillation shock, ete.}, information descriptive of the ECG and / or the treatment may be shared. via mobile computing device 104B or directly, with other devices (e.g, the remote computing device 106, the mobile computing device 104A, and / or the server(s) 108) for storage in a patient record maintained therein. In another example, each of the mobile computing devices 104 can be configured to receive patient information, such as medical records, known medical conditions, and biographical information form the health records data store 110, and to share this information with one or more of the medical devices 102, This biographical information can be inserted into a patient record {e.g., an ePCR) being maintained and / or generated af the mobile computing device 104. {0144] When a mobile computing device 104 receives updated information from the other devices to which it is communicably coupled, and / or via input from a healthcare provider (e.g. either of the healthcare providers 118A or 118B), the mobile computing device 104 can send the updated information to the server(s) 108. Hence, information from one or more device(s) {e.g. the medical devices 102) may be stored locally at the mobile computing device 104 (e.g. in the memory 421) and / or at the server(s) 108 (e.g., in the memory 321, in the event log data store 146, andfor in the charting data store 134). Data from the mobile computing device 104 {and, when present, data from the other devices that may be coramunicably coupled with the mobile computing device 104) can be received by the server(s) 108 and stored in the event log data store 146, the charting data store 134, and / or the case data store 132 via the event log API 144, the ePCR API 128, and / or the case AP{ 126 as described farther below. The remoie computing device 100 can also access the stored information via these interfaces to add the stored information to the health records dasa stove 110. {0145] According to some examples of the present disclosure, each of the mobile computing devices 104 can communicably couple (e.g. automatically or manually or selectively) to one or more medical devices 102 that include a defibrillator, a patient monitor, an automated external defibrillator, a ventilator, an automated chest compression device, and / or a wearable defibrillator. In these examples, any mobile computing device 104 so coupled can receive and display patient monitoring information generated by the one or more medical devices. Such a mobile computing device 104 can also be configared to receive patient-identifving protected health information from the one or more medical devices, to permit the mobile computing device 104 to query (e.i.. across the network 112) an external database (2.1., the health records data store 110) fo retrieve additional information about the patient 116. This mobile computing device 104 can also be configured to connect with an implantable cardioverier-defibrillator (“ICD") in a similar fashion, according to examples of the present disclosure. 10146] In certain examples, each of the mobile computing devices 104 can be a tablet, smartphone, wearable device, and / or other mobile computing device and / or a combination of mobile devices that can access event log and patient charting system capabilities described herein via a server or cloud interface, for example, an interface with the server(s) 108. According to some examples of the present disclosure, the mobile computing devices 104 can include wristbands andor smart phones such as an Apple® iPhone® or iPad® with an interactive data entry interface such as a touchscreen or voice recognition data entry interface that can be communicably coupled to the tablet and tapped to indicate what was done with the patient 116 and when it was done. Further, according to some examples of the present disclosure, the mobile computing devices 104 can be integrated with the medical devices 102, such that a single device can be configured to monitor the patient, treat the patient, as well as 10 generate records and / or notes about the patient’s condition and / or treatments applied to the patient 116. In these examples, the ePCR application 122 can be embedded within the combination medical / computing device. Additional description of some components of the mobile computing devices 104 is provided further detail below with reference to FIG. 18. 10447] In various implementations, the medical devices 102 can include patient treatment devices, or other kinds of device that include patient monitoring and / or patient treatment capabifities, according to examples of the present disclosure. For example, a medical device 102 can include a defibrillator and can be configured to deliver therapeutic electric shocks to the patient. In some examples, a medical device 102 can deliver other types of treatments, such as ventilation, operating a respirator, performing CPR, and / or administering drugs or other medication. 10148] More specifically, one or more of the medical devices 102 can be, for example, a defibrillator with patient interface devices 190 such as electrodes and / or sensors configured for attachment to the patient 116 10 monitor heart rate and / or to generate electrocardiographs (ECGs), according to examples of the present disclosure. Each of the medical devices 102 can include a clock, which can be synchronized with an external time source such as a network resource or a satellite to prevent the healthcare provider 118A from having to manually enter a time of treatment or observation (or having to atteript to estimate the time of treatment), according to examples of the present disclosure. Precise clock synchronization between the medical devices 102 and the mobile computing devices 104 can be particularly helpfid in associating medical device case files to particular patient encounters, especially whers timestamps are used in at least one search criterion, as is described further below. As such, in at least some examples, each medical device 102 and mobile computing device 104 includes a timing circuit with a local clock. The timing circuits can each include a local clock, and the timing circuits can communicate with one another to determine and correct for variations between the local clocks of the timing circuits. In some examples, one of the timing circuits can act as a "master" timing circuit, and each of the other timing circuits can act as "slave" timing circuits that synchuonize with the focal clock at the master timing circuit. In some cases, these timing circuits can enable the medical devices 102 and the mobile computing devices 104 to achieve sub-microsecond level synchronization. In other cases, these timing circuits can enable the processing circuits to achieve synchronization within the range of 1-100 microseconds (e.g., 1-10 microseconds), or less. In at feast one example, the medical devices 120 and the mobile computing devices 104 utilize a timing protocol ww coordinate timing between master Uming circuits and slave timing circuits. Examples of such timing protocols can include the IEEE 1588 or Precision Time Protocol (PTP), the Network Time Protocol {NTP), the Clock Sampling Mutual Network Synchronization (CS-MNS) algorithm, the Reference Broadcast Synchronization (RBS) algorithm, the Reference Broadeast Infrastructure Synchronization (RBIS) algorithm, and the Global Positioning System (GPS). The TEEE 1588- 20K18 Standard for Precision Clock Synchronization Protocol for Networked Measurement and Control Systems is incorporated by reference herein in its entivety. The IEEE 1588 protocol is also described in further detail in Jones, Mike, "Get in Sync!: IEEE {588v2 Transparent Clock Benefits for Industrial Control Distributed Networks," Micrel, Inc. (March 22, 2012), and from Wu, Jiang and Peloguin, Robert, "Synchronizing Device Clocks Using JERE 1588 and Blackfin Embedded Processors,” Analog Dialogue 43-11 (November 2009), both of which are incorporated by reference herein in their entirety, 0149] Each of the medical devices 102 can also include and / or couple to patient interface devices 190 such as sensors to detect and / or a processor to derive or calculate other patient parameters, In some examples, one or more of the medical devices 102 are configured 10 interoperate with the patient interfaces devices 190 to monitor, detect, treat, and or derive or calculate blood pressure, temperatuge, respiration rate, blood oxygen level, end-tidal carbon dioxide level, pulmonary function, bload glucose level, and / or weight, according to examples of the present disclosure. Additional examples of the medical devices 102 and the patient interface devices 190 are described further below with reference to FIG. 18. {0150} In some examples, to initiate easy access to the medical device case files generated by ihe medical devices 102 through the generation of association information, the healthcars provider 118A can use a medical device interface present within the mobile computing device 104 to acquire representations of identifiers of the medical devices. This medical device interface can include, for example, a camera, a near-field communication sensor, a radio frequency identification sensor, a universal serial bus connector, an infrared sensor, a personal area network sensor, a proximity detector, a geolocation detector, a wireless network connector, or another sensor appropriate to gather the relevant identifying information. Notably, in certain examples, these medical device interfaces acquire the representations without establishing a Ume-consuming communication or authentication session with the medical devices. For instance, in some examples, the medical device interface includes a camera and simply scans a QR code, bar code, or device identifier visible on the medical devices. Additionally or alternatively, in some examples the medical device interface reads a NFC tag or radio frequency identification (RFID) tag affixed 10 the medical devices. Regardless of the specific technology used, this lghiweight approach to acquiring representations of the identifiers minimizes the time of the healthcare provider 118A requived io generate association information, and uliimately be able to access the integraled data source encounter structure of the patient encounter in an easy and intuitive manner, It should be noted that, in at least some examples, the identifiers of the medical devices uniquely identify each medical device. {0151] With continued reference to FIG. 1, upon completion of a patient encounter (e.g. via conclusion of patient treatment and / or transfer of the patient 116 to a healthcare facility, such as an emergency room (ER) of a hospital) and‘or during the patient encounter, ihe healthcare provider 118A may wish to provide an ER atiending or other healthcare provider 118B within an emergency response center with an integrated data source encounter structure of the patient encounter, and / or ruay wish to have inunediate access to the integrated data source encounter structure during the medical emergency. In some sifuations, the integraied data source encounter structure must be provided quickly (e.g., where the patient's condition is eritical and / or during the event). Thus, in some examples, the mobile computing device 104B is configured (e.2., via execution of the event log application 140) to transmit the association information to the mobile computing device 104C via a quick, lightweight communication technique using. for example, a medical device interfaces of a mobile computing devices 104. For example, in one example, the event log application is configured to render a visual representation of a token via a user imerface of the mobile computing device 104B. In this example, the mobile computing device 104C is configured to (e.z.. via execution of the encounter review application 148) acquire the representation of the token and transmit a request for the integrated data source encounter structure of the patient encounter via one or more of the interfaces 126 and 128. The encounter review application 148 can include the token in the request to uniquely identify the patient encounter for which an integrated data source encounter structure is sought. Completing the description of this example, the encounter review application 148 is configured to receive the response and provide the healthcare provider 1188 with the integrated data source encounter structure via a user interface. Or, as discussed further herein, the server(s) 108 may transmit the integrated data source encounter structure back to one or move of the mobile computing devices 104 located at the scene, for benefit of the healthcare providers during the event. 0152] According to examples of the present disclosure, the server(s) 108 can receive event log data and / or patient charting data {rom a mobile computing device 104 and store the data (e.g. via operation of the event log APL 144 and / or the ePCR APL 128) in the event log data store 146 and / or the charting data store 134 along with an authenticated timestamp and an identifier associating the information with a particular mobile computing device 104. In this way, data from multiple devices can be accessed by various users.

[0153] tn some examples, the network 112 can include one or more contmunication networks through which the medical device 102, the mobile computing device 104, the remote computing device 106, and the server(s) 108 can send, receive, and / or exchange data. In various implementations, the network 112 can include a cellular communication network andor a computer network, In some examples, the network 112 includes and supports wireless network and / or wired connections. For instance, in these examples, the network 112 may support one or more networking standards such as GSM, CMDA, USB, BLUETOOTH, CAN, ZigRee®:, Wireless Ethernet, Ethernet, and TCP / IP, among others. The network 112 may include both private networks, such as local area networks, and public networks, such as the Internet. It should be noted that, in some examples, the network 112 may include one or more intermediate devices involved in the routing of packets from one endpoint to another. However, in other examples, the network 112 can involve only two endpoints that each have a network connection directly with the other. {0154] The server(s) 108 can include one or more physical and / or virtual server computers configured to traplement the case API 126, the ePCR API 128, the event log API 144, the patient encounter data source integration service 130, the case data stove 132, the event log data store 146, the criteria data store 136, and the charting data store 134, As such, the server(s) 108 can include one or more application servers, web servers, and / or data base servers. The server(s) 108 can communicate with the remote computing device 106, the medical devices 102, and the mobile computing devices 104 via the network 112. The server(s) 10& can include enterprise servers configured to support an organization as a sole tenant and / or cloud servers configured to support multiple organizations as multiple tenants. {01858] The server(s) 108 may be implemented in one or more clouds that may communicably couple to one another. For example, a single cloud including one or more servers may include the elements 126, 128, 130, 132, 134, 136, 144, and 146 of FIG. 1. Alternatively, elements 126 and 132 may be implemented in a first clowd, elements 130 and 136 may be implemented in a second cloud, elements 128 and 134 may be implemented in a third cloud, and elements 144 and 146 may be implemented in a fourth cloud. As a further alternative, the elements 130 and 136 may be implemented in a same cloud as elements 126 and 132, or may be implemented in a same cloud as elements 144 and 146, or may be implemented in a same cloud as elements 128 and 134. As yet another alternative, elements 126, 128, 132, 134, 144, and 146 may be imaplemented in a first cloud and elements 130 and 136 may be implemented in a second cloud. {0156] The communication link 188a illustrated in FIG. 1 between the patient encounter data source integration service 130 and the medical device case daia store 132 is an optional link. Likewise, the communication link 1880 illustrated in FIG. | between the patient encounter data source integration service 130 and the event log data store 146 is also an optional link. Likewise, the communication link 188c ilfustrated in FIG. | between the patient encounter data source hntegration service 130 and the charting data store 134 is also an optional link. In an implementation, the patient encounter daa source integration service 130 may not communicate directly with these data stores for security purposes, In certain implementations, the patient encounter data source integration service 130 is conversant in multiple data formats and is able to interact with components of the medical device 102 and the mobile computing device 104 via a public APL which can serve as a gatekeeper to resources provided by such devices. For example, the medical device case data store 132, the charting data store 134, and the event log data store 146 may be owned by a first entity or separately owned by a first, second, and third entity. The patient encounter data source integration service 130 may be owned by a fourth entity. Thus, the API's (126, 128, and / or 144) may provide security between these various entities in regard to access 10 the data stores 132, 134, and 146. 10157] For these and / or other reasons, in certain implementations ii may be preferred that the patient encounter data source integration service 130 not communicate directly with the medical device case data store 132, the charting data store 134, and / or the event log data store 146, as indicated by the broken lines 188a, 188b, and 18%c shown in FIG. 1. In such case, the patient encounter data source integration service 130 may send the case API 126 a request for information that is stored in the medical device case data store 132. Likewise, the patient encounter data source integration service 130 may send the event log API 144 a request for information that is stored in the event log data store 146. Likewise, the patient encounter data source integration service 130 may send the ¢PCR APY 128 a request for information that is stored in the charting data store 134. Any of these requests may include appropriate security credentials. Based on the security credentials, the case API 126, the ePCR API 128, and / or the event log API 144 may either grant or deny the request for information. If the respective interface grants the request for information, then the interface will retrieve the requested information from the appropriate data store, The patient encounter data source integration service 130 may perform one or more data merge operations according io one or more criteria identified by the patient encounter data source integration service 130. When the patient encounter data source integration service 130 completes the one or more data merge operations, the patient encounter data source integration service 130) may return the merged file (for example, a file that includes medical device data merged inlo patient charting data) to the case API 126 for storage in the medical device case data store 132, 10158] In some examples, the server(s) 108 can exchange data with remote devices such as the medical devices 102, the mobile computing devices 104, and the remote computing device 106 via the case APL 126, the ePCR API 128, andfor the event log APT 144. These interfaces are configured to receive, process, and respond to conumands issued by processes implemented by the remote devices, such as the ePCR application 122, the event log application 140, and the encounier review application 148 described herein. The interfaces 126, 128, and 144 may be implemented using a variety of interoperability standards and architectural styles, For instance, in one example, the inierfiices 126, 128, and 144 are web services interfaces implemented using a representational state transfer (REST) architectural style. In this example, the interfaces 126, 128, and 144 communicate with a client process using Hypertext Transfer Protocol (HTTP) along with JavaScript Object Notation and / or extensible markup language. In some examples, postions of the HTTP communications can be encrypled to increase securily. Alternatively or additionally, in some examples, the interfaces 126, 128, and 144 are implemented as a NET web interface that responses to HTTP posts to particular uniform resource locators with data descriptive of case data, event log data, and charting data. Alternatively or additionally, in some examples, the interfaces 126, 128, and 144 are implemented using simple file transfer protocol conynands andor a proprietary application protocol accessible via a transmission control protocol socket. Thus, the interfaces 126, 128, and 144 as described herein is not limited to a particular implementation, 10159] tn some examples, the interfaces 126, 128, and 144 include a plurality of endpoints to enable reliable system performance. For instance, in at least one example, each of the interfaces 126, 128. and 144 includes a one or more first endpoints to receive and process requests for data previously stored in the case data store 132, the charting data store 134, or the event log data store 146 and one or more second endpoints to receive and process requests 10 store new data within the case data store 132, the charting data store 134, and the event log data store 146. This configuration can ensure that requests for data already stored in the case data store 132, the charting data store 134, and the event log data store 146 can be quickly serviced with nuinimal latency. This bifurcated architecture can be helpful because requests to upload ePCRs, case files, or event logs: parse the ePCRs, case files, or event logs; and store the resulting charting dats, case dats, or event log data in the case data store 132, the charting data store 134, or the event log data store 146 can require more processing time and resources,

[0160] In some examples, the interfaces 126, 12&, and 144 are configared to transmit messages {0 the patient encounter data source integration service 130 that notify the patient encounter data source integration service 130 of (and / or include) newly received case data, charting data, event log data, and association information. Where the messages merely notify the patient encounter data source integration service 130 of the presence of new data, the messages can include one or more identifiers of the new dada that can be wilized by the patient encounter data source integration service 130 to retrieve the new data from the case data store 132, the charting data store 134, and / or the event Jog data store, although the inclusion of identifiers of the new data is not a requirement. In certain examples, the case API 126 is configured to receive case files from the medical devices 102, process the case files, and transmit messages to the medical devices 102 that indicates the result of the processing. This processing can include parsing the case files to retrieve values of case data stored therein and storing the case data in the case data store 132. Similarly, in some examples, the ePCR API 128 is configured to receive ePCRs from the mobile computing devices 104, process the ePCRs, and transmit messages to the mobile computing devices 104 that indicates the result of the processing. This processing can include parsing the ePCRS to retrieve values of charting data stored therein and storing the charting data and / or the ePCRs in the charting data store 134. Likewise, in some examples, the event log APT 144 is configured to receive event logs from the mobile computing devices 104, process the event logs, and transmit messages to the mobile computing devices 104 that indicates the result of the processing. This processing can include parsing the event logs to retrieve values of event log data stored therein and storing the event log data and / or the event Togs in the event log data store 146. It should be noted that the ePCRs and / or the event Jogs can include association information, which can be referenced by the patient encounter data source integration service 130 to create consolidated case data. 0161] In some examples, the interfaces 126 and 128 are further configured to receive requests from the encounter review application 148 for consolidated case data. The request can include a token that uniquely identifies the patient encounter for which consolidated data is requested. In response lo receiving these requests, the interfaces 126 and 128 are configured to interoperate with the patent encounter data source integration service 130 to prepare andor identify consolidated case data using the processes described herein and to veturn the consolidated case data to the encounter review application 148. Where the patient encounter data source integration service has prepared consolidated case data in advance (e.g, in response to receiving association information some time in advance of receiving the request from the encounter review application 148), the patient encounter data source integration service 130 can use ihe token to simply fetch the consolidated data from its storage and transmii the consolidated data to the encounter review application 148.

[0162] Continuing with FIG. 1, the chaning data store 134 can be implemented by, for example, a database (e.g, a relational database} and stored on a non-transitory storage medium. In an implementation, the charting data store 134 includes a plurality of records that store charting data derived from a plurality of ePCRs. In at least one example, the charting data store 134 is organized inte a set of relational database tables that includes an ePCR table and an ePCR fields table, In this example, the ePCR table includes rows of data that are each descriptive of an ePCR that documents a patient encounter in the charting data stove 134. Thus, each row in the ePCR table can include fields configured to store a unique identifier of the ePCR, a timestamp indicating when the ePCR was created, and metadata descriptive of the patient encounter documented by the ePCR (e.g, patient identification information that uniquely identifies the patient, healthcare providers involved in the patient encounter, reasons the ePCR was closed ended and outcome, unique identifiers of medical devices and supplies used in the resolving the patient encounter, overall issues that occurred during the patient encounigr, and / or a type of dispaiched EMS event associated with the ePCR). 10163] Continuing with this exaraple, the ePCR fields table inclades rows of data that are each descriptive of a field stored within an ePCR. Thus, each row in the ePCR fields wable includes fields configured to store a unique identifier of the ePCR to which the field belongs, a field that aniquely identifies the field among the fields associated with the ePCR, a date / time stamp indicating when the field was populated with a value, a unique identifier of the source of the value (e.g, a particular medical device or a particular computing device), and g field that identifies (via a type identifier or textual information) one or more values associated with the field. Notably, each ePCR can have a large quantity of fields that each require entry of a specific data type. For instance, some example ePCRs may have as 100 fields, 200, fields, 400 fields, 600 fields, or more. This quantity of fields may be mandated and, therefore, it is important that each ePCR be complete. Therefore, in some examples the charting data store 134 and / or other components, such as the ePCR application 122, are configured wo prevent modification / deletion of ePCR fields by a user of the ePCR application. It should be noted that, in some examples, ePCRs can be serialized into files for wransmission to the charting data store 134, ln these examples, the charting data store 134 can store complete and distinct copies of the ePCR files themselves (e.g., as large binary objects). {0164] Continuing with FIG. 1, the case daa store 132 can be implemented by, for example, a database (e.g. a relational database) and stored on a non-transitory storage medium. In an implementation, the case data store 132 includes a plurality of records that store case data derived from case files from a plurality of medical devices used to treat patients during encounters. Moreover, in some examples, the case data store 132 can store complete copies of the case files themselves (e.g, as large binary objects). The case data stored in the case data store 132 can document patient encounters from the point of view of medical devices. As such, case data generated by a medical device during a patient encounter can include an identifier of the medical device, physiologic parameter values of the patient recorded by the medical device daring the encounier, characteristics of treatment provided by the medical device to a patient during the encounter, actions taken by healthcare providers during the encounter, and timestamps documenting when any of this information was recorded. For instance, where the medical device is a defibrillator, the case data can include patient physiologic parameters such as BCG data for the patient, as well as characteristics of therapeutic shocks delivered by the defibrillator to the patient, CPR (e.g., chest compressions and / or ventilations) performance data, and timestamps reflecting when the defibrillator was powered vp and when this information was recorded, among other information. 10165] The event log data store 146 can be implemented by, for example, a database (e.g, a relational database) and stored on a non-transitory storage medium, In one example, the event log data store includes a plurality of records that each specify a timestamped event. The event log daia store 146 is configured to store a wide variety of events. Examples of these events include CPR administration, delivery of therapeutic eleciric pulses, provision of medication, occurrence of particular ECG rhythms, return of spontaneous circulation (ROSC), patient vitals information, procedures administered to the patient (e.g., placement of an intubation tube), medical device power on, entry of protected health information (e.g., information identifying a patient), provision of medical device prompts to the healthcare provider, provision of treatment {.g., chest compressions sensed via acceleration signals generated from a sensor located on the sternum of the patient, veniilations sensed via flow / pressure signals generated from a sensor located along the patient airway), occurrence of particular ECG rhythms (e.g. ventricular fibrillation, ventricular tachycardia, asystole, pulseless electrical activity. sinus rhythm, ete), delivery of a therapeutic electric pulse to the patient, and admimistration of medication, among other events. {0166] The criteria data store 136 can be implemented by, for example, a database {e.8., a relational database) and stored on a non-fransitory storage medium. In one example, the criteria data store 136 includes a plurality of records that each specify a relationship between elements of association information and parameters of case data, event log date, and / or charting data. In this example, each of the plurality of records also includes information that ranks the relationship relative to other relationships within the criteria data store 136. This ranking can be accessed by the patient encounter data sowrce integration service during an iterative searching processes, as described further below with reference to FIGS. 15 and 16,

[0167] Criteria data store 136 optionally maintains an audit trail that tracks which data in an integrated record originated from an ePCR charting data file, and which data in the integrated record originated from a medical device case file. In certain embodiments where conflicting data exists, the most recently acquired data can take precedence aver older data. In other embodiments where conflicting data exists, the configuration information can be used to specify a hierarchy of data sowrces that determine which data lakes precedence (for example, retained) and which data is relegated (for example, discarded). {0168] In one implementation an audit trail includes reference numbers for each file processed by the patient encounter data source integration service 13( along with an indication of the result of processing each file. For example, a medical device case file could be indicated as (i) having been merged with another medical device case file, or (if) merged with an ePCR charting data file. Where multiple original medical device case files are merged and the resuliing merged file is subsequently processed by the patient encounter data source integration service 130, the information in the audit file identifying the original files can be used to allow the patient encounter data source integration service 130 to (i) ignore the merged file if the original files have already been processed: (if) select only a portion of the merged file for integration with an ¢PCR charting data file (for example, if the remainder of the merged file has already been integrated; or (iii) integrate the merged file with an éPCR charting data file with redundancy information that the ePCR API 12§& can use {o remove redundant information. {0169] The case data store 132, the charting data store 134, and the event log data store 146 can be organized according to a variety of physical and / or logical structures. In at least one example, the case data store 132, the charting data store 134, and the event log data store 146 are implemented within a relational database having a highly normalized schema and accessible via a structured query language (SQL) engine, such as ORACLE or SQL-SERVER. This schema can, in some implementations, include columns and data that enable the case data stove 132, the charting data store 134, and / or the event log data store 146 to house data for multiple tenants. In addition, althongh the description provided above illustrates the case data store 132, the charting data store 134, and the event log data store 146 as relational databases, the examples deseribed herein are not limited to that particular physical form. Other databases may include flat files maintained by an operating system and including serialized, proprietary data structures, hierarchical database, xml files, NoSQL databases, document-oriented databases and the like. Thus, the case data store 132 and the charting data store 134 as described herein is not limited to a particular implementation. {0170] The case data stove 132, the charting data store 134, and the event log data store 146 can securely store the information received from the mobile computing devices 104 and / or the medical devices 102 for longer periods of time than the remole devices to permit later use of the information. For example, the mobile computing devices 104 may receive protecied health information (2.8., patient-identifving information such as name, address, and / or social security number) via user input directly into the mobile computing devices 104, and then may convey some or all of the protected health information to the server(s 108 to query the charting data store 134 or the event Jog data store 146 for past records involving the patient 116, In an implementation, the mobile computing devices 104 can convey some or all of the patient- identifying information to other servers via the network 112 fo access patient records and / or information from various databases such as those provided by a medical facility, insurance company, medical billing service, financial record service, and / or a health information exchange. In other examples, the mobile computing devices 104 can be configured to receive information in other ways, including without limitation wired or wireless communication and / or messaging. {0171] The server(s) 108 and / or other servers accessed via the network 112 can then forward any such records or portions of such records back to the mobile computing devices 104 (e.g. for display tn an event log screen, a patient charting screen, or past medical history screen) to assist the healthcare provider 118A with the current emergency encounter. Similarly, such past encounter information may also be accessed by other users such as or the healthcare provider 1188, according to examples of the present disclosure. 10172] The remote computing device 186 can include one or more physical and / or virtual computers configured to implement the health records data store 110. The health records data store 110 can inchude records descriptive of padent medical history. These records can include a variety of patient information, such as medical history prior to an encounter, symptoms that lead to an encounter, any diagnosis identified during the encounter, treatments prescribed as a resuli of the encounter, and outcomes resulting from the treatments. In ai least one example, the remote computing device 106 and the health records data store 110 collectively act as a health information exchange (HIE) that is configured to expose one or more interfaces that support health data exchange standards, such as state-wide health data exchange standards, regional health data exchange standard, HL7 message standards, and National Council for Prescription Drug Programs (NCPDP) script standards. It should be noted that the health records data store 110 can include data generated by one organization or by other organizations or networks or third-party sources, such as hospitals, clinics, doctors’ offices, and pharmacies. Associating Processes {0173} In some examples, the system 100 is configured to execute a variety of processes that consolidate case data from a plurality of medical device case files. FIG. 4, for insiance, illustrates a consolidation process 400 that is executed by a mobile computing device (e.g. a mobile computing device 104 of FIG, 1), a patient encounter data source integration service (2.4. the patient encounter data source integration service 130 of FIG. 1), a case interface (e.g. the case API 126 of FIG. 1), and one or more medical devices (e.g.. the medical devices 102 of FIG, 1). {0174] The consolidation process 400 starts with the mobile computing device receiving 402 input indicating initiation of a new patient encounter. For example, the mobile computing device may receive input requesting generation of association information such as for associating data generated by different medical devices involved in the patient encounter, input requesting creation of a new ePCR, or input request creation of 8 new event log. In response to reception of the input, the mobile computing device generates 404 (e.g. via execution of an association generator 142A or 142B of FIG. 1) a token to represent the new patient encounter. For instance, the association generator 142 can generate a UUID and store the UUID as the token in local memory. At some point during the patient encounter, the mobile computing device acquires 406 one or more representations of one or more first identifiers of one or more medical devices used to treat a patient (e.g. the patient 116 of FIG. 1) during the patient encounter. For instance, the mobile computing device can acquire an image of a QR code or identifying tag fe... via NFC) that identifies a medical device. Next, the mobile computing device transmits 408 one or more messages specifying association information including the ken and the one or more first identifiers 10 the patient encounter data source integration service (e.g, via an ePCR interface or event log interface, such as the ¢PCR APL 128 or the event log API 144 of FIG, 1). 10175] As another part of the consolidation process 400, the medical devices record 419 case files for the patient during the patient encounter, For instance, the medical devices may acquire patient tine-stamped physiological data, patient demographic data, and / or healthcare provider performance data and store this case data in association with one or more second identifiers of the medical devices in local memory. The medical devices transmit 422 messages comprising the case files and the one or more second identifiers of the medical devices to the case interface. The case interface receives 424 the messages comprising the case files and the one or more second identifiers and processes 426 (e.g., parses) the case files to generate case data. Next, the case interface stores 428 the case data in association with the second identifiers within a case data store (e.g. the case data store 132 of FIG. 1) for subsequent processing by the patient encounter data source integration service.

[0176] Continuing the consolidation process 400, the patient encounter data source integration service receives 410 the message specifying the association information. The patient encounter data source integration service identifies 412 {e.g., via execution of one or more associating processes, such as those described in detail below with reference 10 FIGS. 6, 7, and 12-16) case data stored in the case data store in association with second identifiers that correspond to the first identifiers of the medical devices. It should be noted that, although comesponding medical device identifiers are helpful in identifying case files for the patieni encounter, corresponding medical device identifiers alone may be Insufficient to positively identify only case files involved in the patient encounter. As such, some examples utilize additional criterion, such as timestamps and / or geotags, as discussed further below. The patient encounter data source inicgration service generaics 414 consolidated case data from the identified case data and transmits 414 the consolidated case data to the mobile computing device {e.g., via one or both of the ePCR interface and the event log interface). This consolidated case data can comprise identified case data, charting data, and / or event log data, all associated with the same patient encounier. 10177] Continuing the consolidation / integration process 400, the mobile computing device receives 416 the consolidated data and renders 418 the consolidated data, for example via execution of a local application (e.g., the ePCR application 122, the event log application 140, and / or the encounter review application 148). In some examples. because the mobile computing device is the source of the association information for the case files generated by the multiple medical devices linked to the patient encounter, the same mobile computing device may receive the consolidated data, by request or automatically, without requiring the healthcare provider to separately access other devices which could otherwise be an inconvenient exercise that could involve authentication of other inconvenienl measures. {0178] It should be noted that in some examples the consolidated case data may also be transmitted 414 to computing device other than the mobile computing device 104A (e.g, the mobile computing device 104C or another computing device) io be rendered 429 on a user interface display, such as at a medical case review station, remote telemedicine device, or the like. For instance, the consolidated case data may be made available for a clinician who is located remote from the scene, so that he / she can provide guidance or instruction for the healthcare providers who are immediately located onsite. Alternatively, or in addition, the consolidated case data may be accessed by a user after the medical event has ended, for post- case analysis and review,

[0179] It should also be noted that in some examples of the consolidation process 400, within the operation 422 the medical devices stream case files in real-time to the case interface. In these examples, the case interface and the patient encounter data source integration service also operate in real-time to identify case data being streamed as part of a live patient encounter, consolidate the streamed case data, and transmii the consolidated case daia to the mobile computing device for real-time rendering. Accordingly, the consolidated case data may be updated in a real-time manner so that medical practitioners are able to receive live information generated by various devices located at the scene, so as fo be able to achieve a high-level perspective of all notable occurrences during the patient encounter. 10180] In some examples, the patient encounter data source integration service 130 is configured to identify a plurality of case files (e.g. generated by medical devices located at the scene) to associate with one another and, in some implementations, to associate with ePCRs and’or event logs that document a patient encounter. As discussed above, medical data from the case files, ePCRs, and event logs can be stored respectively within the case data store 132, the charting data store 134, and the event log data store 146, along with copies of the case files, ePCRs, and event logs. In some implementations, associations between case files, ePCRs, and event fogs can be stored within the data stores 132, 134, and 146 as well. FIG. 5A illustrates one example of a consolidation process $00a executed by the patient encounter data source integration service 130 in these, and other, implementations. {0181] As shown in FIG. SA, the process 500a starts with the patient encounter data source integration service receiving 502a association information from the mobile computing device 104 located at the scene which has acquired identifying information from the medical device(s) and subsequenily generated the sssociation information to provide the link for the data originating from the medical device(s). In some examples, the healthcare provider using the mobile compating device for associating the medical device data may provide input on the mobile device to generate the association information between medical devices, and to send a request to the server(s) for associating of the relevant corresponding case files together. The patient encounter data source integration service can receive 502a a message generated from an interface (e.g. case APT 126, ePCR API 128 and / or event log API 144 of FIG. 1) including the association information. Alternatively or additionally, in some examples, the patient encounter data source integration service can receive S02 the association information from a data store (e.g, the charting data store 134 and / or the event log data store 146 of FIG. 1). In these examples, the patient encounter data source integration service can utilize identifiers of charting data or event log data included in a message from the interface to request and receive 502a the association information as contained within the charting dala or the eveni log data. Alternatively or additionally, in these examples, the patient encounter data source integration service can request aud receive 302a charting data added to the charting data store or event log data added to the event log data store afler a predefined timestamp maintained by the patient encounter data source integration service to mark the last time new charting data or event log data was requested. {0182] Continuing the process 50{la, the patient encounter data source integration service generates 504a at least one search criterion based on the association information. In some examples, the at least one search criterion specifies the identifiers of the plurality of medical devices included in the association information and at least one predetermined relationship between at least one element of the association information and at least one parameter associated with a medical device case file. The predetermined relationship can vary between examples. For instance, in some examples, the predetermined relationship can be an equality between the at least one element and the at least one parameter. A predetermined relationship of equality can be particularly useful where the at least one element and the at least one parameter include maneric values or strings that can be matched or satisfied with precision. Alternatively or additionally, the predetermined relationship can be a proximity or similarity between the at least one element and the at least one parameter. A predetermined relationship based on proximity or similarity can be particularly useful where the at least one element and the at least one parameter include timestamps, physiological measurements taken at different times or by different devices, or other values that can only be matched or satisfied inexactly (e.g., by satisfying a threshold proximity or similarity). Alternatively or additionally, the predetermined relationship can be a combination of equality, proximity, and / or similarity between multiple elements and parameters. For instance, in one example, the predetermined relationship requires at least one of an overlapping range between a case start time and a case end time as recorded in a case file and the association information and an equality between a patient biometric identifier from the case file and the association information and an equality between a healthcare provider biometric identifier from the case file and the association information. In some implementations the overlapping range between the case start times and end times recorded in a case {ile and the association information begins at the case start time included in the association information and ends at the case end time included in the association information. In other implementations the target time range begins tightly before or slighty after the case start time included in the association information and ends slightly before or stightly afer the case end time included in the association information. Thus, the target time range may be defined by target range start and end times that are within a threshold proximity of respective case start and end times included in the association information. For example, if the association information indicates a case start time of 10:00am and a case end time of 11:15am, the target time range may be 9:55am to 10:20am, 9:35am to 10:16am, 9:5%m to 11:20am, 10:01am to 10:15am, 10:00am to 10:14am, or any other suitable range. Thus, it will be appreciated that the difference between the target range start time and the association information case start time is not necessarily the same as the difference between the target range end time and the association information case end time. In general, clocks between different medical devices may not be exactly synced with one another. In some embodiments, the case start times / end times exactly match between the medical device case file and the association information. {0183] In some examples, the at least one predetermined relationship is a hardcoded part of the patient encounter data source integration service. In these examples, the patient encounter data source integration service generates S04a the al least one search criterion by identifying the at least one element within the association information and associating the at least one element with the predetermined relationship. For example, where the predetermined relationship is proximal and reqeires a parameter of a case file be within a range of an element of the association information and the element is a timestamp indicating when a case documenting an encounter was started, the patient encounter dala source integration service generates 504a the at least one search criterion by identifving the timestamp within the association information and associating the timestamp with the range of case start times for subsequent use in searching 5063. 1t should be noted that such a range can be a dynamic value calculated by the patient encounter data source integration service and / or a predetermined value, For instance, a range can include a caloulated range between a case start ime and a transfer-of-care time from the association information. Aliernatively or additionally, a predetermined range of case stant times can be, for example, between 0-1, 0-2, 0-8, and 1-10 minutes. Any given predetermined relationship can apply these ranges between elements and time parameters indicating the same event (e.g. case start times) or beiween elements and time parameters indicating different events (e.g., a case start time and a treaiment time or a transfer time). {0184] In some examples, the at least one predetermined relationship is soficoded and stored within a criteria data store (e.g., the criteria data store 136 of FIG. 1). In these examples, the patient encounter data source integration service can generate 04a the at least one search criterion by identifying a preferred predetermined relationship from the criteria data store prior io identifying, within the association information as described above, the at least one element specified by the predetermine relationship. For inslance, in some examples, the patient encounter data source integration service can identify the preferred predetermined relationship by finding the predetermined relationship with the highest rank that has not yet been used by the current instance of the process 500a. {0185] It should be noted that each of the at least one element and the at least one parameter can be a single element or parameter or a plurality of elements or parameters. For instance, in some examples, the at least one element is a timestamp indicating a time when an ePCR or event log was opened and the at least one parameter is a timestamp indicating a time when a case file was started, In other examples, the at least one element includes a plurality of elements and the at least one parameter includes a plurality of parameters. In some of these examples, the plurality of elements includes a umestamp indicating a ime when an ¢PCR or event log was uploaded to the server(s) 108 and an identifier of a mobile computing device that generated the ePCR or event log and the plurality of parameters includes a timestamp indicating a time when the case file was uploaded to the server(s} 108 and an identifier of a medical device that generated the case file. Other elements of association information can include patient identifiers, healthcare provider identifiers, medical device identifiers, timestamps indicative of patient transfer, patient treatmeni information, patient medical information. patient demographic information, and physiological measurements specified in the charting data. Other parameters associated with case files can include patient identifiers, healthcare provider identifiers, medical device identifiers, timestamps indicative of patient transfer, patient reatment information, patient medical information, patient demographic information, and physiological measurements taken by a medical device specified in the case file. The patient identifiers can include biometric information (e.g., facial recognition information, fingerprint information, retinal scan information, and the like). The medical device identifiers can include identifiers manually entered into an ePCR, identifiers retrieved from memory of the medical device, identifiers electronically transmitted by the medical device to the mobile computing device, and / or identifiers scanned from a bar or quick response code associated with the medical device. The physiological measurements can include blood pressure, body temperature, respiralory rate, heart rate, and elecuocardiogram (ECG) data, among other physiological data. 0186] Continuing the process 500a, the patient encounter data sowce integration service searches 506a the case data for a case file that matches or satisfies the at least one search criterion, During this searching 506a, the patient encounter data source Integration service can identify S08a a case file to associate with the association information based on the at least ong search criterion. For instance, the patient encounter data source integraiion service can identify S0Ra a case file as a corresponding case file where a parameter associated with the case file, stored in the case data, satisfies the predetermined relationship with an element of the association information stored in the at least one search criterion.

[0187] Where the patient encounter data source integration service identifies 508a an association of corresponding case data, the patient encounter data source integration service stores S1ita an integrated data source encounter structure including case data (which may be streaming real-time} from the plurality of medical device case files for subsequent processing, aud the process 500a ends. The integrated data source encounter structure can include, for example, a copy of or a pointer to the one or more of the plurality of medical device case files, case data generated from the plurality of medical device case files, and / or charting data andfor event log data containing or associated with the association information. As described above, association information can be associated with charting data and / or event log data via an identifier of a mobile device used to create both the association information and the charting data and / or the event log data. Further, in some examples, the integrated data source encounter structure can include a supplemented ePCR or event log that includes case data imported from and the associated phurality of medical device case files. The integrated data source encounter structure can be stored, for example, in the charting data store, the event log data store, and / or the case data store.

[0188] FIG. 5B illustrates an example of an integration process S00b that is executed by the patient encounter data source integration service 130 and that identifies one or more medical device case files that include a medical device identifier that matches (e.g., exactly or closely matching) a medical device identifier included in the association information. 0189] As shown in FIG. 5B, the process 500b starts with the patieni encounter data source integration service 130 receiving 502h association information uploaded by the mobile computing device 104, The patient encounter data source integration service 130 can receive 502b within the process 500b by executing actions such as {hose executed by the patient encounter dala source tegration service 130 ta receive 502a within the process 500a described above with reference to FIG, 5A. 0190] The patient encounter data source integration service 130 generates 504b at least one search criterion that specifies that a medical device identifier included in the association information matches (e.g., exactly or closely matching) a medical device identifier included in one or more medical device case files, The medical device identifier may include information from, for example, an RFID tag, a barcode, or a QR code. The medical device identifiers can include identifiers manually entered into an ePCR, identifiers retrieved from memory of the medical devices, identifiers electronically transmitted by the medical devices to the charting device, and / or identifiers scanned from a bar or QR code associated with the medical devices.

[0191] Continuing the process S00b, the patient encounier daia source integration service 130 searches SO6b for case files that satisfy the at least one sesrch criterion. In particular, the patient encounter data source integration service 130 searches for medical device case files that include a medical device identifier that matches (e.g., exacily or closely matching) a medical device identifier included in the association information. Where the patient encounter data source integration service 130 identifies 508b one or more case files that include the medical device identifier based on the at least one search criterion, the patient encounter data source integration service 130 stores S10b an integrated data source encounter structure including case data and the process 500b ends. The patigut encounter data sonrce integration service 130 can store 310b within the process S00b by executing actions such as those executed by the patient encounter data source integration service 130 (o store $10a within the process 500a described above with reference to FIG. 5A.

[0192] Another example of an integration process that is executed by the patient encounter data source integration service 130 identifies a medical device case file that includes a case start time and / or case end time that matches {¢.¢.. exactly or closely matching) a case start time and / or case end time included in the association information. As used herein, matching a case start time and / or end time from a medical device case file with a case start time and / or end time included in the association information can include times that are within g target time range. In some implementations the target time range begins at the case start time included in the association information and ends at the case end time included in the association information. In other implementations the target time range begins slightly before or slightly afier the case start ime included in the association information and ends slightly before or slightly after the case end time included in the association information. Thus, the target time range may be defined by target range start and end times that are within a threshold proximity of respective case start and end times included in the association information. For example, if the association information indicates a case start time of 10:00am and a case end time of 10:15am, the target time range may be 9:55am to 10:20am, 2:55am to 1:16am, 9:59am to 10:20am, 10:01am 0 1k) 5am, 10:00am to 10:14am, or any other suitable range. Thus, it will be appreciated that the difference between the target range start time and the association information case start ime is not necessarily the same as the difference between the target range end time and the association information case end time. In general, clocks between different medical devices may not be exactly synced with one another. In some embodiments, the case start times‘end times exactly match between the medical device case file and the association information, In an example process, the patient encounter data source integration service 130 generates at least one search criterion that specifies that a case start time and / or case end time included in the charting data matches {e.¢., exactly or closely matching) a case stant ime and / or case end time included in the medical device case file. For example, in one implementation a case start time included in the association information matches a ease start time included in a given medical device case file. In another implementation, a case end time included in the association information matches a case end time included in a given medical device case file, In another implementation, (a) a case start time included in the association information matches a case start time included in a given medical device case file and (b) a case end time included in the association information matches a case end time included in a given medical device case file. The patient encounter daia source integration service 130 then searches the case data for ong or more case files that satisfy the at least one search criterien. In particular, the patient encounter data source integration service 130 searches for one or more medical device case files that include a case start time and / or case end time that matches a case start time and / or case end time included in the association information. Where the patient encounter data source integration service 130 identifies one or more case files to associate with the association information based on the at least one search criterion, the patient encounter data source integration service 130 stores an integrated data source encounter structure, for example by executing actions such as those executed by the patient encounter data source integration service 130 to store §10a within the process 500a described above with reference to FIG. 5A. 10193] FIG. 5C illustrates an example of an integration process 500c that is executed by the patient encounter data source integration service 130 and that identifies one or more medical device case files that include a case start time and / or a case end time that are within a “target time range” that is defined based on case start aud end times included in the association information. In some implementations the farget lime range begins at the case start time included in the association information and ends al the case end lime included in the association information. In other implementations the target time range begins slightly before or slightly after the case start time included in the association information and ends slightly before or stightly after the case end time included in the association information. Thus, the target time range may be defined by target range start and end times that are within g threshold proximity of respective case start and end times included in the association information. For example, if the association information indicates a case start time of 10:00am and a case end time of 10:15am, the targel time range may be 9:55am to 10:20am, %:55am to 10:16am, 9:5%am to 10:20am, 10:01am to 10:15am, 10:00am to 10:14am, or any other suitable range. Thus, it will be appreciated that the difference between the target range start time and the association information case start lime is not necessarily the same as the difference between the target range end time and the association information case end time. {0194] As shown in FIG. SC, the process S00¢ starts with the patient encounter data source integration service 130} receiving S02c association information uploaded by the mobile computing device 104. The patient encounter dala source integration service 130 can receive 502¢ within the process 500c by executing actions such as those executed by the patient encounter data source integration service 130 to receive S02a within the process Sia described ahove with reference to FIG. SA. {0195} The patient encounter data source integration service 130 generates S04c at least ong search criterion that specifies that a case start lime and a case end time included in one or mors medical device case files are within a target time range. As noted above, the target time range is defined based on case start and end times included in the association information. In some implementations the target time range begins at the case start time included in the association information and ends at the case end time included in the association information. In other implementations the target time range begins slightly before or slightly after the case start time included in the association information and ends slightly before or slightly afler the case end time included in the association information. {0196] Continuing the process S00, the patient encounter data source integration service 130 searches $06¢ for one or more case files that satisfy the at least one search criterion, In particular, the patient encounter data source integration service 130 searches for one or more medical device case files that include a case start time and a case end time that are within the specified target time range. For example, in one implementation the patient encounter data source integration service 130) generates $04 the at least one search criterion by defining the target time range based on relevant timestamps within the association information. In another implementation the patient encounter data source integration service 130 generates {4c the at lenst one search criterion by defining the target time range based on relevant timestamps within the association information and applying a suitable threshold proximity to the target range start time and / or the target range end time. Thus, the target time range is not necessarily defined by the start and end times included in the association information. Where the patient encounter data source integration service 130 identifies S08¢ one or more case files to associate with the association information based on the at least one search criterion, the patient encounter data source integration service 130 stores 510c an integrated data source encounter structure and the pracess S00¢ ends. The patient encounter data source integration service 130} can store $10c within the process 500c by executing actions such as those executed by the patient encounter data source integration service 130 to store 510a within the process 500a described above with reference to FIG. SA. {0197] FIG. 5D illustrates an example of an integration process 500d that is executed by the patient encounter data source integration service 130 and that identifies one or more medical device case files that include (a) a medical device identifier that matches (e.g., exactly or closely matching) a medical device identifier included in the association information, and (b) a case start time and a case end time that are within a “target time range” that is defined based on case start and end times included in the association information. As noted above, in some iniplementations the target tume range begius at the case start time included in the association information and ends at the case end time included in the association information. In other implementations the target time range begins slightly before or slightly after the case start time included in the association information and ends slightly before or slightly after the case end time included in the association information. Thus, the target time range may be defined by target range start and end times that are within a threshold proximity of respective case start and end times included in the association information, as discussed previously with regards to FiGs, SA - 5C. The difference between the target range start time and the association information case start time is not necessarily the same as the difference between the target range end time and the association information case end time, 10198] As shown in FIG. 5D, the process 500d starts with the patient encounter data source integration service 130 receiving §02d association information uploaded by the mobile computing device 14. The patient encounter data source integration service 130 can receive 5024 within the process 300d by executing acdons such as those executed by the patient encounter data source integration service 130 w receive 502a within the process 500a described above with reference to FIG. SA. {0199] The patient encounter data source integration service 130 generates 504d at least one search criterion that specifies that (a) a medical device identifier included in the association information matches (¢.g., exactly or closely matching) a medical device identifier included in one or mare medical device case files, and (b) a case start time and a case end time included in the one or more medical device case files are within a target time range. As noted above, the target time range is defined based on case start and end times included in the association information. In some implementations the target time range begins at the case start time included in the association information and ends af the case end iime inchuded in the association information. In other implementations the target time range begins slightly before or slightly after the case start time included in the association information and ends slightly before or slighily after the case end time included in the association information. {0200] Continuing the process 500d, the patient encounter data source integration service 130 searches 506d for one or more case files that satisly the at least one search criterion. In particular, the patient encounter data source integration service 130) searches for one or more medical device case files that include (2) a medical device identifier that maiches (2.g., exactly or closely matching) a medical device identifier included in the association information, and (b) a case start time and a case end time that are within the specified time range. Where the patient encounter data source integration service 130 identifies 508d a case file to associate with the association information based on the at least one search criterion, the patient encounter data source integration service 130 stores S10d an inlegrated data source encounter structure and the process 500d ends. The patient encounter data source integration service 130 can store 510d within the process 500d by executing actions such as those executed by the patient encounter data source integration service 130 to store 510a within the process 500a described above with reference to FIG. SA. {0201] As noted above, a search criterion specifies at least one relationship between medical device case files and enables the identification of one or more of the medical device case files that have data to be integrated into an integrated data source encounter structure. FIGs. 5B tough SD illustrate example file integration processes, each of which uses one or more search criteria to search for and identify one or more medical device case files. Other search criteria can be used in these and other implementations, including one or more of the following: (i) a search criterion specifying that a case start time included in a medical device case file is within a threshold proximity of a case start time included in association information; (i) a search criterion specifying that a case end time included in a medical device case file is within a threshold proximity of a case end time included in association information; (iil) a search criterion specifying that case start and end times included in a medical device case file are both within a target time range, wherein the target time range begins at a case start time included in association information and ends at a case end time included in the association information; and (iv) a search criterion specifying that case start and end times included in a medical device case [ile are both within a target time range, wherein the target time range begins at a specified duration before a case start time included in association information and ends at the specified duration after a case end time included in the association information. In implementations where a search criterion that relies on comparing timestamps included in association information with timestamps included in a medical device case file, optional adjustments can be included to account for different time standards upon which the timestamps in the association information and the timestamps in the medical device case file are based. Such differing time standards may be the result of using different time zones or using daylight savings time. 0202) The various search criteria and methods described in FIGS. 3B, 5C, and SD may depend apon various equipment configurations and capabilities. These configurations and capabilities may determine the manner in which the case start time, the case end time, and / or the medical device identifiers are recorded in the integrated data source encounter structure. For example, these values may be automatically recorded or manually entered or triggered. Further, these configurations and capabilities may deternune whether one or more of the case start tine, the case end time, and / or the medical device identifiers are available as search criteria. For example, in a system that lacks the capability to automatically record or prompt for one or more of the case start time, the case end time, and / or the medical device identifiers, one or more of these values may be unavailable for use as a search criteria. Finally, these configurations and capabilities may determine the relative reliability or accuracy of the case start time, the case end time, and / or the medical device identifiers as search criteria. For example, automatically recorded values may be more accurate and reliable than manually entered values. {0203] The association information may include a case start time and a case end time, These times may be recorded automatically in, for example, a patient charting file or event log. In an implementation, these times may correspond to clock times on the mobile computing device 104. For example, the case start time may be the clock time at which a patient charting application or event log application opens and initiates a new charting file and the case end time may be the clock time at which the patient charting application or event log application closes the charting file. As another example, the patient charting application or event log application may receive a case start {ime transmitted from a computer aided dispatch (CAD) or other dispaich server or device to the mobile computing device 14 and record this time in the patient charting file or event log, which may be included as part of the association information. This case start time may correspond to a clock time at the CAD or dispatch server or device at the time the case is assigned to an EMS crew. As a further example, the time may correspond to a clock time on the mobile computing device 104 at which the EMS crew accepts a case assignment {rom the CAD or other dispatch server or device, In this scenario, the mobile computing device 104 may display the case assignment, prompt the user for an acceptance, and automatically record the acceptance time as the case start time in the patient charting file or event log. In some embodiments, a case start time may correspond to the time at which a user activates and / or initiates a case file with one or more of the medical devices associated with the medical event. As yet another example, the mobile computing device 104 may receive time al a patient transport destination (e.g. based on a WIFL or BLUETOOTH or other conununicative coupling initiated at the transport destination) and automatically record this received time as the case end time. As yet a further example, the mobile computing device 104 may transmit the case file to the charting data store 134 and / or to a remote computing device 1036 (e.g., a hospital server or other computing device at a patient transport destination) and the mobile computing device 104 may record the time of transmission as the case end time. 0204] In an implementation, the mobile computing device 104 may receive and ausomatically record the case start time and / or the case end time from a geofencing application on the mobile computing device 104. For example, the geofencing application may provide a case start time to the mobile computing device 104 based on the mobile computing device 104 crossing a geofence around an EMS agency location or around a patient location. As another example, the geofencing application may provide a case end time to the mobile compating device 104 based on the mobile computing device 104 crossing a geofence around a patient location or around a patient transport destination (e.g., a hospital, a doctor's office, a dialysis center, a psychiatric center, or other cars provider location). Similarly, the mobile computing device 104 nay receive and awtomatically record the case start time and / or the case end time based on one or more GPS coordinates of the mobile computing device 104. 10205] In some implernentations, the case start time may be a time of treatment (e.g., a time thet defibrillation shock, drug, or other therapy was delivered to the patient by the medical device. The medical device also records times at which the device provides therapy (e.g, as 2 time-stamped event marker). Thus, a correlation between “case start time” may inchule a correlation between therapy delivery times as recorded in the association information and in the medical device case file. The association imformation may receive this information from the medical device (e.g. us transmitted information) or may receive this information via an entry {0 the association information. 10206] In an implementation, mobile computing device 1{4 may prompt the user to enter or confirm a case start time and / or a case end time at the ¢PCR application 122 or the event log application 140, The mobile computing device 104 may record this user entered or confirmed {ime in the association information. In this case, the recorded time may be a clock time on the mobile computing device 104 confirmed by the user or may be a time gathered from a waich or other time source separate from the mobile computing device 104 and entered into the association information by the user. 10207] For case times and other entries to the association information as discussed herein, these entries may be manual entries (e.g., via a keyboard), audio entries (e.g., via a microphone and a speech recognition capability at the mobile computing device 104), entries capiured via an augmented reality device, and / or entries captured at a wearable device that either communicates with the mobile computing device 104 or servers 108. 10208] In some scenarios, the case end time may lag behind the actual discharge of the patient from the care of EMS. For example, an EMS crew may transport a patient to a hospital, discharge the patient to the hospital, and then proceed to complete the patient chart. This lag time may be necessary operationally if the EMS crew does not have time to complete patient charting during the patient care because they do not have time to divert their attention from the patient care to the task of patient charting. Thus, even if a communicative coupling exists between the mobile computing device 104 and the medical device(s) 102A-102N with a sufficient bandwidth and signal strength to transfer files between these devices, the file association may still need to occur in the cloud because the association information may not be complete until some time after the event. At this time, the relevant medical device(s) may be redeployed or powered off. Additionally, in some cases, for privacy and data protection reasons, a caregiver must mamally initiate or confirm a file wansfer from a medical device to a mobile computing device. If the caregiver forgets to initiate this transfer, the file association can still occur in the cloud rather than based on a device to device transfer. Furthermore, the medical devices, the patient charting application, andfor the event log application may be from different vendors and may not be compatible with one another in terms of file formats. Therefore, even with au available communications channel, in the absence of an appropriate software development kit (SDK), file transfers between these devices may not be possible and may require a {le association in the cloud as described herein. 10209] The case end time may correspond to a completion of the association information or a time entered by the user, In various implementations, the case start time in the association information may be a time at which a caregiver arrives at the patient scene {e.g., an “at patient side time”) and the case end time may be a time at which the patient is discharged from the care of EMS (e.g. a “time of patient care transfir™). The time at which the caregiver arrives at the patient scene may be the eartigst time at which a medical device could be deployed andior activated for use on the patient. Thus, this time may be the relevant case siart time. Similarly, the time at which the patient care is transferred away from EMS is the latest time at which a medical device could be detached from the patient and / or deactivated. In some embodiments, a case end time may correspond to the time at which a user deactivates and / or closes a current case file with one or more of the medical devices associated with the medical event. Typically, upon atrival at a transport destination, such as a hospital, a patient is transferred from medical devices belonging lo the EMS agency to those belonging to the hospital. {0210} During care of the patient, the EMS crew may couple the patient to one or more medical devices. The medical device may automatically record a case start time or a case end time as a time of power on or power off or as a time at which a patient interface device is coupled to or removed from the patient. The medical device may recognize this coupling or removal based on the presence or absence of a physiologic signal from the patient or based on a sensor signal ihat indicates a patient connection {e.g., a closed circuit based on a proper attachment of a pair of elecivodes to a patient) or based on a sensor signal indicating thai a patient interface device has been removed from a package or otherwise deployed. In an implementation, a medical device and a mobile computing device may communicatively couple and one or more both devices may record a case start time and / or a case end time based on a time associated with the initiation of communications, In an implementation, a medical device may request a user entry or confirmation of a case start time or a case end time. {0211] In an implementation, the medical device(s} 102A-102N may automatically record a device identifier in the medical device case fle. For example, this device identifier may be a code unigue to the particular medical device (e.g, a serial number and / or model number andior other identifying information) included as metadata with the medical device case file, In an implementation, the medical device(s) 102A-102N may communicatively couple with the mobile computing device 104 and transmit the medical device identifier to the mobile computing device 104. The mobile computing device 104 may automatically record this identifier in the association information. In an implementation, the medical devices) 102A- 102N may include the medical device identifier on an exterior housing, for example, on an affixed tag or sticker or as an embossed or engraved code. The caregiver may visually inspect this code and manually enter the code at the ePCR application 122 or the event log application 1441 Alternatively, the caregiver may capture the code using a camera or other visual recording device and transmit the captured code to the mobile computing device 104 for recordation in the association information. As another option, the medical device identifier may be a bar code or QR code and the caregiver may capiure the code using a scanner and transmit the captured code to the mobile computing device 104 for recordation in the association information. In an implementation, the mobile computing device 104 may include the camera and / or the scanner. As a further option, the caregiver may read and vocalize the code and the mobile computing device 104 may include a microphone configured to capture the audible mformation and automatically record the code in the association information. In an implementation, particular medical devices may be associated with a particular EMS crew andfor EMS vehicle. In such an implementation, the caregiver may provide a crew or vehicle identification to the association information and the mobile computing device 104 may consalt a look-up table or other reference to associated a medical device identifier with the association information based on the crew or vehicle identification. {0212] Given the various possible modes of time recordation on the mobile computing device 104 and the medical device(s) 102A-102N, the reliability and accuracy of any correlation, or natch, between the times in the association information and the medical device case file may vary to differing degrees depending on how each device records these times. Similarly, the various possible modes of capturing and recording the medical device identifier by the mobile computing device 104 may determine the reliability and accuracy of any correlation, or match between the information in the association information and in the medical device case file. Therefore, a system may use one or other or both of these criteria, as exemplified in FIGS, 3B, 5C. and SD. as search critena for file associations. {0213 Use ofboth of these criteria may be not be necessary for a small EMS agency that owns only one or a few medical devices, such as defibrillators, antomated compression devices, ventilators, ete. andor has only one or a few medical devices deployed simulianeously (e.g. for two concurrent emergencies or scheduled transports). In this case, the times may be sufficient to associate the medical device case files and the association information. However, for a large EMS agency, such as an agency in a major metropolitan area, the agency may own 100-200 medical devices and may have 10-20 concurrent deployments. In this case, the times may be insufficient and the medical device identifiers may be needed in conjunction with the times for accuracy of the file associations. This situation may be panicularly true for a mass casualty situation where the times would substantially overlap between patients and there may be confusion in the field regarding timely recordation of medical device identifiers. Therefore, in this case, the search criterion may require several parsmeters for reliable snd accurate file associations. A multiple or mass casualty situation also provides another example of a situation in which a file association may need to occur in the cloud even if a communicative coupling exists between the mobile computing device 104 and the medical device(s) 102A~102N with a sufficient bandwidth and signal strength to transfer files between these devices. For example, if a long range communicative coupling such as WIFI or cellular is unavailable (e.g., in an inlerior space, a parking garage, an wban canyon, a remote location, ete.), the devices may only be able to communicate via a short range connection such as BLUETOOTH. However, multiple devices within short range communications distance of one another may interfere with detection capabilities that enable an automatic transfer of files between the medical devices and the mobile computing device. 10214] FIG. 6 illustrates one example of an associating process 600 executed by a patient encounter data source integration service (e.g., the patient encounter data source integration service 130 of FIG. 1) in some inaplementations. The patient encounter data source integration service can be configured to execute the process 600 in response {0 an event, such as expiration of a periodic timer and / or a request from a calling process (e.g., the ePCR API 128 and or the event log API 144 of FIG, 1). 0218] As shown in FIG. 6, the process 600 starts with the patient encounter data source integration service receiving 602 association information. This association information may be included in a message from the calling process or stored with charting data or event log data processed by the patient encounter data source integration service in response fo expiration of the periodic timer. After receiving 602 the association information, the patient encounter data source integration service generates 604 at least one search criterion based on the association information and searches 606 case data stored in a case data store (e.g, the case data store 132 of FIG. 1) for ove or more case files thai match or satisfy the at least one search criterion. In some examples, the patient encounter data source integration service can receive 602, generate 604, and search 606 within the process 600 by executing actions such as those executed by the patient encounter data source integration service to receive $02, generate 504, and search 506 within the process 500 described above with reference to FIG. §. 0216] Next, the patient encounter data source integration service determines 608 whether at least one corresponding ease file was identified by the search 606. Where the patient encounter data source integration service determines 608 that at least one corresponding case file was not found, the patient encounter data source integration service generates and returns 612 an error message to the calling process, and the process 600 ends. Where the patient encounter data source integratinn service determines 608 that at least one corresponding case file was found, ihe patient encounter data source integration service retamns 610 a message including the at least one corresponding case file or at least one identifier thereof io the calling process, and the process 600 ends. 0217] FIG. 7 illustrates one example of an associating process 700 executed by a patient encounter data sowrce integration service (e.g., the patient encounier data source integration service 130 of FIG. 1) in some implementations. The patient encounter data source integration service can be configured to execute the process 700 in response to an event, such as expiration of a periodic timer and / or a request from a calling process {e.g., the ePCR API 128 of FIG. 1). {0218] As shown in FIG. 7, the process 700 starts with the patient encounter data source integration service receiving 702 association information. This association information may be included in a message from the calling process or stored with charting data or event log data processed by the patient encounter data source integration service in response to expiration of the periodic timer. After receiving 702 the association information, the patient encounter data source integration service generates 704 at least one search criterion based on the association information and searches 706 case data stored in a case data store (e.g., the case data store 132 of FIG. 1) for one or more case files that match or satisfy the at least one search criterion. In some examples, the patient encounter data source integration service can receive 702, generate 14, and search 706 within the process 700 by executing actions such as those executed by the patient enconnter data source integration service to receive 502, generate 504, and search 506 within the process 500 described above with reference to FIG. 3. {0219} Next, the patient encounter data source integration service determines 708 whether at least one corresponding case file was identified by the search 706. Where the patient encounter data source integration service determines 708 that at least one match was not found, the patient encounter data source integration service resets 714 resets a timer (e.g, the event-iriggering periodic timer described above) and transmits 716 a refurn message to the calling process that indicates no corresponding case file was found. Where the patient encounter data source integration service determines 708 that at least one corresponding case file was found, the patient encounter data source integration service refurns 710 the at least one corresponding case file or at least one identifier thereof to the calling process, and the process 700 ends. {02201 FIG. 8 illustrates one example of a consolidation process 800 executed by a plurality of medical devices, a patient encounter data source integration service, and a mobile computing device {e.g., the medical devices 102, the patient encounter data source integration service 130 and a mobile computing device 104 of FIG. 1) in some implementations. As shown in FIG. 8, operations rendered with dashed line boarders may not present in some examples. {0221] Within the process 800, the mobile computing device transmits 802 a request message io the patient encounter data source integration service. This request message can include a request to associate 10 case data (e.g. a medical device case file or a portion thereof) from multiple medical device case [iles to one another. The request message can include association information to be used to develop at least one search criterion and / or an identifier of such association information to be (e.g. an identifier of charting data and / or event log data that subsurnes the association information within a charting data store and / or an event log data stove, such as the charting data store 134 and / or the event log data store 146 of FIG. 1). In some examples, the mobile computing device can transmit the request message and / or the association information to the patient encounter data source integration service via one ar more messages to an ePCR interface andéor an event Jog interface (e.g., the ePCR API 128 and / or the event log API 144 of FIG. 1) implemented by a server (e.g., a server of the server(s) 108 of FIG. 1). Altematively or additionally, the mobile computing device can store the association information within the charting data store and / or the event log data store via the ePCR interface and / or the event fog interface as part of transmitiing 802 the request message. 10222] Continuing the process $00, the patient encounter dala source integration service receives $04 the association information from the ePCR inierfaice and / or the event log interface or the charting data store and / or the event log data store. This action is followed by the patient encounter data source integration service generating 806 at least one search criterion based on the association information. In some examples, the patient encounter data source integration service can receive 804 and generate 806 within the process 800 by executing actions such as those executed by the patient encounter data source integration service to receive 502 and generate 504 within the process 300 described above with reference to FIG. 5. 10223] As shown in FIG. 8, the medical devices transmit 808 one or more request messages to a case interface (e.g. the case API 126) implemented by a server (e.g, a server of the server(s) 108 of FIG. 1). The request messages can include one or more requests to import a plurality of case files into a case data store (e.g. the case data store 132 of FIG. 1). The request messages can include the case files to be imported. In response to receiving the request messages, the case interface can receive the case files, parse the case files to retrieve case data from the case files, store the case data and / or the case files in the case data store, and transmit one or more response messages to the medical devices that indicate results of processing the request TesSages. {0224] Continuing the process 800, the patient encounter data source integration service identifies 810 case data associated with the imported case files as satistving the at least one search criterion. In some examples, the patient encounter data sowree integration service can identify 810 within the process 800 by executing actions such as those executed by the patient encounter data source integration service in identifying S08 within the process 500 described above with reference to FIG. 5. The patient encounter data source integration service can further generate and transmit a confirmation request including one or more identifiers of case files and / or other metadata descriptive of the case files to the mobile computing device as part of identifying 810 the case files. The one or more identifiers of the case files can include, for example, one or more timestamps indicating when the case files were created by the medical devices and idemifiers of medical devices that generated the case files, 10225] Continuing with the process 800, the mobile computing device receives 812 the confirmation request including the identifiers and / or other metadata of the case files from the patient encounter data sowrce integration service and prompts a user (e.g. the healthcare provider 118A of FIG. 1) to confirm whether the case files are descriptive of the same patient encounter. In some examples, the mobile computing device prompts the user via an ePCR application and / or an event log application (e.g., the ePCR application 122 and / or the event log application 140 of FIG. 1) using the identifiers. FIG. 9 illustrates one example of a user interface screen 9 that the ePCR application and / or the event log application is configured {o render in response to receiving a confirmation request. As shown in FIG. 9, the screen 900 includes columns of case controls 902 and 904; a column of confirmation controls 906; and a submit control 208. The case controls 902 and 904 are configured to display the identifiers of and information regarding the case files identified in the confirmation request. More specifically, each of the case controls 902 is configured to display a case start time and each of’ the case controls 904 is configured to display an idenuifier of the medical device that generated the case file. The confirmation controls 906 are configured lo receive input indicating whether the case file identified by the row in which the confirmation control 906 resides is confinned or not confirmed to be associated for other case files (e.g. that sach was generated during the same patient encounter). The submit control 908 is configured fo receive input indicating that {he user has confirmed or not confirmed the case files as desired. {0226] Returning to the process R00, where the ePCR application and / or the event log application receives input confirming the case {Hes (e.g., selection of the submit control 908), the ePCR application and / or the event log application transmits 814 a confirmation response to the patent encounter data source integration service (e.g., via the ePCR interface and / or the event log interface). The patient encounter data source integration service receives 816 the confirmation response. {0227] In some examples, the patient encounter data source integration service consolidates 818 the case data [rom the associated case files into consolidated case data in an integrated data source encounter structure, For instance, in some examples, the patient encounter data source integration service consolidates 818 the case data into consolidated case daia by establishing associations between all, or a portion of, the records of case data stored in the case data store that originated from the associated case files. Further, the patient encounter data source integration service can integrate the consolidated case data, or a portion thereof, with charting data and / or event log data by, for example, importing at least a portion of the consolidated case data into an ePCR and / or an event log as part of the jutegrated data source encounter structure. This consolidation generates supplemented ePCRs and / or supplemented event logs. Moreover, the patient encounter data source integration service can integrate the consolidated case data, or a portion thereof, with one or more case files of the associated case files by, for example iraporiing at least a portion of the consolidated case data into the one or more case files. This consolidation generates supplemented case files. 10228] Continuing the process 800, the patient encounter data source integration service stores and / or transmits 819 the consolidated case data to the medical devices and / or the mobile computing device. For instance, in some examples, the patient encounter data source integration service stores the supplemented case files in the case data store andfor transmits 819 the supplemented case files to the medical devices. Alternatively or additionally, in some examples, the patient sucounter data source integration service stores the supplemented ePCR and / or supplemented event Jog in the charting data store and / or transmits 819 the supplemented ePCR and / or the supplemented event log to the mobile computing device, 0229] Where the patient encounter data source integration service transmits 819 the supplemented case files lo the medical devices, the medical devices receive 822 the supplemented case files and transmit and / or locally store 824 the supplemented case files. Where the patient encounter data source integration service transmits 819 the supplemented ePCR and / or the supplemented event log to the mobile computing device, the mobile device receives 826 the supplemented ePCR and / or the supplemented event log and transmits andfor locally stores 82& the supplemented ePCR andor the supplemented event log. {02301 FIG. 10 illustrates one example of a consolidation process 1000 executed by a patient encounter data source integration service and a mobile computing device (e.g, the patient encounter data source integration service 130 and the mobile computing device 104 of FIG. 1) in some inplementations. {0231] As shown in FIG. 10, the process 1000 starts with the patient encounter data source integration service receiving 1002 association information from the mobile computing device. This action is followed by the patient encounter data source integration service generating 1004 at least one search criterion based on the association information, searching 1006 case data stored in a case data store (e.g. the case daa store 132 of FIG. 1) for a plurality of medical device case files that match or satisfy the at least one search criterion, and identifying 1008 the medical device case files as being associated with one another and a specific patient encounter based on the at least one search criterion. In some examples, the paiient encounter daia source integration service can receive 1002, generate 1004, search 1006, and identify 1008 within the process 1000 by executing actions such as those executed by the patient encounter data source integration service to receive S02, generate 504. search 506, and identity S08 within the process S04) described above with reference to FIG. 5. 0232] Next, the patient encounter data source integration service transmits 1010 identifiers of the identified case files wo the mobile computing device. These identifiers can include a timestamp indicating when the case files were generated by the medical devices. In some examples, the patient encounter data source integration service transmits 1010 the timestamps to an PCR application and / or an event log application (e.g.. the PCR application 122 and / or the event log application 140 of FIG. 1) hosted by the mobile device. In certain examples, the mobile computing device receives the identifiers of the case files from the patient encounter data source integration service and prompts a user (2.2. the healthcare provider 118A of FIG. 1} to confirm whether the case files are descriptive of the same patient encounter. In some examples, the mobile computing device prompts the user via the ePCR application and / or the event log application. Where the ePCR application and / or the event log application receives input confirming the case files, the ePCR application and / or the event log application transmits a confirmation message to the patient encounter data source integration service (e.g. via an ¢PCR interface andior an event log interface such as the ePCR interface 126 and / or the event log API 144 of FIG. 1). {0233} Continuing the process 100K), the patient encounter data source integration service receives 1012 the confirmation message from the patient mobile computing device, stores 1014 an integrated data source encounter structure including case data from the confirmed case files (which may be streaming real-time from medical device(s) during the patient encounter), and the process 1000 ends. In some examples, the patient encounter data source integration service can store 1014 the integrated data source encounter structure within the process 1000 by executing actions such as those executed by the patient encounter data source integration service to store S10 an integrated data source encounter siructure within the process 500 described above with reference to FIG. 5. 10234] FIG. 11 illustrates one example of a consolidation process 1100 executed by a patient encounter data source integration service and au ePCR application, an event log application, and / or a device association application hosted by a mobile computing device (e.g., the patient encounter data source integration service 130), the ePCR application 122, the event log application 140 and / or patient encounter device association application 150, and the mobile compuling device 14 of FIG. 1} in some implementations.

[0235] As shown in FIG. 11, the process 1100 starts with the patient encounter data source integration service receiving 1102 association information. This action is followed by the patient encounter data source integration service generating 1104 at least one search criterion based on the association information and searching 1106 case data stored in a case data store {e.g., the case data store {32 of FIG. 1) for a plurality of medical device case files that match of satisfy the at feast one search criterion. In some examples, the patient encounter data source integration service can receive 1102, generate 1104, and search 1106 within the process 1100 by executing actions such as those executed by the patient encounter data source integration service to receive S02, generate 504, and search $06 within the process $00 described above with reference to FIG. 5. {0236] Next, the patient encounter data source integration service determines 1108 whether the search resulted in identification of one or more case files that match or satisfy the at least one search criterion. Where the patient sucounter data source integration service determines 1108 that no corresponding case files were identified, the process 1100 ends. Where the patient encounter data source integration service determines 1108 that one or more corresponding case files were identified, the patient encounter data source integration service generates 1110 metadata descriptive of the corresponding case files. This metadata can inclade identifiers of the corresponding case files, such as timestamps indicating when the corresponding case file was created by medical devices, identifiers of the medical devices that created the corresponding case files, and / or identifiers of one or more mobile computing devices coupled with the medical devices during creation of the case files, among other identifiers. 10237] Continuing the process 1100, the patient encounter data source integration service transmits 1112 the metadata to the ePCR application, the event log application, and / or the device association application over a network (e.g., the network 112 of FIG. 1). In some examples, the patient encounter data source integration service transmits the metadata vig messages generated by one or more interface calls (e.g.. calls supported by the ePCR API 128 andor the event fog API 144 of FIG. 1). These messages can include a confirmation request.

[0238] The ePCR application, the even log application, and / or the device association application receives 1114 the metadata and renders 1116 a prompt for each case file described in the metadata. For instance, the ePCR application, the event log application, and / or the device association application can render a timestamp and / or a medical device identifier for each case file within its associated prompt. Each of the one or more prompts can be configured to receive input confirming that its associated case file is descriptive of operation of a medical device coupled to a patient {e.g., the patient 116 of FIG. 1) during an encounter associated with the association information. In response to receiving input confirming a case file, the ePCR application, the event log application, and / or the device association application transmits 1118 a confirmation response to the patient encounter data source integration service (e.g., via the ePCR interface andior the event log interface). The confirmation response can include an identifier of each confirmed case file. {0239] Next, the patient encounter dala source integration service receives 1120 the confirmation response and parses the confirmation response to retrieve identifiers of case files stored therein. The patient encounter data source integration service attaches and / or embeds 1122 the case files into an integrated data source encounter structure, This integrated data source encounter structure can be attached and / or embedded into ePCRs and / or event logs. The case liles can be embedded and / or attached in whole or in part. Where the case files are embedded, case data stored within the case files can be stored in fields of the ePCR andior in fields of the event log. {0240 Continuing the process 1108, the patient encounter data source integration service ransmits 1124 the ePCR, the event log, and / or the integrated data source encounter structure containing the attached / embedded case data to the ePCR application, the event log application, and‘or the device association application. The ePCR application, the event log application, and / or the device association applicadon receives 1126 the ePCR with the auached’embedded case data, the event log with the atiached‘embedded case data, and / or the integrated data source encounter structure and renders 1128 the ePCR, event log andior the integrated data source encounter siructure for review and manipulation by the healthcare provider. 10241] FIG. 12 illustrates one example of an associating process 1200 executed by a patient encounter data source integration service (e.g., the patient encounter data source integration service 1301 of FIG. 1) in some implementations. The patient encounter data source integration service can be configured to execute the process 1200 in response fo an event, such as expiration of a periodic timer and / or a request from a calling process (e.g.. the ePCR API 128 and or the event log AP 144 of FIG. 1).

[0242] As shown in FIG. 12, the process 1200 starts with the patient encounter data source integration service receiving 1202 association informaiion, This action is followed by the patient encounter data source integration service generating 1204 at least one search criterion based on the association information and searching 1206 case data stored in a case data store (2.g., the case data store 132 of FIG. 1) for multiple medical device case files that match or satisfy the at least one search criterion. In some examples, the patient encounter data source integration service can receive 1202, generate 1204, and search 1206 within the process 1200 by executing actions such as those executed by the patient encounter data source integration service to receive 502, generate S04, and search 506 within the process 500 described above with reference to FIG. 5. However, within the process 1200, the patient encounter data source iniegration service generates 1204 ai feast one search criterion that specifies a list of medical device identifiers from the association informalion, one of which must equal a medical device identifier associated with a case file for the case file to be a corresponding case file. The patient encounter data source integration service uses this search criterion to search 1206 for associating case files,

[0243] Next, the patient encounter data source integration service determines 1208 whether at least one corresponding case file was identified by the search 1206. Where the patient encounter data source integration service determines 1208 that no corresponding case files were found, the patient encounter data source integration service generates and returns 1210 an error message indicating no corresponding case file was found to the calling process, and the process 1200 ends. Where the patient encounter data source integration service determines 1208 that at least one corresponding case {ile was found, the patient encounter data source integration service generates and returns 1212 the at least one corresponding case file or at least one identifier thereof to the calling process, and the process 1200 ends. {0244] FIG. 13 illustrates one example of an associating process 1300 executed by a patent encounter data source integration service (e.g. the patient encounter data source integration service 130 of FIG. 1) in some implementations. The patient encounter data source integration service can be configured to execute the process 1300 in response to an event, such ag expiration of a periodic timer and / or a request from a calling process (e.g. the ePCR APL 128 and or the event log API 144 of FIG, 1). 10248] As shown in FIG. 13, the process 1300 starts with the patient encounter data source integration service receiving 1302 association information, This action is followed by the patient encounter dala source integration service generating 1304 at least one search criterion based on the association information and searching 1306 case data stored in a case data store (e.g, the case data store 132 of FIG. 1) for a medical device case file that matches or satisfies the at least one search criterion, In some examples, the patient encounter data source integration service can receive 1302, generate 1304, and search 1306 within the process 1300 by executing actions such as those executed by the patient encounter data source integration service 10 receive 502, generate 504, and search 506 within the process 500 described above with reference to FIG, 5. However, within the process 1300, the patieut encounter data source integration service generates 1304 at least one search criterion that specifies a list of pairs of medical device identifiers and timestamps from the association information, one of which must equate to a medical device identifier and timestamp pair associated with a case file for the case file to be a corresponding case file. The patient encounter data source integration service uses this search criterion to search 1306 for associating case files. {0246] Next, the patient encounter data source integration service determines 1308 whether one or more corresponding case files were identified by the search 1306. Where the patient encounler dafa source integration service determines 1308 that no corresponding case files were found, the patient encounter data source integration service generates and returns 1310 an error message to the calling process, and the process 1300 ends. Where the patient encounter data source integration service determines 13018 that at least one corresponding case file was found, the patient encounter data source integration service generates and returns 1312 the at least one corresponding case file or at least one identifier thereof to the calling process, and the process 1300 ends. 10247] FIG. 14 illustrates one example of an associating process 1400 executed by a patient encounter data source integration service (e.g., the patient encounter data source integration service 130 of FIG. 1} in some implementations, The patient encounter data source integration service can be configured to execute the process 14K} in response to an event, such as expiration of a periodic timer andfor a requast from a calling process (e.g, the ePCR API 128 and or the evant log API 144 of FIG. 1). {0248] As shown in FIG. 14, the process 1400 starts with the patient encounter date source integration service receiving 1402 association information. This action is followed by the patient encounter data source integration service generating 1404 at least oue search criterion based on the association information and searching 1406 case data stored in a case data store {&.g., the case data store 132 of FIG. 1) for a medical device case files that matches or satisfies the at least one search criterion, Tn some examples, the patient encounter date source integration service can receive 402, generate 1404, and search 1406 within the process 1400 by executing actions such as those execuled by the patient encounter data source integration service to receive 502, generate 504, and search S06 within the process 500 described above with reference to FIG. 5. However, within the process 1400, the patient encounter data source integration service generates 1404 at least oue search criterion that specifies a list of pairs of’ medical device identifiers and timestamps from the association information. In the at least one search criterion, the predetermined relationship requires that a corresponding case file be associated with a medical device identifier equal to a medical device identifier from the list and that the corresponding case file have a timestamp within a predetermined range of a timestamp paired with the medical device identifier from the list. The patient encounter data source integration service uses this search criterion to search 1406 for associating case files. 10249] Next, the patient encounter data source integration service determines 1408 whether one or more corresponding case files were identified by the search 1406. Where the patient encounter data source integration service determines 1408 that no corresponding case files were found, the patient encounter data source integration service generates and returns 1410 an error message to the calling process, and the process 1400 ends. Where the patient encounter data source integration service determines 1408 that at least one corresponding case file was found, the patient encounter data source integration service generates and returns 1412 the at least one corresponding case file or at least one identifier thereof to the calling process, and the process 1400 ends. {0250] FIG. 15 illustrates one example of an associating process 1500 executed by a patient encounter data source integration service (e.g. the patient encounter data source integration service 130 of FIG. 1} in some implementations. The patient encounter date source integration service can be configured 10 execute the process 1300 in response to an event, such as expiration of a peviodic timer and / or a request from a calling process (e.g. the ePCR API 128 and or the event log API 144 of FIG. 1). As shown in FIG. 15, operations rendered with dashed ling boarders may not present in some examples, {0251] As shown in FIG. 15, the process 1500 starts with the patient encounter data source Integration service receiving 1502 association information. This action is followed by the patient encounter dala source integration service generating 1504 at least one search criterion based on the association information and filtering 1506 case data stored in a case data stove (e.g. the case data store 132 of FIG. 1) for medical device case {iles that match or satisfy the at least one search criterion. In some examples, the patient encounter data source integration service can receive 1502, generate 1504, and Blter 1506 within the process 1500 by executing actions such as those executed by the patient encounter data source integration service to receive S02, generate 504, and search 506 within the process 500 described above with reference to FIG. 5. However, within the process 1500, the patient encounter dala source integration service searches 1506 the case data for the case file by filtering (2.g., via a query) the case data store using an initial search criterion and, in so doing, identifies a plurality of candidate case files. In some examples, the initial search criterion employed by the filter specifies that an element of association information (e.¢., a timestamp) must fall within a range of a parameter associated with a case file. {0252] Next, the patient encounter dafa source integration service generates 1508 at least one supplemental search criterion. In some examples, the at least one supplemental search criterion specifies at least one supplemental predetermined relationship between at least one supplemental element of association information and at least one supplemental parameter associated with candidate case fles. For example, where the at least one supplemental relationship is hardcoded, the patient encounter data source integration service generates 1308 the at feast one supplemental search criterion by identifying at least one supplemental element from the association information and associating the at least one supplemental element with the at least one supplemental relationship, Alternatively or additionally, where the at least one supplemental relationship is softcoded, the patient encounter data source integration service generates 1508 the at Jeast one supplemental search criterion by first identifying the next preferred predetermined relationship by rank within a criteria data store (e.g., the criteria data store 136 of FIG. 1) and next identifying the at least one supplemental element of association information as specified in the next preferred pradetermined relationship and associating the at least one supplemental element with the at least one supplemental relationship. In at least one example, the at least one supplemental element includes a geotag and the predetermined relationship specifies that corresponding case files be associated with a geotag within a predetermined range of the geotag from the association information. {0283] Continuing the process 1300, the patent encounter data source integration service searches 1310) the candidate case data for a medical device case files that match or satisfy the at feast one supplemental search criterion. In some examples, the patient encounter data source integration service can search 1510 within the process 1500 by executing actions such as those executed by the patient encounter data source integration service to search 506 within the process 500 described above with reference to FIG. 5. However, within the process 1500, the patient encounter data source integration service can restrict its search 1510 to case data from the candidate case files. For instance, the patient encounter data source integration service can identify a candidate case file as a corresponding case file where a supplemental parameter associated with the candidate case file, stored in the case data, satisfies the supplemental relationship with the supplemental element of the association information stored in the at least one supplemental search criterion, 10254] Next, the patient encounter data source integration service determines 1512 whether at least one corresponding case file was found. Where the patient encounter data sowce integration service determines 1512 that at least one corresponding case file was found, the patient encounter data source integration service generates and returns 1514 the corresponding case files or identifiers thereof to the calling process, and the process 1500 ends. Where the patient encounter data source integration service determines 1512 that no corresponding case files were found. the patient encounter dala source integration service iterates a counter and determines 1516 whether the counter has transgressed a configurable constraint 1 the number of search iterations acceptable in a single instance of the process 1500. Where the patent encounter dala source integration service determines 1516 that the counter bas not transgressed the constraint, the patient encounter data source integration service generates 1508 another supplemental search criterion and the process 1300 continues. Where the patient encounter daia source integration service determines 1516 that the counter has transgressed the constraint, the patient encounter data source integration service returns 1518 an error message to the calling process, and the process 1500 ends. {0255] FIG. 16 illustrates one example of an associating process 1600 executed by a patient encounter data source integration service (e.g., the patient encounter data source integration service 130 of FIG. 1) in some implementations. The patient encounter data source integration service can be configured to execate the process 1600 in response to an event, such as expiration of a periodic timer and / or 8 request from a calling process (e.g.. the ePCR interface 168 and or the event fog APT 144 of FIG. 1). As shown in FIG. {6, operations rendered with dashed line boarders may not present in some examples. 10256] As shown in FIG. 16, the process 1600 stars with the patient encounter data source integration service receiving 1602 association information. This action is followed by the patient encounter dala source integration service generating 1604 at least one search criterion based on the association information and filtering 1606 {e.g., via a query) case daia stored in a case data store (e.g. the case data store 132 of FIG. 1) using the at least one search criterion to identify a plurality of candidate case files. In some examples, the patient encounter data source integration service can receive 1002, generate 1604, and filter 1606 within the process 1600 by executing actions such as those executed by the patient encounter data source integration service to receive 1502, generate 1504, and filter 1506 within the process 1500 described above with reference to FIG. 15. However, within the process 1604, the initial search criterion employed by the filter includes an initial predetermined relationship that specifies an equality between an element of association information and a parameter associated with medical device case files that is non-medical. These non-medical elements and parameters can include case star time, medical device identifier, and / or patient identifiers.

[0287] Next, the patient encounter data source integration service generates 1608 at least one supplemental search criterion. In this example, the at least one supplemental search criterion specifies that al least one medical element in the association information be medically consistent with and indicative of at least one medical parameter in a case file. In these examples, the at least one medical element can include a patient complaint, a medic impression, a drug administration, a vital sign, a physiological measurement, a treatment provided to the patient, a symptom of chest pain, an ECG with ST elevation, and / or a STEMI diagnosis. Further, in these examples, the at least one medical parameter can include a type of physiological measurement, a value of a physiological measurement, a medical treatment (eg. a defibrillation shock), and an alarm. 0258] Continuing the process 1600, the patient encounter data source integration service searches 1610 the candidate case data, determines 1612 whether at least one corresponding case file was found, and returns 1614 the corresponding case files or identifiers thereof to the calling process where a corresponding case file was Found. Where a corresponding case file was not found, the patient encounter data source integration service determines 1616 whether a search limit has been exceeded, returns 161¥ an error message indicating no corresponding case file to the calling process where the search limit has been exceeded, and returns to generate 1608 ai least one supplemental search criterion where the search limit has not been exceeded. In some examples, the patient encounter data source integration sevvice can search 1610, determine 1612, return 1614. determine 1616, and return 1618 within the process 1600 by executing actions such as those executed by the patient encounter data source integration service to search 1310, determine 1512, return 1514, determine 1516, and return {318 within the process 1500 described above with reference to FIG. 15. {0259] As explained above, in the process 1600 generales 1608 at leasi one supplemental search criterion that specifies at least one medical element in association information be medically consistent with and indicative of at least one medical parameter in a case file. In this example, the at least one predetermined relationship specifies that the association information be “medically consistent with an indicative of” case data. This predetermined relationship is complex and difficult to evaluate using commonly available comparison operations. As such, in this example, the patient encounter data source integration service evaluates the predetermined relationship while searching 1610 by executing one or more specialized heuristic, statistical, and / or machine learning processes that compare association information and case data. Table 1 provides association information and case data that satisfy the “medically consistent with and indicative of” predetermined relationship according to some examples. {0260] MEDICAL DATA ! A n wo ™ 1 A B C D TRIE ra 1 Si Ta i Primary Secondary Primary Secondary Case | Element of Association | Element of Association | Case Data Data Information Information Patient complaint of | Drug Administration 12 Lead ECG Shock t Chest Pain (aspirin andior administration nitroglycerin} Patient complaint of | Drug Administration Pulse Oximetry 12 Lead ECG ! difficulty breathing (albuterol, steroids, Capunography Alarms (heart rate, | and / or epinephrine) respiratory rate, i Medic Impression of | Airway Placement pulse oximetry, Respiratory Distress | blood pressure) {0261] More specifically, as shown in Table 1 cohamns A and B list primary and secondary elements of association information that are medically consistent with and indicative of the primary and secondary medical device case data listed on columns C and D. In some examples, the patient encounter data source integration service can generate 1608 supplemental search criteria specifying thai any corresponding case data found while searching 1510 must be medically consistent with and indicative of the primary and secondary elements of association information, Alternatively, in some examples, the patient encounter data source integration service can generate 1608 a first supplemental search ceiterion specifying that any corresponding case data found while searching 1610 must be medically consistent with and indicative of the primary element of association information. Where no corresponding case data is found to the first supplemental search criterion during searching 1610, the patient encounter data source integration service can generate 160% a second supplemental search criterion specifying that any corresponding case data found while searching must be medically consistent with and indicative of the secondary element of association information. 10262] In some examples, the systen 100 is configured to execute a variety of medical device case file sharing processes. FIG. 17, for instance, illustrates a sharing process 1700 that involves a mobile computing device (e.g., the mobile computing device 104A of FIG. 1), a compuling device (e.g. the mobile computing device 104B of FIG. 1), and a patient encounter data source integration service. 10263] The sharing process 1700 starts with the mobile computing device authenticating 1702 a healthcare provider (e.g., the healthcare provider 118A of FIG. |) as an authorized user. The mobile computing device receives 1704 input from the user requesting that the mobile computing device share consolidated case data from a patient encounter with the computing device. For instance, an event Jog application and / or an ePCR application (e.g.. the event log application 140 and / or the ePCR application 122 of FIG. 1) can receive the Input. In response 10 reception of the input, the mobile computing device transmits 1724 a token identifying the patient encounter to the computing device. For instance, the mobile computing device may display a visual representation of the token vin a user interface and / or may transmit data representing the token via NFC. 10264] Continuing the sharing process 1700, the computing device receives 1706 the token {e.g., by scanning the visual image with a camera) and transmits 1708 a request for consolidated case data for the patient encounter identified by the token to the patient encounter data source integration service. For instance, an encounter review application {e.g., the encounter review application 148 of FIG. 1) can transmit the request. {0265] As another part of the sharing process 1700, the patient encounter data source integration service, as part of a previously executed consolidation process (e.g. the consolidation process 400 of FIG. 4), stores 1710 the consolidated case date for the patient encounter identified by the token, in association with the token. The patient encounter data source integration service receives 1712 the request for the consolidated case data from the computing device. The patient encounter data source integration service identifies 1714 the consolidated case data using the token, retrieves 1 716 the consolidated case data, and transmits 1718 the consolidated case data to the computing device. {0266] Continuing the sharing process 1700, the computing device receives 1720 the consolidated case data and renders the consolidated case data automatically in response to receipt of the consolidated case data. For instance, the encounter review application can render an event log including the consolidated data. 10267] Referring to FIG. 18, a block diagram of examples of computing and medical device components are shown schematically. 10268] The medical device 102 can inclade a processor 220, a memory 221, one or more output devices 230, one or more user input devices 244, and a commumications 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. 10269] In various implementations, the medical device 102 can be 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, ar 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 device 102 can be an integrated therapy delivery / moniloring device within a single housing 280. The single housing 280 can surround, at least in part, a patent interface device signal processor 236 and / or a therapy delivery control module 233. {0270 The patient interface device(s) 190 can include one or more therapy delivery componeni(s) 261a andor one or more sensor device(s) 261b. The medical device 102 can be configured to couple 10 the one or more therapy delivery component(s) 261a. In combination, the medical device 102 and the one or more therapy delivery components can provide therapeutic treatment fo a patient (2.2., the patient 116 of FIG. 1). In an implementation, the medical device 102 can include or incorporate the therapy delivery components) 261a. The therapy delivery component(s) 26 1a 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 (2.g., one of more belts or a piston), ventilation devices {e.2., a mask and / or tubes), drug delivery devices, etc. The medical device 102 can include the one or more therapy delivery compenent(s) 26 1a 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 healthcare provider (e.g, the healthcare provider 118) may aftach the electrodes to the patient, and the medical device 102 (e.g, a defibrillator or defibrillator / patient monitor) may provide electrotherapy to the patient via the defibrillation elecirodes. 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. 10271] The medical device 102 can be, 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 stinwulation) and the medical device 102 can be 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 first medical device 102 can be a mechanical chest compression device such as a belt-based 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 (ECMQ)), etc. and the medical device 102 can be a device configured to provide a respective therapy. In an implementation, the medical device 102 can be a combination of one or more of these examples. The therapeutic medical device can include patient monitoring capabilities via one or more sensors, These types of medical therapy and devices are examples anly and not limiting of the disclosure. 0272] The medical device 102 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 Lo provide signals indicative of sensor data to the medical device 102. The sensor(s) 261b can be configured to couple to the patient. For example, the sensox(s) 261b can nclade 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 sataration (Sp02), 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, pueuwmography, and / or cardiography, eic. Additionally or alternatively, the one or more sensors 261b can generaie signals indicative of chest compression parameters, ventilation parameters, drug delivery parameters, fluid delivery parameters, etc. {0273] In addition (o delivering therapy to the patient, the therapy delivery componeni(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 102. 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, electrocardiogram {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 (TV) 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 10 sense the patient's temperature, As a further example, an IV device can provide therapy via drug delivery andéor fluid management. The TV device can also monitor andior enabling monitoring of a patient via blood sampling and / or venous pressure monitoring (e.g. central venous pressure {CVP) monitoring). {0274] The medical device 102 can be configured to receive the sensor signals (e.g., from the therapy delivery compouent(s) 261a andior the sensor(s) 201b) and to process the sensor signals to determine and collect the patient data. The patient data can include patient data which can characierize a status and / or condition of the patient (e.g. physiological data such as ECG, heart rate, respiration rate, temperature, pulse oximeiry, non-invasive hemoglobin parameters, capnography, oxygen saturation (Sp02), end tidal carbon dioxide (FiCO2}, invasive blood pressure (IBP), non-invasive blood pressures (NIBP), tssue pH, tissue oxygenation, Near Infrared Spectroscopy (NIRS) measurements, etc.). Additionally or alternatively. the patient data can characterize the delivery of therapy (2.g., chest compression data such as compression depth, compression rate, ete.) 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). 10275] The components of 220, 221, 230, 244, 245, and 255 of the medical device 102 are communicatively coupled (directly and / or indirectly) to each other for bi-directional communication. {0276] Although shown as separate entities in FIG. 18, the one or more of the components of the medical device 102 can be combined into one or more discrete components and / or can be part of the processor 220. The processor 220 and the memory 221 can include aud / or be coupled to associated circuitry to perform the functions described herein, 10277] In an implementation, the medical device 102 can be a therapeutic medical device configured to deliver medical therapy to the patient. Thus, the medical device 102 can optionally include the therapy delivery control module 283. 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, veutilation, and / or other type of therapy delivery. Alternatively, some examples of the medical device 102 may noi be configured to deliver medical therapy to the patient 116 but can be configured to provide patient monitoring and / or diagnostic care. As shown in FIG. 18, in some examples, the therapy delivery control module 255 exchanges messages with the mobile computing device 104 (e.g, the patient mobile computing device) via a communication link 1180. These messages can include padent data descriptive of therapy provided to the patient or ather patient data stored on the medical device 102. This patient data can be used by an ePCR application in generating an ePCR documenting a dispatched EMS event. In one embodiment communication link 1180 is implemented using BLUETOOTH andior near-field communications technology. {0278] In certain implementations the file maiching and merging functionalities described herein as being associated with the patient encounter data source integration service 130 are alternatively invoked at the medical device 102 and / or the mobile computing device 104. In such implementations the conununication link 1180 between the medical device 102 and the mobile computing device 104 can be used to support this functionality. thus allowing a medical device case file to be integrated with related charting data even when a connection to the server 108 is unavailable. In applications where the communication link 1180 is limited, for example due to limited bandwidth or limited duration, file matching and merging functionality is optionally limited to one or more specified search criteria, such as a search criterion that compares device identifiers. This may be particularly useful in applications where it is desired to throitle bandwidth provided by the communication tink 1180 to reserve limited resources for patient treatment and EMS interactions. {0279] The information shared via the communication link 1180 is optionally limited to increase security and / or to protect PHI. This can be accomplished by, for example, configuring the medical device 102 and the mobile computing device 104 to only communicate public information (for example, a device identifier) using the communication link 1180. In implementations where PHI is to be shared between the medical device 102 and the mobile computing device 104, the communications can be routed via a trusted cloud service where stronger authentication can be implemented. In certain embodiments the server(s) 108 provides such a trusted cloud service. Routing communications via the server(s) 108 may be preferred for other reasons as well, such as where the medical device 102 and the mobile computing device 104 produce daia in different formats, and / or where one or more of the communicating devices are not configured to communicate in a local network. {0280] The medical device 102 can incorporate and / or be configured to couple 10 one or more patient interface device(s) 190. The patient interface device(s) 190 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) 26 1a and the one or more sensor(s) 261b sensor can provide one or more signals to the medical device 102 via wired and / or wireless connection {s}. {0281] The ong 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. belt, a cuirass, etc), ete. 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 corabinations thereof. Tn various implementation, the therapy delivery componeni(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, ete. Farther the electrotherapy electrodes can include and or be coupled to a chest compression sensor. As anoiher example, the ventilation devices can be coupled to and / or incorporate flow sensors, gas species sensors {e.g., oxygen sensor, carbon dioxide sensor, ete), ete. As a further example, the intravenous devices can be coupled to and / or incorporate temperature sensors, flow sensors, blood pressure sensors, ste. 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. {0282) In various implementations, the sensor(s) 261b can include one or more sensor devices configured fo provide sensor data that includes, for example, but not limited to electrocardiogram (ECG), blood pressure, heart rate, pulse oxygen level, respiration rate, heart sounds, lung sounds, respiration sounds, tidal CO2, saturation of muscle oxygen (SMO2), atlevial oxygen saturation (Sp02), cerebral blood flow, electroencephalogram (EEG) signals, brain oxygen level, tissue pH, issue fluid levels, images andior videos via ultrasound, Jaryngoscopy., andior other medical imaging techniques, near-infrared reflectance spectroscopy, pneumography, cardiography, and / or patient movement. Images andior videos can be two-dimensional or three-dimensional. {0283] 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.i.. the chest compression sensor 268), ete. 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 patent's ECG information. In an implementation, the sensing electrodes can be configured to measure the transthoracic impedance andfor a heart rate of the patient. The ventilation sensors can include spirometry sensors, [low sensors, pressure sensors, oxygen andor 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 Hauid crysial thermometer, & thetmocouple, a thermistor, ele. and can measure patient temperatare internally and / or externally. The chest compression sensor can include one or nore motion sensors including, for example, one or more accelerometers, one or more force Sensors, one oF more magnetic sensors, one or more velocity sensors, one or more displacement sensors, ele. The chest compression sensor can be, for example, but not limited fo, a compression puck, a smart phone, a hand-held device, a weamble 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 sysiem, a piston system, #ic.). 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 {0284] Continuing with FIG. 18, examples of components of the mobile computing device 104 are shown schematically. In an implementation, the mobile computing device 104 can be configured as a mobile computing device. The mobile computing device 104 can inclade a processor $20, a memory 421, one or more output devices 430, one or more user input devices 444, and a communications interface 445, FIG. 18 also illasirates schematically examples of components of the remote computing device 106. As shown in FIG. 18, remote the computing device 106 can include a processor 320, a memory 321, one or more output devices 330, one or more user inpul devices 344, and a communications interface 343, FIG. 18 further illustrates schematically examples of components of the server(s) 108. As shown in FIG. 18, the server(s) 108 can include a processor 520, a memory 521, one or more output devices $30, one or more user input devices 544, and a communications interface 543, 0288] Each of the mobile computing device 104 (e.2., the mobile computing device) and the remote computing device 106 can be a computer system, such as a desktop, notebook, mobile, portable, or other type of computing system. Each of these devices 104 and 106 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) 108 can be another type of computing system including for example a desktop, notebook, mobile, portable, or other type of computing system. {0286] As shown in FIG. 18, each of the devices 104 and 106, along with the server(s) 108 and the medical device 102, includes a bus or other interconnection mechanism that commmunicably 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. 0287] The processors 220, 320, 420, and 520 can each include a processor, such as, but not limited to, an Intel® Tanium® or Itanium 28 processor(s), or AMD® Opteron: or Athlon MP® processor(s), or Motorola ® fines of processors. The communication interfaces 248, 345, 445, and 545 can each be any of an R$-232 port for ase with a modem-based dislup 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 {0 which the medical device 102, the mobile computing device 104, the remote computing device 106, and / or the server(s) 108 may connect. The ruemovies 221, 321, 421, and 521 can be Random Access Memory (RAM), Read Only Memory (ROM), Flash memory, and / or another dynamic volatile and / or nou-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 Adapiec 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, {0288) Continuing with FIG. 18, the server(s) 108 can include, for example, the one or more storage server(s) and one or mote application server(s). In some examples, the server(s) 108 are configured to exchange messages 1170 with the remote computing device 106. These messages can include charting and / or case data as described above. In some examples, the server(s) 108 are configured to exchange messages 1160 with the mobile computing device 104 via the ePCR API 128. These messages can include data descriptive of ePCRs generated by the mobile computing device 104. In some examples, the server(s) 108 are configured to exchange messages 1190 with the medical device 102. These messages can include data descriptive of a patient {e.g.. the patient 116 of FIG. 1) being weated via by the medical device and‘or treatment being deliversd by the medical device 102. 10289] Some examples of the present disclosure include various sieps. some of which can be performed by hardware components or can be embodied in machine-executable instructions. These machine-xecutable instructions can be stored on a non-transitory data storage medium and can be used fo cause a general-purpose of a special-purpose processor programmed with the instructions to perform the steps. The non-transitory data storage medium can further to 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 122. 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, sndior 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.. vue or mors modules), on one or more computer sysiems, 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 {0290] Having thus described several aspects of at least one exaraple, 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 ave 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

CLAIMS 1. A system for consolidating medical data from multiple devices involved in an encounter between a patient and an emergency healthcare provider, the system comprising: a plurality of medical devices each having one or more identifiers and being configured to: obtain case data related to the encounter between the patient and the emergency healthcare provider, and transmit the obiained case data to a server as one or more medical device case files; a mobile computing device having a medical device interface and a user interface, the mobile computing device configured to: acquire, vig the medical device interface, one or more representations of the one or more identifiers of each medical device of the plurality of medical devices, generate association information comprising the one or move identifiers, and transmit the association information to the server: and the server conprising at least one processor and memory to execute instructions for associating the one or more medical device case files, the server configured to be communicatively coupled with the plurality of medical devices and the mobile computing device, the server further configured to: receive and store the one or more medical device case files from the plurality of medical devices, receive the association information from the mobile computing device, generate at least one search criterion based at least in part on the association information {o relate the one or more medical device case files to one another, identify the related one or more medical device case files based on the generated at least one search criterion, consolidate the one or more medical device case files fo produce an integrated data source encounter structure comprising case data from the related one or more medical device case files, and transmit the integrated data source encounter structure for review of the encounter between the patient and the emergency healthcare provider to a receiving computing device.

2. The system of claim 1, wherein the receiving computing device comprises the mobile computing device, 3. The sysiem of claim 2, wherein the mobile computing device is further configured io render al least a portion of the integrated data source encounter structure via the user interface.

4. The system of claim 1, wherein the integrated data source encounter structure comprises information other than patient information.

5. The system of claim 1, wherein the receiving computing device comprises at least one medical device of the plurality of medical devices.

6. The system of claim 1, wherein the receiving computing device comprises a computing device within an emergency response center.

7. The system of claim 6, wherein the association information comprises a token to access the integrated data source encounter structure and the server is further configured (o receive the token from the computing device within the emergency response center, wherein to transmit comprises to automatically transmit the integrated data source encounter structure to the computing device in response to reception of the token.

8. The system of claim 7, wherein the mobile computing device is configured to transmit the token to the computing device within the emergency response center, 9. The system of claim 1, wherein to transmit the one or more medical device case files comprises to transmit one or more streams of the obtained case data to the one or more medical device case files.

10. The system of claim 9, wherein the integrated data source encounter structure comprises the one or more streams of the obtained case data from the one or move medical device case files.

11. The system of claim 1, further comprising a computing device comprising at least one user interface and configured to: receive the integrated data source encounter structure; and render, subsequent to the encounter, at least a portion of the integrated data source encounier siructure via the at least one user interface.

12. The system of claim 1, wherein the plurality of medical devices comprises one or more of: a defibrillator, a patient monitor, an automated external defibrillator, a ventilator, an automated chest compression device, and a wearable defibrillator.

13. The system of claim 1, wherein the association information comprises patient information.

14. The system of claim 13, wherein the patient information comprises one or more of patient nae, patient identifier, age, gender, weight, height, and past medical history.

15. The system of claim 1, wherein the association information comprises timestamp information indicating when at least a portion of the one or more medical device case files was created.

16. The system of claim 1, wherein the association information comprises timestamp information indicating when the one or more representations of the one or more identifiers of each medical device were acquired.

17. The system of claim 16, wherein the association information comprises geolocation information indicating where the mobile computing device was located when the one or more representations of the one or more identifiers of each medical device were acquired.

18. The system of claim 1, wherein the association information comprises geolocation information indicating where the mobile computing device was located when the one or more representations of the one or mote identifiers of each medical device were acquired.

19. The sysiem of claim 1, wherein the association information comprises geolocation information indicating where the mobile computing device was located during the encounter. 21, The system of claim 1, wherein the medical device interface comprises at least one of: a camera, a near-field communication sensor, a radio frequency identification sensor, a universal serial bus connector, an infrared sensor, a personal area network sensor, a proximity detector, a geolocation detector, and a wireless neiwork connector.

21. The system of claim 1, wherein the medical device interface comprises a camera, and the one or more identifiers comprise one or more of a quick response code, a bar code, and a device identifier.

22. The system of claim 1, wherein the one or more identifiers of each medical device correspond to ong or more unique device identifiers.

23. The system of claim 1, wherein the mobile computing device is further configured 10 generate one or more log entrizs of the encounter.

24. The system of claim 23, wherein the mobile computing device is configured to ransmit the one or more log entries to the server for inclusion in the integrated data source encounter structure.

25. The system of claim i, wherein the server is remote from the mobile conputing device.

26. The system of claim {, wherein the obtained case data comprises physiological data comprising one or more oft BCG data, oxygen saturation data, capnographic data, and blood pressure data.

27. The system of claim 1, wherein the oblained case daia comprises treatment daia comprising ane or more of: defibrillation data, drug infusion data, chest compression data, and ventilation data.

28. The system of claim 1, wherein the obtained case data comprises performance data comprising one or more of; chest compression performance data and ventilation performance data.

29. The system of claim 1, wherein the obtained case data comprises protected health information.

30. An associating server for consolidating medical data from an encounter between a patient and an emergency healthcare provider, the server comprising: amemory storing at least one database configured to store case data from a plurality of medical device case files recorded during the encounter between the patient and the emergency healthcare provider; a network interface: and at least one processor communicatively coupled with the memory and the network interface, the at least one processor configured 10; receive, via the network interface, the plurality of medical device case files from a plurality of medical devices used to teat the patient during the encounter, store the case data from the plurality of medical device case files in the at least one database, receive, via the network interface, association information from 8 mobile computing device, the association information comprising at least one identifier of each medical device of the plurality of medical devices, generate at least one search criterion based al least in part on the association information to relate the plurality of medical device case files io one another, identify the related plurality of medical device case files based on the generated at least one search criterion, consolidate the related plurality of medical device case files to produce an integrated data source encounter structure comprising at least a portion of the case data from the plurality of medical device case files from the at least one database, and transtuil the integrated data source encounter structure for review of the encounter between the patient and the emergency healthcare provider to a receiving conputing device.

31. The associating server of claim 30, wherein to transmit the integrated data source encounter structure comprises to transmit the integrated data source encounter structure to the mobile computing device, 32. The associating server of claim 30, wherein the integrated data source encounter structure comprises information other than patient information.

33. The associating server of claim 30, wherein to transmit the integrated data source encounigr structure comprises to transmit the integrated data source encounter structure 10 af Teast one medical device of the plurality of medical devices.

34. The associating server of claim 30, wherein to transmit the integrated data source £UCOUNIEr Structure comprises 10 transit the integrated data source encounter structure (0 a computing device within an emergency response center.

35. The associating server of claim 34, wherein the association information comprises a token to access the integrated data source encounter structure and the at least one processor is farther configured to receive the token from the computing device within the emergency response center, wherein to transmit comprises 10 automatically transmit the integrated data source encounter structure to the computing device in response to reception of the token.

36. The associating server of claim 30, wherein to receive the plurality of medical device case files comprises to receive a plurality of streams of case data from the plurality of medical devices.

37. The associating server of claim 36, wherein the integrated data source encounter structure comprises the plurality of streams of case data from the plurality of medical devices.

38. The associating server of claim 30, wherein the association information comprises patient information.

39. The associating server of claim 38, wherein the patient information comprises one or more of: patient name, patient identifier, age, gender, weight, height, and past medical history, 40. The associating server of claim 30, wherein the association information comprises timestamp information indicating when at least a portion of the plurality of medical device case files was recorded.

41. The associating server of claim 30), wherein the association information comprises timestamp information indicating when one or more representations of the at least one identifier of each medical device were acquired.

42. The associating server of claim 41, wherein the association information comprises geolocation information indicating where the mobile computing device was focated when the one or more representations of the at least one identifier of each medical device were acquired.

43. The associating server of claim 30, wherein the association information comprises geolocation information indicating where the mobile computing device was located when one or more representations of the at least one identifier of each medical device were acquired.

44. The associating server of claim 30, wherein the association information comprises geolocation information indicating where the mobile computing device was located during the encounter. 45, The associating server of claim 30, wherein the one or more identifiers of each medical device correspond to one or more unique device identifiers.

46. The associating server of claim 30, wherein the server is remote from the mobile computing device.

47. The associating server of claim 30, wherein the case data comprises physiological data. comprising one or more of: ECG data, oxyzen saturation data, capnographic data, and blood pressure data, 48. The associating server of claim 30, wherein the case data comprises treatment data comprising one or more of: defibrillation data, drug infusion data, chest compression data, and ventilation data.

49. The associating server of claim 30, wherein the case data comprises performance data comprising one or more of: chest compression performance data and ventilation performance data.

561. The associating server of claim 30, wherein the case data comprises protected health information.

51. A mobile computing device for consolidating case data from an encounter between a patient and an emergency healthcare provider, the mobile computing device comprising: amemory, a user interface configured to receive user input concerning the encounter; a medical device interface configured to acquire a represeniation of an identifier of a medical device; a network interface: and at feast one processor communicatively coupled with the user interface, the madical device interface, the network interface, and the memory, the at least one processor being configured to: receive, via the user interface, input to acquire a plurality of representations of a plurality of identifiers of a plurality of medical devices involved in the encounter. store the acquired plurality of representations of the pharality of identifiers in the memory, generate association information comprising the plurality of identifiers, and transmit the association information to a server for associating and consolidating the case data fron: at least one medical device case file genersted by the plurality of medical devices during the encounter, 52. The mobile computing device of claim 531, wherein the at least one processor is further configured to; receive, via the network interface, an integrated data source encounter structure comprising at least a portion of the case data from the at least one medical device case file: and render, via the user interface, at least a portion of the integrated data source encounter struciure.

53. The mobile computing device of claim 32, wherein the integrated data source encounter structure comprises information other than patient information.

34. The mobile computing device of claim 52, wherein the portion of the case data comprises physiological data comprising one or more oft ECG data, oxygen saturation data, capnographic data, and blood pressure data.

55. The mobile computing device of claim §2, wherein the portion of the case data comprises treatment data comprising one or more of: defibrillation dats, drug infusion data, chest compression data, and ventilation data, 56. The mobile computing device of claim 52, wherein the portion of the case data comprises performance data comprising one or more of: chest compression performance data and ventilation performance data.

57. The mobile computing device of claim 52, wherein the portion of the case data comprises protected health information.

58. The mobile computing device of claim 51, wherein the association information comprises patient information, 59. The mobile computing device of claim 58, wherein the patient information comprises one or more of: patient name, patient identifier, age, gender, weight, height, and past medical history, i}. The mobile computing device of claim 51, wherein the association information comprises timestamp information indicating when at least a portion of the at least one medical device case file was generated.

61. The mobile computing device of claim 51, wherein the association information comprises timestarnp information indicating when the phaality of representations of the plurality of identifiers of the plurality of medical devices were acquired.

62. The mobile computing device of claim 61, wherein the association information comprises geolocation information indicating where the mobile computing device was located when the plurality of representations of the plurality of identifiers of the plurality of medical devices were acquired.

63. The mobile computing device of claim 51, wherein the association information comprises geolocation information indicating where the mobile computing device was located when the plurality of representations of the plurality of identifiers of the plurality of medical devices were acquired. G4. The mobile computing device of claim $1, wherein the association information comprises geolocation information indicating where the mobile computing device was located during the encounter.

65. The mobile computing device of claim S1, wherein the association information comprises a token to access an integrated data source encounter structure comprising at least a portion of the case data from the at least one medical device case {ile and the at least one processor is configured to transinit the token to a computing device within an emergency response center.

66. The mobile computing device of claim 51, wherein the medical device interface comprises at least one off a camery, a near-field communication sensor, a mdio frequency identification sensor, a universal serial bus connector, an infrared sensor, a personal area network sensor, a proximity delector, a geolocation defector, and a wireless network comector.

67. The mobile computing device of claim 51, wherein the medical device interface comprises a camera, and the plurality of identifiers comprises one or more of: a quick response code, a bar code, and a device identifier.

68. The mobile computing device of claim 51, wherein the plurality of identifiers of the plurality of medical devices correspond to one or more unique device identifiers.

69. The mobile computing device of claim 5}, wherein the at least one processor is further configured to generate one or more log entries of the encounter.

70. The mobile computing device of claim 69, wherein the at least one processor is configured fo transmit the one or more log entries to the secver for inclusion in an integrated data source encounier structure comprising at least a portion of the case data from the at least one medical device case file, 71. The mobile computing device of claim 31, wherein the mobile computing device is remote from the server.

72. A computer implemented process for consolidating case data from an encounter between a patient and an emergency healthcare provider, the computer implemented process comprising: receiving, via a user interface, inpal to acquire a plurality of representations of a plarality of identifiers of a plurality of medical devices involved in the encounter, storing the acquired plurality of representations of the plurality of identifiers in a memory of the computer, generating association information comprising the plurality of identifiers, and transiting, via a network interface of the computer, the association information to a server for associating and consolidating the case data from at least one medical device case file generated by the plurality of medical devices during the encounter.

73. The computer implemented process of claim 72, further comprising: receiving, vin the network interface, an integrated data source encounter stnictare comprising at least a portion of the case data from the at least one medical device case file; and rendering. via the user interface, at least a portion of the integrated data source encounter structure. 74, The computer implemented process of claim 73, wherein receiving the integrated data source encounter strucure comprises receiving information other than patient information.

75. The computer implemented process of claim 73, wherein rendering the at least a portion of the case data comprises rendering physiological data comprising one or more oft ECG data, oxygen saturation data, capnographic data, and blood pressure data, 76. The computer implemented process of claim 73, wherein rendering the at least a portion of the case data comprises rendering treatment data comprising one or more of: defibrillation data, drag infusion data, chest compression data, and ventilation data.

77. The computer implemented process of claim 73, wherein rendering the at least a portion of the case data comprises rendering performance data comprising one or more of: chest compression performance data and ventilation performance data.

78. The computer implemented process of claim 73, wherein rendering the at least a portion of the case data comprises rendering protected health information, 79. The compaier implemented process of claim 72, wherein transmitting the association information comprises transmitting patient information, &0. The computer implemented process of claim 79, wherein transmitting the patient information comprises transmitting one or more of patient name, patient identifier, age, gender, weight, height, and past medical history.

81. The computer implemented process of claim 72, wherein fransmitting the association information comprises transmitting imestamp information indicating when at least a portion of the at least one medical device case file was generated.

82. The computer implemented process of claim 72, wherein transonitting the association information comprises transmitting timestamp information indicating wheu the plurality of representations of the plurality of identifiers of the plurality of medical devices were acquired. 83, The computer implemented process of claim 82, wherein transmitting the association information comprises transmitting geolocation information indicating where the mobile computing device was located when the plarality of representations of the plurality of identifiers of the plurality of medical devices were acquired.

84. The computer implemented process of claim 72, wherein fransmitting the association information comprises transmitting geolocation information indicating where ihe mobile computing device was located when the plurality of representations of the plurality of identifiers of the plurality of medical devices were acquired. RS. The computer implemented process of claim 72. wherein transmifting the association information comprises transmitting geolocation information indicating where the mobile computing device was located dering the encounter.

86. The computer implemented process of claim 72, wherein transaitting the association information comprises transanitting a token 10 access an integrated data source encounter structure comprising at least a portion of the case data from the at least one medical device case file and the computer implemented process further comprises transmitting, via the network interface, the token fo a computing device within an emergency response center.

87. The computer implemented process of claim 72, wherein receiving input to acquire the plurality of representations comprises receiving input via at least one of: a camera, a near- field communication sensor, a radio frequency identification sensor, a universal serial bus connector, an infrared sensor, a personal area network sensor, a proximity detector, a geolocation detector, and a wireless network connector.

88. The computer implemented process of claim 72, wherein receiving input 10 acquire the plurality of representations comprises receiving input via a camera, and the plurality of identifiers comprises one or more oft a quick response code, a bar code, and a device identifier.

89. The computer implemented process of claim 72, wherein receiving input to acquire the plurality of representations of the plurality of identifiers comprises receiving input to acquire a plurality of representations of a plurality of unique medical device identifiers.

90. The computer iraplemented process of claim 72, farther comprising generating one or more log entries of the encounter, 91. The coraputer implemented process of claim 90, further comprising transmitting the one or more log eniries to the server for inclusion in an integrated data sousce encounter structure comprising ai least a portion of the case data from the at least one medical device case file.

92. A non-teansitory computer-readable storage medium stoging instructions configured to execute the compuler implemented process of any of claims 72 through 91. 93, A mobile computing device comprising the non-transitory computer-readable storage medium of claim 92, wherein the mobile computing device is remote from the server. 94, The system of claim 26, wherein the ECG data comprises a 12-lead ECG data report.

95. The system of claim 94, wherein the 12-lead ECG data report comprises electrical waveforms and an interpretation of one or more of the electrical waveforms, 96. The system of claim 1, wherein the plurality of medical devices are configured 10 automatically transmit the obtained case data to the server as one or more medical device case files without receiving a request from the server for the case data.

97. The associating server of claim 47, wherein the ECG data comprises a 12-lead ECG data report, 98. The associating server of claim 97, wherein the 12-lead ECG data report comprises electrical waveforms and an interpretation of one or more of the electrical waveforms.

99. The associating server of claim 30, wherein the at least one processor is configured io automatically receive the plurality of medical device case files from the plurality of medical devices without sending a request for the plurality of medical device case files, 1080. A system for ransmitting medical data reports, the system comprising: a medical device configured to: obtain medical data from a patient, generate a medical report based at least ob a portion of the obiained medical data, and transmit the medical report to a local computing device, the local computing device being configured to automatically receive the medical report without sending a request to the medical device for the medical report, wherein one or both of the medical device or the local computing device is further configured fo transmit the medical report {0 one or more remote computing devices via a communication network, the one or more remate computing devices being configured to access and display medical data associated with the medical report.

101. The system of claim 100, wherein the medical report comprises a 12-lead ECG report.

102. The system of claim 101, wherein the 12-Jead ECG report is one report of an integrated data source encoutier siructure.

103. The system of claim 101, wherein the 12-lead ECG report comprises electrical waveforms and an interpretation of one or more of the electrical waveforms, 104. The system of claim 100, wherein the medical device is configured to transmit the medical report to the local computing device using a wireless local area network.

105. The system of claim 100, wherein the medical device is configured to transmit the medical report to the local computing device using a personal area network.

106. The system of claim 100, wherein the medical device or the local computing device is configured to transmit the medical report to the one or more remote computing devices using a cellular network.

107. The system of claim 100, wherein the medical report is encrypied before it is transmitted by the medical device to the local computing device.

108. The system of claim 108, wherein the local computing device is configured to opt out of receiving commumcations front the medical device.

109. The system of claim 100, wherein the medical device comprises: a defibrillator, a patient monitor, an automated external defibrillator, a ventilator, an automated chesi compression device, or a wearable defibrillator. 11k The system of claim 100, wherein the one or more remote computing devices are configured to display a list of received medical reports.

111. The system of claim 110, wherein the one or more remote computing devices are configured to filter the list of received medical reports based on timestamps associated with the medical reports, 112. A mobile computing device configured to receive and transmit medical data reports, the mobile computing device comprising: a memory. a user interface; a network interface: and at least one processor communicatively coupled with the user interface, the network interface, and the memory, the at least one processor being configured to: automatically receive a medical report transmitted from a medical device without sending a request to the medical device for the medical report; provide access to the medical report via the user interface; and transmit the medical report (0 one or more remote computing devices.

113. The mobile computing device of claim 112, wherein the medical report comprises a 12- {ead ECG report. 114, The mobile computing device of claim 113, wherein the 12-lead ECG raport is one report of an integrated data source encounter structure.

113. The mobile computing device of claim 113, wherein the 12-lead ECG report comprises electrical waveforms and an interpretation of one or more of the electrical waveforms.

116. The mobile computing device of claim 112, wherein the medical report is automatically received via a wireless local area network.

117. The mobile computing device of claim 112, wherein the medical report is automatically received via a personal area network, 118. The mobile computing device of claim 112, wherein the at least one processor is configured to transmit the medical report to the one or mote temote computing devices using a cellular network.

119. The mobile computing device of claim 112, wherein the medical report is encrypted before being received.

120. The mobile computing device of claini 112, wherein the at feast one processor is configured to opt out, via the user interface, from receiving communications from the medical device.

121. The system of claim 112, wherein the medical device comprises: a defibrillator, a patient monitor, an avtomated external defibrillator, a ventilator, an awtomated chest compression device, or a wearable defibritiator.

122. A computer implemented process for receiving and transmutting medical data reports, the computer implemented process comprising: automatically receiving a medical report transmitted from a medical device without sending a request to the medical device for the medical report; providing access to the medical report via a user interface; and transmitting the medical report to one ar more remote computing devices.

123. The compuier implemented process of claim 122, further comprising displaying one or more waveforms associated with the medical report via g display.

124. The computer implemented process of claim 122, wherein the medical report comprises a 12-lead BCG repost.

125. The computer implemented process of claim 124, wherein the 12-lead ECG report is one report of an integrated dala source encounter sttucture. 126, The computer implemented process of claim 124, wherein the 12-lead ECG report comprises electrical waveforms and an interpretation of one or more of the electrical waveforms.

127. The computer implemented process of claim 122, wherein the automatically receiving comprises automatically receiving the medical report via a wireless {ocal area network. 128, The computer implemented process of claim 122, wherein the automatically receiving comprises automatically receiving the medical report via a personal area network.

129. The computer implemented process of claim 122, wherein the transoritting comprises transmitting the medical report to the one or more remote computing devices using a cellular network.

130. The computer implemented process of claim 122, further comprising decrypting the medical report after receiving the medical report.

131. The computer implemented process of claim 122, further comprising receiving an input from a user via the user interface and ceasing the automatic receiving of any further medical reports in response to the inpul.

132. A non-transitory computer-readable storage medium storing instructions configured to execute the computer implemented process of any one of claims 122 - 131.

133. A mobile computing device comprising the non-transiiory computer-readable storage medium of claim 132.

Images