Patent Publication Number: US-2022223276-A1

Title: Systems and methods for and displaying patient data

Description:
CROSS-REFERNCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. application Ser. No. 13/798,661, filed on Mar. 13, 2013, which claims the benefit and priority of U.S. Provisional Application No. 61/624,954, filed Apr. 16, 2012, the entire contents of which are expressly incorporated herein by reference in their entirety. 
    
    
     BACKGROUND 
     Implementations of the present disclosure are directed to displaying patient data and/or information on mobile devices. 
     While physicians and other health care providers currently utilize a large number of products and systems that benefit from advances in wireless communication technology, there are still significant limitations to the information that can be transmitted, received, and displayed over these devices in a practical and efficient manner. There are many limitations that are intrinsic to mobile devices, especially those constraints related to speed, performance, memory, and display size. In addition, because of the critical nature of medical data, it is important that the technology work reliably and efficiently over potentially low speed, low bandwidth, and sometimes intermittent wireless connections. 
     SUMMARY 
     Implementations of the present disclosure provide methods for providing a user of a mobile device access to patient information and patient physiological data. In some examples, methods include actions of receiving user input, the user input indicating a user command to display a waveform strip screen, in response to the user input, processing patient-specific data to provide waveform data, and displaying the waveform strip screen on the mobile device, the waveform strip screen displaying one or more waveform strips, each waveform strip of the one or more waveform strips being based on the waveform data and graphically depicting a physical waveform strip. Other implementations of this aspect include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices. 
     These and other implementations can each optionally include one or more of the following features: a waveform strip of the one or more waveform strips includes a real-time waveform strip; the real-time waveform strip is updated in response to patient data provided from a remote monitoring device; the real-time waveform strip is animated to scroll absent user input based on updates to waveform data used to provide the real-time waveform strip; a waveform strip of the one or more waveform strips includes a historical waveform strip; actions further include receiving user input to the historical waveform strip, and in response to the user input, animating the waveform strip to scroll to display portions of a waveform that were absent from the waveform strip before scrolling; the historical waveform strip includes a strip stack; scrolling of the historical waveform strip induces animation of waveform strip segments to be unfolded from the strip stack; scrolling of the historical waveform strip induces animation of waveform strip segments to be folded into the strip stack; each waveform strip provides a graphical representation of strip paper, the strip paper including one or more scales; each scale is associated with at least one unit of measure; the waveform strip screen further displays at least one waveform view that depicts one or more waveforms respectively corresponding to waveforms of the one or more waveform strips; the at least one waveform view includes a scrubber bar that provides a reference to associate waveforms of the one or more waveform strips to the one or more waveforms of the at least one waveform view and actions further include receiving user input, the user input indicating movement of the scrubber bar, and in response to the user input, scrolling at least one waveform strip relative to movement of the scrubber bar. 
     Other aspects of the present disclosure provide systems including one or more processors, and a computer-readable medium coupled to the one or more processors having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform one or more of the methods provided herein. 
     It is appreciated that methods in accordance with the present disclosure can include any combination of the aspects and features described herein. That is to say that methods in accordance with the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of the aspects and features provided. 
     The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. 
    
    
     
       DESCRIPTION OF DRAWINGS 
       The patent or application file contains at least one drawing executed in color. Copies of this patent or patent application publication with color drawing(s) will be provided by the Office upon request and payment of the necessary fee. 
         FIG. 1  is a schematic illustration of an example system architecture in accordance with implementations of the present disclosure. 
         FIG. 2  is a schematic illustration of another example system architecture in accordance with implementations of the present disclosure. 
         FIG. 3  is a functional block diagram of an example system in accordance with implementations of the present disclosure. 
         FIG. 4  is a more detailed view of the functional block diagram of  FIG. 3 . 
         FIG. 5  depicts an example platform for providing integrated and unified views of patient data and patient information. 
         FIG. 6  depicts example components and sub-components that can be included in core components of  FIG. 5 . 
         FIGS. 7-10  depict example graphical user interfaces (GUIs) for providing integrated and unified views of patient data and patient information in accordance with implementations of the present disclosure. 
         FIG. 11  is a flowchart illustrating an example process that can be executed in accordance with implementations of the present disclosure. 
     
    
    
     Like reference symbols in the various drawings indicate like elements. 
     DETAILED DESCRIPTION 
     Implementations of the present disclosure are generally directed to an enterprise scalable, data- and vendor-agnostic mobility architecture to securely deliver patient data and information from medical devices, electronic medical records (EMRs) and patient monitors to healthcare providers anywhere across a healthcare continuum. More particularly, implementations of the present disclosure provide integrated and unified views of patient data and patient information on mobile devices (e.g., smartphones, tablets) from a plurality of data sources across the healthcare continuum. As discussed in further detail herein, implementations of the present disclosure enable timely and collaborative clinical decision-making, and enable healthcare systems to better track quality metrics, empower a mobile workforce, expand networks, and achieve clinical transformation. 
     Example systems and methods that can be included in implementations of the present disclosure are provided in U.S. Provisional Application Ser. No. 61/771,591, filed Mar. 1, 2013, the contents of which are expressly incorporated herein by reference in the entirety. 
     Referring now to  FIG. 1 , an example system architecture  100  is illustrated, and includes a mobile device  102 , connectivity interface(s)  104 , a network  106 , a first facility system  108 , and a second facility system  110 . As discussed in further detail herein, data is transferred from each of the first and second facility systems  108 ,  110  through the network  106  and connectivity interface(s)  104  for presentation, or display on the mobile device  102 . Further, data can be transferred from the mobile device  102  through the connectivity interface(s)  104  and the network  106  to each of the first and second facility systems  108 ,  110 . Although a single mobile device  102  is illustrated, it is contemplated that one or more mobile devices  102  can communicate with each of the first and second facility systems  108 ,  110  through the network  106  and the connectivity interface(s)  104 . Similarly, although two facility systems are illustrated, implementations of the present disclosure can include one or more facility systems. 
     The mobile device  102  can include any number of example devices. Such example devices include, but are not limited to, a mobile phone, a smartphone, a tablet computing device, a personal digital assistant (PDA), a laptop personal computer (PC), a desktop PC, and/or appropriate combinations thereof. In the depicted example, the mobile device  102  includes a display  122 , a processor  124 , memory  126 , an input interface  128 , and a communication interface  130 . The processor  124  can process instructions for execution of implementations of the present disclosure. The instructions can include, but are not limited to, instructions stored in the memory  126  to display graphical information on the display  122 . Example displays include, but are not limited to, a thin-film-transistor (TFT) liquid crystal display (LCD), or an organic light emitting diode (OLED) display. The memory  126  stores information within the mobile device  102 . In some implementations, the memory  126  can include a volatile memory unit or units, and/or a non-volatile memory unit or units. In other implementations, removable memory can be provided, and can include, but is not limited to, a memory card. Example memory cards can include, but are not limited to, a secure digital (SD) memory card, a mini-SD memory card, a USB stick, and the like. 
     In some examples, the input interface  128  can include a keyboard, a touchscreen, a mouse, a trackball, a microphone, a touchpad, and/or appropriate combinations thereof. In some implementations, an audio codec (not shown) can be provided, which receives audible input from a user or other source through a microphone, and converts the audible input to usable digital information. The audio codec can generate audible sound, such as through a speaker that is provided with the mobile device  102 . Example sounds can include sound from voice telephone calls, recorded sound (e.g., voice messages, music files, etc.), and/or sound generated by applications operating on the mobile device  102 . 
     The mobile device  102  may communicate wirelessly through the communication interface(s)  104 , which can include digital signal processing circuitry. The communication interface(s)  104  may provide communications under various modes or protocols including, but not limited to, GSM voice calls, SMS, EMS or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, and/or GPRS. Such communication may occur, for example, through a radio-frequency transceiver (not shown). Further, the mobile device can be capable of short-range communication using features including, but not limited to, Bluetooth and/or WiFi transceivers (not shown). 
     The mobile device  102  communicates with the network  106  through the connectivity interface(s)  104 . In some examples, the connectivity interface(s)  104  can include a satellite receiver, cellular network, a Bluetooth system, a Wi-Fi system (e.g., 802.x), a cable modem, a DSL/dial-up interface, a private branch exchange (PBX) system, and/or appropriate combinations thereof. Each of these connectivity interfaces  104  enables data to be transmitted to/from the network  106 . In some examples, the network  106  can be provided as a local area network (LAN), a wide area network (WAN), a wireless LAN (WLAN), a metropolitan area network (MAN), a personal area network (PAN), the Internet, and/or combinations thereof. 
     In the example systems of  FIGS. 1 and 2 , the first facility system  108  includes a plurality of facilities  140 , and the second facility system  110  includes a facility  140 . It is contemplated that each facility system  108 ,  110  can include one or more facilities, and is not limited to the example arrangement described herein. In the case of multiple facilities, the facilities can be remotely located from one another, and/or can be located at a common location, or site (e.g., separate departments in a common (the same) building). Each facility system  108 ,  110  can be provided as a medical care system, for example, which medical care system can include one or more hospitals, hospital systems, clinics, physician offices, and the like. 
     In some examples, each facility  140  includes an associated information system  142 , computer interface(s)  144 , and patient monitoring device(s)  146 . Example information systems can include, but are not limited to, a clinical information system (CIS), an EMR system, an electronic health record (EHR) system, and/or a hospital information system (HIS). Each information system  142  can be provided as a server, and supports the acquisition, storage, modification, and distribution of clinical information, such as patient data, throughout the facility  140  and/or facility system  108 ,  110 . In some examples, each information system  142  can communicate with one or more ancillary information systems (not shown) that can include, but are not limited to, a pharmacy management system, a laboratory management system, and/or a radiology management system. Although the example system architecture  100  includes an information system  142  located at each facility  140 , it is contemplated that the facilities  140  can communicate with a common information system  142  that is remotely located from either facility  140 , or that is located at one of the facilities  140  within the facility system  108 ,  110 . 
     In some examples, the computer interface  144  can communicate with the information system  142  to enable access to information that is stored within, and managed by the information system  142 . In some examples, the computer interface  144  can include a personal computer (PC) (e.g., desktop, laptop, or tablet). Although a single computer interface  144  is illustrated in the example architectures described herein, it is contemplated that one or more computer interfaces  144  can communicate with the information system  142 . Communication between each computer interface  144  and the information system  142  can be achieved via a direct connection, or remotely through a network (not shown) that can include, but is not limited to, a LAN, a WAN, a WLAN, and/or the Internet. 
     In some examples, each patient monitoring device  146  monitors physiological characteristics of a particular patient  150 , and generates data signals based thereon. As discussed in further detail herein, implementations of the present disclosure provide patient monitoring devices that include a computing device, such as a tablet computing device. The data signals are communicated to the information system  142 , which collects patient data based thereon, and stores the data to a patient record that is associated with the particular patient. An example patient record can include an electronic medical record (EMR). Although a single patient monitoring device  146  is illustrated per each patient  150 , it is contemplated that multiple patient monitoring devices  146  can monitor a particular patient  150 . The patient monitoring device(s)  146  can communicate with the information system  142  via a direct connection, or remotely through a network (not shown) that can include, for example, a LAN, a WAN, a WLAN, and/or the Internet. 
     In some examples, the patient data is made available for display on the computer device  144 . A healthcare provider (e.g., a nurse and/or physician) can augment the patient data by inputting patient information that is also stored to the information system  144 . More specifically, the healthcare provider can input patient information corresponding to a particular patient  150 , which patient information can be stored to the patient record (e.g., EMR). As one example, a nurse can input nursing notes, which nursing notes can be stored to the patient record in the information system. Example patient information can include any non-physiological information corresponding to a patient (e.g., name, age, date-of-birth (DOB), gender). 
     As discussed above, each information system  142  stores patient data that can be collected from the patient monitoring devices  146 , as well as additional patient information, that can include information that is input by a healthcare provider. The information system  144  communicates the patient data and/or the additional patient data to a data management system (DMS)  160 . The DMS  160  can be provided as a server, or a virtual server, that runs server software components, and can include data storage including, for example, a database and/or flat files. In the example system architecture  100  of  FIG. 1 , each facility system  108 ,  110  includes a corresponding DMS  160 . In such an arrangement, each information system  142  communicates patient data, and/or additional patient data to the DMS  160 . Furthermore, and as discussed in further detail below, the DMS  160  can communicate ancillary information to the information system  142 . Communication between the DMS  160  and the information system(s)  142  can be achieved via a direct connection, or remotely through a network (not shown) that can include, for example, a LAN, a WAN, a WLAN, and/or the Internet. 
     In some examples, a DMS  160  corresponding to a particular facility system can be remotely located from any of the facilities  140  of the facility system  108 ,  110 , or can be located at a particular facility  140  of the facility system  108 ,  110 . In the example system architecture  100  of  FIG. 1 , the DMS  160  is remotely located from either facility  140  within each of the facility systems  108 ,  110 . It is contemplated, however, that the DMS  160  can be located at one of the facilities  140 , and remote from the other facility  140 . 
     In the example system architecture  100 ′ of  FIG. 2 , a DMS  160 ′ is provided that is common to (the same for) the facility systems  108 ,  110 . For example, the DMS  160 ′ can be described as being common to various facility systems  108 ,  110 , and is not associated with a particular facility system  108 ,  110 . For example, the DMS  160 ′ can be hosted by a third-party vendor (e.g., a cloud service provider). In some examples, each information system  42  communicates with the DMS  160 ′ via a direct connection, or remotely through a network (not shown) that can include, but is not limited to, a LAN, a WAN, a WLAN, and/or the Internet. In the example arrangement of  FIG. 2 , the DMS  160 ′ communicates with each of the information systems  142  through the network  106 . The information systems  142  communicate patient data and/or patient information to the DMS  160 ′, and the DMS  160 ′ can communicate ancillary information to the information system  142 , as discussed in further detail below. 
     In the example system architecture  100  of  FIG. 1 , the facility  140 , or facility system  108 ,  110  installs the DMS  160  as a local DMS, and the DMS  160  sits at the local site with other servers that can include, for example, the information system  142 . In some implementations, the DMS  160  can be sectioned off, or separated from a logical network perspective, but still physically exists with the other servers that belong to the respective facility  140 . In some examples, server components are installed on the DMS  160 , which components can include, for example, a database component, a database synchronization component, a web services component, and/or a structured query language (SQL) component. An information system interface can also be installed on the DMS  160 , and functions as the interface to the information system  142 . As one example, the information system interface can include OBLink, provided by GE Healthcare. In some implementations, the DMS  160  can be arranged in a multiple server configuration, in which one server only hosts web service related components and is logically segregated, and another server has the remaining necessary server components installed. 
     The example system architecture  100 ′ of  FIG. 2 , provides for the remote location of data collection at the DMS  160 ′. In such implementations, the DMS  160 ′ can be provided at a third-party site, remote from any of the facilities  140 , or facility systems  108 ,  110 . The third-party functions as a DMS host, and the necessary server components are installed on the remotely hosted DMS  160 ′. In some implementations, a business-to-business (B2B) virtual private network (VPN) can be created between the remotely hosted DMS  160 ′ and the network of the facility  140  or facility system  108 ,  110 . In this manner, the facility  140  and/or facility system  108 ,  110  forgoes the purchase and/or maintenance of another physical server, or DMS  160 . Further, the up-time and the status of availability of the DMS  160 ′ are easier to manage on the part of a dedicated third-party. The DMS&#39; access to the network can be attended to by the third-party, as opposed to burdening the facility  140 , or the facility systems  108 ,  110 . Further, the third-party can implement virtual server technologies to leverage multiple DMS installations on a single physical server. In such implementations, a plurality of virtual servers are logically partitioned in a single physical server, and each virtual server has the capability of running its own operating system and server components, and can be independently booted. 
     In accordance with implementations of the present disclosure, the DMS  160 ,  160 ′ synchronizes and transfers data between the mobile device  102 , or multiple mobile devices  102 , and the information system  142 , or multiple information systems  142 . More specifically, the DMS  160 ,  160 ′ processes and prepares the patient data and/or patient information for transfer to and presentation on the mobile device  102 , or multiple mobile devices  102 , from the information system  142 , and/or other systems, as discussed in further detail herein. The DMS  160 ,  160 ′ also processes and prepares ancillary information for transfer to and storage in the information system  142  from the mobile device  102 , or multiple mobile devices  102  for potential presentation at a corresponding computer device  144 . Example DMSs can include, but are not limited to, the AirStrip Server provided by AirStrip Technologies, LLC, which AirStrip Server includes AirStrip Server Components installed therein. 
     Referring now to  FIGS. 3 and 4 , example module structure, or system  300  that can be implemented to provide features of the present disclosure will be described in detail. In some examples, the example system  300  enables patient data and patient information to be communicated to/from, and to be exchanged between mobile devices and data sources across healthcare continua. In some examples, each module can be provided as one or more computer-executable programs that are executed using one or more computing devices (e.g., computing devices provided as part of a DMS, computing devices located at one or more facilities of a facility system). 
       FIG. 3  illustrates an overview of the example system  300 . In the depicted example, the module structure includes modules located at a DMS  301 , a first facility system  302  and a second facility system  304 . In some examples, the first facility system  302  and the second facility  304  can be included in at least a portion of a healthcare continuum, discussed in further detail herein. The facility system  302  includes a patient record module  303  (e.g., EMR module) that accesses one or more patient records managed and stored by the facility system  302 . The facility system  304  includes a patient record module  305  (e.g., EMR module) that accesses one or more patient records managed and stored by the facility system  304 . 
     In the depicted example, and as discussed in further detail herein, patient data and/or information can be provided for integrated and unified display on the mobile device  102  through the network  106  and the DMS  301  from across healthcare continua (e.g., the facility systems  302 ,  304 ). In some examples, patient data and/or information can be provided for display on a mobile device  102 ′,  102 ″ through the network  106  from a facility system (e.g., the facility system  302 ,  304 ). In some examples, the mobile devices  102 ,  102 ′,  102 ″ are the same device. That is, for example, a mobile device can receive patient data and/or information from across a healthcare continuum, and/or from individual facility systems. 
     In some implementations, the DMS  301  includes a web module  310 , a host module  312 , a data cache module  314  and an adapter module  316 , web module  320 , a host module  322 , a data cache module  324 , a collector module  326 . In general, modules of the DMS  301  enable the DMS  301  to retrieve and combine data from multiple facility systems (e.g., the facility systems  302 ,  304 ) across healthcare continua. In some examples, the web module  310  provides a first-level network facing interface to the DMS infrastructure. In some examples, and in response to a request from a mobile device (e.g., the mobile device  102 ), the web module  310  performs request validation and user authentication and routes the request to the host module  312 . In some examples, the web module  310  includes one or more sub-modules. Example sub-modules include a request validation sub-module, which validates received requests, a user authentication module, which authenticates an identity of the user and/or mobile device from which a request is received, and a request routing sub-module, which routes requests after validation and authentication. 
     In some implementations, the host module  312  orchestrates request processing. In some examples, the host module  312  includes one or more sub-modules. Example sub-modules include a request parsing sub-module that parses received requests, a pipeline assembly sub-module, a pipeline processing sub-module, an operation execution sub-module, a data access sub-module, a results formatting sub-module, an access control sub-module, an encryption sub-module, a data conditioning sub-module, and a logging sub-module. In some examples, the host module  312  parsers a received request (e.g., using the request parsing sub-module) to determine, for example, what type of device issued the request, which application executing on the device issued the request, and/or patient data/information (or other data such as analytical data, discussed below) is needed to fulfill the request. In some examples, and based on the parsed information, the host module  312  builds a pipeline (e.g., using the pipeline assembly sub-module). In some examples, a pipeline can be provided as a list of tasks that need to be executed to fulfill the request. Example tasks can include retrieving particular patient data/information, processing retrieved patient data to generate additional data and/or data visualizations (e.g., analytical data, trend graphs, discussed below), encrypting/decrypting retrieved data, performing access control to retrieve data, generating logs of tasks. 
     In some implementations, the host module  312  coordinates data retrieval with the data cache module  314  (e.g., using the data access sub-module). The retrieved data is provided back to the host module  312 . In some examples, the host module  312  processes the retrieved data (e.g., using the operation execution sub-module, the results formatting sub-module and/or the data conditioning sub-module). In some examples, the retrieved data is processed to generate additional data (e.g., data used for data visualizations). In some examples, the retrieved data and/or the additional data are conditioned to provide efficient transfer back to the requesting mobile device. In some examples, conditioning can include converting data based on transmission protocol, formatting data for optimal display on the particular device, and/or packaging data to send to the requesting device. 
     In some implementations, the data cache module  314  enables access to and optional storage of detailed patient data/information used by other components of the system  300 . In some examples, the data cache module  314  includes one or more sub-modules and/or data stores. An example sub-module can include a cache services sub-module. In some examples, the data cache module  314  can operate in a pass-through mode (real-time mode) and a reposed mode. In some examples, patient data/information required to satisfy a given request can be directly accessed from a source system (e.g., the facility system  302 ,  304 ) in real-time. In such examples, the data cache module  314  operates in a pass-through mode, retrieving the patient data/information from multiple data sources and passing the patient data/information onward for responding to the request. In some examples, an application program interface (API), or other programmatic mechanism can be used to retrieve the patient data/information. In some examples, in the pass-through mode, patient data/information is not stored in a persistent data store accessed by the data cache module  314 . In some implementations, it might be desired to improve retrieval performance. Consequently, the data cache module  314  can store data identifiers and/or pointers in a persistent data store. When in the pass-through mode, the data cache module  314  uses the adapter module  316  to perform the actual retrieval of patient data/information from one or more facility systems. 
     In some examples, the patient data/information that is required to satisfy a request cannot be directly accessed from the facility systems (e.g., the facility systems  302 ,  304 ). In such examples, the data cache module  314  operates in the reposed mode. In some examples, in the reposed mode, the data cache module  314  stores a detailed copy of the patient data/information in the persistent data store. That is, for example, stored patient data/information is stored at the DMS-level, but had been retrieved from remote data sources (e.g., data sources located at the facility systems  302 ,  304 ). In some examples, when a request is made for patient data/information in the reposed mode, the patient data/information is retrieved directly from the persistent data store (e.g., by the cache services sub-module). 
     In some implementations, the adapter module  316  enables the retrieval of patient data/information from across healthcare continua. Consequently, the adapter module  316  can be referred to as a federated adapter module. In some examples, in response to receiving a request from the mobile device  102  for patient data/information from multiple data sources (e.g., the facility systems  302 ,  304 ), the data cache module  314  utilizes the adapter module  316  to retrieve the requested patient data/information from the multiple data sources. In some examples, the adapter module  316  communicates with local host modules (discussed in further detail below) of the respective facility systems. 
     In some implementations, the request processing operation of the DMS  301  is stateless. More particularly, the modules of the DMS  301  handle each received request as a distinct unit and, once a request is handled, stores no state information associated with a completed request. In other words, after the DMS  301  has processed a request, the DMS  301  (e.g., modules within the DMS  302  that handled the request) “forget” that the request even occurred. In this manner, subsequently received requests are not influenced by (e.g., handled based on) previously processed requests. 
     In some examples, operation of the DMS  301  is stateless, but the DMS  301  can still provide a log of requests handled (e.g., using the logging sub-module). For example, a request log can be accessed during an audit of the system  300 . 
     In some implementations, each facility system  302 ,  304  includes one or more local web modules  320 ,  330 , one or more local host modules  322 ,  332 , one or more local data cache modules  324 ,  334 , and one or more vocabulary service modules  328 ,  338 . In the depicted example, the facility system  302  includes one or more collector modules  326 , and the facility system  304  includes one or more patient record (EMR) adapter modules  336 . 
     In some examples, each of the web modules  320 ,  330  provides functionality as similarly discussed above with respect to the web module  310 . More particularly, the web modules  320 ,  330  operate at a local level (e.g., local to the respective facility systems  302 ,  304 ), each performing request validation and user authentication, and routing requests to the respective local host modules  322 ,  332 . For example, the web modules  320 ,  330  can receive requests from the respective mobile devices  102 ′,  102 ″, can validate the requests and authenticate the respective users/mobile devices, and route the requests accordingly. In some examples, each web module  320 ,  330  includes one or more sub-modules. Example sub-modules include a request validation sub-module, which validates received requests, a user authentication module, which authenticates an identity of the user and/or mobile device from which a request is received, and a request routing sub-module, which routes requests after validation and authentication. 
     In some examples, each of the local host modules  322 ,  332  provides functionality as similarly discussed above with respect to the host module  312 . More particularly, the local host modules  322 ,  332  operate at a local level (e.g., local to the respective facility systems  302 ,  304 ), each orchestrating request processing. In some examples, the local host modules  322 ,  332  orchestrate request processing for requests received from the mobile device  102  through the DMS  301 , and/or from the respective mobile devices  102 ′,  102 ″ through the respective local web modules  320 ,  330 . In some examples, each local host module  322 ,  332  includes one or more sub-modules. Example sub-modules include a request parsing sub-module that parses received requests, a pipeline assembly sub-module, a pipeline processing sub-module, an operation execution sub-module, a data access sub-module, an access control sub-module and an encryption sub-module. 
     In some examples, each of the local data cache modules  324 ,  334  provides functionality as similarly discussed above with respect to the data cache module  314 . More particularly, the local data cache modules  324 ,  334  operate at a local level (e.g., local to the respective facility systems  302 ,  304 ), each enabling access to and optional storage of detailed patient data/information used by other components of the system  300 . In some examples, the each data cache module  324 ,  334  can operate in a pass-through mode and a reposed mode, as discussed above with respect to the data cache module  314 . In the pass-through mode, the local data cache modules  324 ,  334  retrieve the patient data/information from one or more local data sources and passed the patient data/information onward for responding to the request. In some examples, it might be desired to improve retrieval performance. Consequently, the local data cache modules  324 ,  334  can store data identifiers and/or pointers in a persistent data store. When in the pass-through mode, the local data cache modules  324 ,  334  use the collector module  326  and the patient record adapter module  336 , respectively, to perform the actual retrieval of patient data/information from local data source(s) (e.g., the patient record module  303  and the patient record module  305 , respectively). In some examples, when in the pass-through mode, the local data cache modules  324 ,  334  can write data back to the respective patient record modules  303 ,  305 . 
     In some examples, the patient data/information that is required to satisfy a request (e.g., from the mobile device  102 ′,  102 ″) cannot be directly accessed from the local data sources (e.g., the patient record modules  303 ,  305 ). In such examples, each local data cache module  324 ,  334  can operate in the reposed mode. In some examples, in the reposed mode, the local data cache module  324 ,  334  stores a detailed copy of the patient data/information in the persistent data store. That is, for example, stored patient data/information is stored at the local level, having been previously received from local data source(s) (e.g., the patient record modules  303 ,  305 ). In some examples, when a request is made for patient data/information in the reposed mode, the patient data/information is retrieved directly from the persistent data store (e.g., by the cache services sub-module). 
     In some implementations, the collector module  326  and the adapter module  336  are specific to the type of patient record module  303 ,  305 , respectively. In the example of  FIG. 3 , the patient record module  303  can be accessed based on a particular messaging protocol. An example messaging protocol can include the Health Level 7 (HL7) messaging protocol. In some examples, patient data/information provided based on such messaging protocols is reposed by the data cache module  324 . Consequently, requests for such data can be fulfilled based on operation of the data cache module  314  and/or the local data cache module  324  in the reposed mode, as discussed above. In some examples, changes to patient records in the patient record module  303  can trigger updating of reposed patient data/information by the data cache modules  314 ,  324 . For example, the collector module  326  can automatically receive a message from the patient record module  303  in response to a change/updated, triggering updating/changing of reposed patient data/information. 
     In the example of  FIG. 3 , the patient record module  305  supports programmatic interface (e.g., API) access. In some examples, patient data/information provided through programmatic interfaces is passed-through the data cache module  314  and/or the data cache module  334 . Consequently, requests for such data can be fulfilled based on operation of the data cache module  314  and/or the local data cache module  334  in the pass-through mode, as discussed above. In this manner, such patient data/information is not persisted by the data cache module  314 ,  334 . 
     Although the example of  FIG. 3  depicts facility systems  302 ,  304  having different types of patient record modules  303 ,  305 , it is appreciated that facility systems can include any appropriate combination of types of patient record modules and any number of patient record modules (e.g., patient record modules  303 ,  305 ), and respective adapter modules (e.g., modules  326 ,  336 ). Further, although the example of  FIG. 3  depicts two facility systems, implementations of the present disclosure are applicable in instances include any number of facility systems. 
     In some implementations, the vocabulary services modules  328 ,  338  perform translation between the vendor-specific vocabularies and a standard vocabulary. In this manner, patient data/information retrieved through the modules  303 ,  305  use standard vocabulary to be provided back to the mobile device  102  in a unified manner. For example, the patient record modules  303 ,  305  can each be provided by a respective third-party (e.g., a vendor) and can record data/information based on a vocabulary that is specific to the particular vendor. Consequently, data sources provided from different third-parties can refer to the same data/information or type of data/information using different terminology. In some examples, each vocabulary service module  328 ,  338  is specific to a respective patient record module  303 ,  305 . 
       FIG. 4  is a more detailed view of the functional block diagram of  FIG. 3 , depicting additional components of the example system  300 . In the depicted example, the DMS  301  further includes a patient list import module  400 , a patient membership portal module  402 , a patient matching service module  404 , a provider management (mgmt) module  406 , a patient information data store  408 , and a directory information data store  410 . In some examples, the patient information data store  408  stores patient demographic information  420 , a data pointer cache  422 , a patient-to-provider index  424  and a patient-to-facility index  426 . In some examples, the directory information data store  410  stores a facility directory  430 , a provider directory  432 , and provider-to-facility index  434 . 
     In some implementations, the patient list import module  400  enables initial and ongoing import of patient lists and patient demographic information for patients. In some examples, the patient list import module  400  provides an interface to receive a patient list, e.g., provided in a computer-readable document, and processes the patient list to populate the patient information data store  408  (e.g., the demographic information  420 ). In some examples, the patient membership portal module  402  provides an interface that enables users (e.g., an administrator) to establish relationships between patient data/information stored across healthcare continua and particular patients. In some examples, healthcare providers, facilities and/or facility systems across healthcare continua can be included in a healthcare organization (e.g., an accountable care organization (ACO)). In some examples, the patient membership portal module  402  enables a user to define relationships between multiple patient records (e.g., based on respective medical record numbers (MRNs)) to the healthcare organization. In some examples, relationship information defined through the patient membership portal module  402  can be stored in the patient information data store  408 . 
     In some implementations, the patient matching service module  404  can be accessed by the host module  312  and the patient membership portal module  402 . In some examples, the patient matching service module  404  can be accessed by an application executed on a mobile device (e.g., the mobile device  102 ) through the host module  312 . In some examples, the patient matching service module  404  processes patient data and/or patient information to identify potential patient matches between disparate data sources (e.g., multiple, different EMRs across the healthcare continuum). In some examples, patient information associated with confirmed matches (e.g., confirmed by an administrator through the patient membership portal module  402 , confirmed by a healthcare provider using a mobile device through the host module  312 ) can be stored in the patient information data store  408 . In some examples, a patient matching user interface (UI) is provided (e.g., displayed on a mobile device) and can be used by a healthcare provider to search for patients and establish, record and/or confirm relationships between patient records in different systems that are related to a single patient. 
     In some examples, the demographics information  420  includes information that can be used to identify any patient that has been established in the system. In some examples, the demographics information  420  can be used to search for patients, discussed in further detail herein. Example demographics information can include name, age and/or gender. In some examples, the data pointer cache  422  stores identifiers associated with detailed patient data. In some examples, the identifiers point to particular data stores, in which to be retrieved patient data/information is stored. In this manner, retrieval performance (e.g., speed) can be improved. In some examples, the patient-to-provider index  424  maps particular patients to one or more healthcare providers, and/or particular healthcare providers to one or more patients. For example, a patient can be treated by a plurality of healthcare providers (e.g., members of a patient care team, discussed below). As another example, a healthcare provider can treat a plurality of patients. In some examples, the patient-to-facility index  426  maps particular patients to one or more facilities and/or facility systems. In some examples, a patient can be mapped to particular facilities based on respective MRNs of the patient at the respective facilities. For example, a healthcare continuum for a particular patient can include a hospital and a clinic. In this example, the patient-to-facility index can map the patient to the MRN of the hospital and the MRN of the clinic. 
     In some implementations, the provider management portal module  406  provides an interface (e.g., web portal) to enable members of a healthcare organization (e.g., ACO) to update healthcare provider directory information and/or healthcare provider-to-facility relationships. For example, a physician can be associated with one or more facility systems of the healthcare organization and credentials (e.g., for log on and/or authentication) can be provided to enable the physician to access patient data/information provided from the one or more facility systems. 
     In some examples, the facility directory  430  provides a directory of the facilities interfaced to by the system (e.g., the DMS  301 ). In some examples, the facility directory  430  also provides configuration parameters to enable communication (messaging) between the system and computing devices associated with the respective facilities. In some examples, the provider directory  432  includes a directory of healthcare providers (e.g., nurses, physicians, specialists, and the like) that are able to access patient data/information through the system (e.g., the DMS  301 ). In some examples, the provider-to-facility index  434  maps each healthcare provider (e.g., in the provider directory) to one or more facilities. For example, a healthcare provider can treat patients at multiple facilities. In some examples, the provider-to-facility index  434  securely stores credentials of healthcare providers for facilities that the healthcare provider is mapped to. For example, a healthcare provider can have first credentials for accessing patient data/information at a first facility, and can have second credentials for accessing patient data/information at a second facility. In some examples, the provider-to-facility index  434  supports single sign-on functionality discussed in further detail herein. 
     An example data flow will be discussed to illustrate implementations of the present disclosure. It is appreciated that implementations of the present disclosure are equally applicable to other data flows. The example data flow can be initiated in response to a request received from a mobile device (e.g., the mobile device  102 ). In some examples, the request includes a user identifier, a device identifier, a patient identifier, patient data identifiers, patient information identifiers and additional data identifiers. In some examples, the user identifier can be used to determine the particular user that has issued the request, and the device identifier can be used to determine the particular device that transmitted the request. In some examples, the patient identifier identifies the particular patient that is the subject of the request, the patient data identifiers identify the particular patient data that has been requested, the patient information identifiers identify the particular patient information that has been requested, and the additional data identifiers identify additional data that has been requested. For example, the patient data identifiers can indicate that patient vital data has been requested, and the additional data identifiers can indicate that vitals alarm data and vital data trend visualizations have also been requested. 
     In the example data flow, the web module  310  receives the request and processes the request to validate the request and to authenticate the user, who submitted the request (e.g., based on the user identifier and/or the device identifier). Upon validation and authentication, the web module  310  provides the request to the host module  312 . The host module  312  processes the request, as discussed above. In some examples, it can be determined that patient data/information required to fulfill the request can be provided from the data cache module  314  (e.g., reposed mode). In such examples, the patient data/information is provided to the host module  312  from the data cache module  314 . In some examples, it can be determined that that patient data/information required to fulfill the request is to be retrieved from one or more data sources across a healthcare continuum of the patient (e.g., federated mode). 
     In some examples, if patient data/information required to fulfill the request is to be retrieved from one or more data sources across the healthcare continuum (e.g. federated mode), request information (e.g., assembled by the host module  312 , as discussed above) is provided to the adapter module  316  by data cache module  314 . In some examples, the adapter module  316  accesses information stored in the directory store  410  to request data from one or more facility systems (e.g., the facility system  304 ). For example, the adapter module  316  can be aware of which facility systems to retrieve patient data/information from (e.g., based on the patient-to-facility index  426 ) and can access the provider-to-facility index  434  to retrieve user credentials for the particular provider (e.g., user that issued the request). In this manner, the adapter module  316  can provide appropriate user credentials to respective facility systems for patient data/information retrieval. 
     In some examples, the adapter module  316  sends requests to identified facility systems, each request identifying patient data/information and providing appropriate user credentials. In some examples, respective host modules (e.g., the host module  332 ) of the facility systems receive the requests from the adapter module  316 , and can process the requests as similarly discussed above with reference to the host module  312 . The respective host modules fulfill the requests and provide the requested patient data/information back to the adapter module  316 . In some examples, the adapter module  316  provides the retrieved patient data/information to the host module  312 , which completes processing of the request, as discussed above, and provides a response to the mobile device that issued the request. 
     As discussed at the outset, the present disclosure provides a healthcare provider, or user of the mobile device  102 , with secure, remote access to patient data and/or patient information. Example patient data can include physiological data. In some examples, physiological data can be obtained from patient monitoring device(s). In some examples, physiological data can be obtained by a local healthcare provider (e.g., a nurse, or physician measuring blood pressure, temperature, heart rate). In some examples, physiological data can be recorded in one or more patient records (e.g., EMRs). In the example case of a maternity patient, patient data can include delivery progress information such as cervical exam status, membrane status, gravida, para, epidural status, and/or whether the patient is attempting a vaginal birth after cesarean (VBAC). In some examples, the term patient information refers to information corresponding to a particular patient that is, for example, input into the information system  142  by the local healthcare provider. Example patient information can include the patient&#39;s name, the name of the doctor(s) assigned to the patient, the nurse(s) assigned to the patient, a facility identification, a patient bed identification, a summary of patient data, and/or chart annotations. The term patient information can also refer to patient information provided from one or more patient records (e.g., EMRs). 
     The patient data and/or patient information provided to the remotely located user can be provided as real-time data, and/or as historical data and information. The patient data and/or patient information is communicated between the mobile device  102  and the DMS  160 ,  160 ′ using a secure connection that is established over the network  106 . A secure log-in, or sign-on process is provided, which is preferably compliant with the provisions of the Health Insurance Portability and Accountability Act (HIPAA). The secure sign-on authenticates the identity of the user of the mobile device  102  based on a unique user ID and password combination. Both the user ID and the password must be correct in order to establish the secure communication between the mobile device  102  and the DMS  160 ,  160 ′. 
     In some examples, a census, or patient list is provided, which captures a variety of the information and/or data described herein that is associated with each of one or more monitored patients  150 . Strip charting is also provided, in which patient data and/or information can be presented to the user in graphical form. In the example case of a maternity patient, a fetal strip and maternal contraction information can be provided for a particular patient  150 . More specifically, the particular patient  150  is selected from the patient list, and the patient information and/or data is subsequently presented. The presented information and/or data can include a fetal strip and maternal contraction waveform, the patient name, the hospital name, the patient room and/or bed number, and the date and time. The strip charting can provide a real-time view of the patient data, as well as a historical view of the patient data. More specifically, the waveform display can be updated in real-time, such that the user of the mobile device  102  observes the patient data as it occurs and/or is recorded. The user can scroll through the waveform display, to view historical patient data, as described in further detail below. 
     Several navigation features can be provided that enable the user to manipulate a view of the waveform display. In some implementations, the user can zoom in/out of the displayed image. In this manner, the user can view very specific waveform information, and/or other waveform micro-characteristics by zooming in, for example, and/or can view patterns or other waveform macro-characteristics by zooming out, for example. In some implementations, the user can scroll forward or backward through the waveform display. In this manner, the user can view historical patient data. 
     A patient data display can also be provided. In some implementations, the patient data display can overlay the strip charting described herein. In other implementation, the patient data display can be provided as an overlay, and/or as a separate display. The patient data display can include, but is not limited to, the patient&#39;s name, age, fetal gestation, gravida, parity, cervical exam information, and physician name. 
     Implementations of the present disclosure can be realized on any one of a number of operating systems, or platforms  302  associated with the particular mobile device  102 . Example platforms include, but are not limited to, RIM Blackberry, Apple iOS and/or OS X, MS Pocket PC, Win Mobile (Pocket PC, Smartphone), Win Mobile (standard, professional) and/or any other appropriate platforms (e.g., Google Android, and Hewlett-Packard WebOS, Microsoft Windows, Unix, Linux). 
     As discussed in detail herein, implementations of the present disclosure are directed to systems and methods of providing integrated and unified views of patient data and patient information from disparate data sources and/or products. More particularly, implementations of the present disclosure provide integrated and unified views of patient data and patient information retrieved from across a healthcare continuum. In some examples, the healthcare continuum can include a plurality of disparate clinical data sources. In some examples, a clinical data source can correspond to one or more categories of healthcare services. Example categories can include emergency medical services (EMS), outpatient services, inpatient services, ambulatory services, post-acute services, home services and stand-alone services. Example EMS can include emergency departments (e.g., emergency room (ER) of a hospital), urgent care facilities and transport (e.g., ambulance). Example outpatient services and/or inpatient services can include hospitals and/or critical access hospitals (CAHs). Example ambulatory services can include clinics, physicians groups/offices, surgery centers and pre-acute care. Example post-acute services can include skilled nursing facilities, long-term care hospitals, rehabilitation centers and home healthcare. Example stand-alone services can include imaging centers (e.g., MIR), oncology centers, laboratories, virtual call centers and retail clinics. 
       FIG. 5  depicts an example platform  500  for providing integrated and unified views of patient data and patient information. The example platform  500  includes one or more product applications  502  and core components  504 . The example platform enables the transfer of patient data/information to/from one or more data sources  506  for display on a mobile device (e.g., the mobile device  102 ). In some examples, the example platform  500  is provided as one or more computer-executable programs that are executed using one or more computing devices (e.g., the DMS  160 ,  160 ′). Example data sources  506  can include one or more medical devices (e.g., bedside monitors), one or more EMRs, health information exchange (HIE) data  512 , image data  514  (e.g., x-ray data), and sensor data  516 . 
     In some implementations, the example platform  500  can include a mobile application platform  520 . An example mobile application platform  520  can include the mobile application platform disclosed in U.S. application Ser. No. 13/716,974, filed Dec. 17, 2012, and which claims the benefit of U.S. Prov. App. No. 61/579,954, filed Dec. 23, 2011, the disclosures of which are expressly incorporated herein by reference in their entireties. 
     In some examples, the mobile application platform  520  separates native graphical user interface (GUI) and operating system components from the application logic. In this manner, the mobile application platform  520  translates and interprets application logic into the native languages of each operating system of mobile devices to/from which patient data/information is to be transferred, and embraces the unique properties, features, function, and usability of each operating system. In some implementations, the mobile application platform  520  embodies a template-based approach, where one or more templates are provided, each template corresponding to a view of patient data/information that is to be presented on a mobile device. In some examples, and as discussed in further detail herein, default templates can be provided, which provide default views of patient data/information. In some examples, custom templates can be provided, and can include templates customized by a user of a mobile device. 
     In some examples, the mobile application platform  520  processes patient data/information based on a template that defines a view to be displayed on the mobile device. In some examples, the mobile application platform  520  generates instructions for rendering graphics based on the patient data/information and the template, and provides instructions to the mobile device, the mobile device executing the instructions to provide the template-based view of the patient data/patient (e.g., rendering the patient data/information in a view displayed on the mobile device). 
     In some examples, the product applications  502  can include medical software applications that enable mobility in healthcare. For example, products can enable patient information and patient data (e.g., waveforms and other critical data from EMRs, bedside monitors and devices, pharmacy, lab, and other clinical information systems) to be securely and natively accessed by healthcare provides on mobile devices. Example products can include an obstetrics (OB) product (e.g., AirStrip OB provided by AirStrip Technologies, LLC), a cardiologiy product (e.g., AirStrip CARDIO provided by AirStrip Technologies, LLC), a patient monitoring product (e.g., AirStrip PATIENT MONITORING provided by AirStrip Technologies, LLC), and an EMR extension product (e.g., AirStrip EMR EXTENDER provided by AirStrip Technologies, LLC). 
       FIG. 6  depicts example components and sub-components that can be included in the core components  504  of  FIG. 5 . In some examples, each component and/or sub-component can be provided as one or more computer-executable programs that can be executed using one or more computing devices (e.g., computing devices of the DMS  160 ,  160 ′ of  FIGS. 1 and 2 ). In some examples, the core components provide secure data access and data transport, single sign-on and profile/context management, interoperability (data adapters and interfaces), intelligent message routing, master patient indices (e.g., EMPI) and care collaboration. 
     In the depicted example, the core components  504  include a security component  600 , a care coordination and collaboration interfaces component  602 , a data and workflow integration component  604 , a data source adapters component  606  and a services component  608 . In the depicted example, the security component  600  includes a single sign-on sub-component  610  and a user context/profiles sub-component  612 . In the depicted example, the care coordination and collaboration interfaces component  602  includes a voice sub-component  614 , a video sub-component  616  and a messaging sub-component  618 . In the depicted example, the data and workflow integration component  604  includes a patient index (or indices) component  620  and an intelligent routing sub-component  622 . In some examples, the data source adapters component  606  can include adapter services sub-components  624  (e.g., the adapter services module  324  of  FIG. 3 ). In the depicted example, the services component  608  includes a reporting and analytics sub-component  626 , a clinical transformation sub-component  628  and an implementation and support sub-component  630 . 
     In some examples, the single sign-on sub-component  610  supports single sign-on functionality, discussed herein. In some examples, a user can be authenticated once (e.g., by providing log-in credentials to an application executed on a mobile device) and can be provided access to data across a plurality of data sources, without being authenticated for each data source individually. In some examples, the user context/profiles sub-component  612  supports user-specific customizations based on a context of the user and/or a profile of the user, as discussed in further detail herein. Example contexts can include the user being an attending physician at one hospital and a part-time physician at another hospital. In some examples, one or more profiles can be associated with the user, each profile reflecting one or more customizations associated with the particular user. For example, the user can customize a default view that can be displayed on a mobile device, to provide a customized view. Consequently, after the user is authenticated, one or more user-defined (user-customized) views can be provided to the mobile device. 
     In some examples, the care coordination and collaboration interfaces component  602  supports collaboration between members of a patient care team. For example, a patient care team can include a physician, a consultant, a specialist, an intensivist and a nurse. In some examples, the voice sub-component  614  provides voice-based collaboration between care team members (e.g., teleconferencing). In some examples, the video sub-component  616  provides video-based collaboration between care team members (e.g., video conferencing). In some examples, the messaging sub-component  618  provides messaging-based collaboration between care team members (e.g., SMS/MMS text messaging). In some examples, the care coordination and collaboration component  602  provides security in remote collaboration between care team members (e.g., secure teleconferencing, secure video conferencing and/or secure messaging). 
     In some examples, the data and workflow integration component  604  integrates data from a plurality of data sources and routes data for display on mobile devices. In some examples, the patient index (or indices) component  620  provides one or more indices for mapping users to facilities and/or patients. In some examples, one or more indices can be provided to associate a user (e.g., a physician) with a facility or multiple facilities (e.g., hospitals), to associate a patient with a facility or multiple facilities, and/or to associate a user with one or more patients. In some examples, an index can be based on an ACO. In some examples, the ACO includes one or more healthcare providers across a healthcare continuum and can provide cross-access to patient data/information. In some examples, the intelligent routing sub-component  622  provides intelligent routing functionality, discussed above. 
     In some examples, the data source adapters component  606  provides adapter functionality. In the depicted example, the services component  608  includes a reporting and analytics sub-component  626 , a clinical transformation sub-component  628  and an implementation and support sub-component  630 . 
     As discussed in further detail herein, patient data and patient information can be provided from one or more disparate patient data sources (e.g., examples depicted in  FIG. 5 ). In some examples, a patient can be associated with one or more healthcare services across the healthcare continuum. Consequently, and for each patient, patient data and patient information can be distributed across the healthcare continuum. For example, a patient can be taken to a hospital by EMS (e.g., ambulance), can be treated in an emergency department of the hospital (e.g., ER), can stay in the hospital on an inpatient basis, can frequent a rehabilitation center (e.g., physical therapy), can be undergoing home healthcare (e.g., home nursing care), and patient samples can be sent to a laboratory for analysis (e.g., blood analysis provided by an external laboratory). In this example, treatment of the particular patient touches multiple facilities across the healthcare continuum, and each facility can generate its own patient data, patient information and patient records (EMRs). 
     In general, an EMR can be described as a digital medical record provided as an electronic document that can be processed (e.g., read from/written to) by one or more computer programs executed by one or more computing devices. Further, each entity or organization (e.g., clinic, hospital, physician, rehabilitation center, laboratory) that treats a patient can include its own, stand-alone information system that provides an EMR that is specific to the information system. Consequently, multiple, disparate EMRs can be provided for a single patient across the healthcare continuum. Within the context of the example above, a first EMR can be provided for the patient by an ambulance service that transported the patient to the hospital, a second EMR can be provided for the patient by the hospital, a third EMR can be provided for the patient by the rehabilitation center and a fourth EMR can be provided for the patient by a nursing company that is providing home nursing care to the patient. In some examples, and as noted above, EMRs can be generated from disparate information systems. Consequently, format and syntax of one EMR can be different from the format and syntax of another EMR. 
     In some examples, historical patient data and information can be provided for viewing by a healthcare provider, as well as providing real-time patient data for viewing to the healthcare provider. Extending the example above, the patient can be re-admitted to the hospital on an inpatient basis and can be connected to one or more patient monitoring devices that generate patient physiological data based on patient physiological activity. In accordance with implementations of the present disclosure, and as discussed in further detail herein, patient data and information from one or more of the first EMR, the second EMR, the third EMR and the fourth EMR, as well as real-time patient data can be provided for display to a healthcare provider (e.g., a physician attending to the patient) on a mobile device in an integrated and unified manner. For example, real-time and/or historical patient physiological data can be provided for display by multiple products (e.g., a cardiology product and a patient monitoring product). Implementations of the present disclosure enable integration and unification of the patient physiological data across the products. 
     In accordance with implementations of the present disclosure, patient data can be displayed to a user of a computing device. In some implementations, the user provides log-in credentials to an application that is executed on the mobile device. For example, the application can open and can provide a log-in screen for the user to provide credentials. In some examples, the credentials can include a personal identification number (PIN). If the PIN is not authenticated (e.g., the user-input PIN is not the same as a pre-stored PIN), an error is displayed. If the PIN is authenticated (e.g., the user-input PIN is the same as a pre-stored PIN), a sites screen or a base screen can be displayed. In some examples, authentication can be provided based on a personal identifier (e.g., the PIN) and another identifier. In some examples, another identifier can include an identifier that is unique to a mobile device that the user is using. For example, the PIN and a unique device identifier can be provided for authentication. 
       FIG. 7  depicts an example sites screen  700 . In some implementations, the sites screen  700  provides a GUI including one or more site icons that can be selected (e.g., clicked on) by the user. In some examples, a site can include a specific facility (e.g., hospital clinic), a system of facilities (e.g., a hospital system including one or more hospitals, one or more clinics, and/or one or more laboratories, and the like). In some examples, an index (e.g., a user-facility index) can be accessed based on an identifier associated with the user, to determine the one or more site icons that are to be displayed to the user. In some examples, in response to the PIN being authenticated, an identifier associated with the user can be provided to the DMS  160 ′, for example, by the mobile device  102  (see  FIGS. 1 and 2 ). In some examples, the DMS  160 ′ stores an index (e.g., a user-facility index) that is accessed based on the identifier. In some examples, the index maps the identifier associated with the user to one or more facilities that the user is associated with. In response, the DMS  160 ′ provides instructions to the mobile device  102  to display the sites screen  700  including the one or more site icons  702 ,  704 ,  706 ,  708 ,  710 ,  712 ,  714 ,  716 , each site icon being a graphical representation of a facility of facilities that the user is associated with. 
     In some implementations, and as noted above, the user can be associated with more than one site (e.g.,  702 ,  704 ,  706 ,  708 ,  710 ,  712 ,  714 ,  716 ). In some implementations, the user is affiliated with a single site, which is included in a network that includes a plurality of inter-communicating sites associated therewith. In some examples, a site can include a medical center, a dispensary, a hospital, an infirmary, a surgery center, an ambulatory setting, a nursing home, a rest home, a sanatorium, a sanitarium, or any other appropriate healthcare facility. In some implementations, the site screen  700  can provide a summary of each site and/or specific sites, with which the user is associated. In some examples, a site summary can include a plurality of selectable icons (e.g. a site access icon, a site information icon, a patient information icon, etc.). In some implementations, each site summary can include attributes (e.g. patient counts). 
     User input can be provided to the site screen  700 , the user input indicating a selection of a site icon of the one or more site icons. In some examples, user input can include touching of a touchscreen display with a digit (e.g., finger), a stylus, and/or other pointing device, as well as with a digital cursor and/or a keypad. 
     In some implementations, a base screen can be displayed. In accordance with implementations of the present disclosure, and as discussed in further detail herein, the base screen can include a menu. In some examples, the menu provides a GUI, through which the user can request display of patient data/information. In some examples, the menu is a user-specific menu. In some examples, the menu is specific to one or more user contexts. In some examples, the menu is specific to a site selected by the user. In some examples, the base screen is displayed in response to the PIN being authenticated. In some examples, the base screen is displayed in response to user input to the sites screen. 
     In accordance with implementations of the present disclosure, the menu is provided as a slide-out menu that is animated in response to user selection of an icon. In some examples, the menu can be animated such that the menu appears to slide-out from an edge of the base screen (e.g., left-side edge). In some examples, the menu is animated such that the menu appears to slide-in to the edge of the base screen in response to user selection of an icon from the menu. 
     In accordance with implementations of the present disclosure, the menu can include icon groups. In some examples, the icon groups can be provided as default icon groups. For example, a default icon group can be displayed in the menu, the default icon group being agnostic to the particular user (e.g., displayed for any user). In some examples, the icon groups can include user-customized icon groups. For example, the menu can include a user-customized icon group that is specific to (e.g., that was defined by) the user. In some examples, the icon groups can include user-specific and/or site-specific icon groups. For example, an icon group can include a workflow icon group that is specific to the role of the user (e.g., an attending physician) at a specific facility. 
       FIG. 8  illustrates an example screen-shot of a base screen  800  that includes a menu  802 . The example base screen  800  of  FIG. 8  is user-specific and site-specific. For example, the base screen  800  can be displayed in response to user selection of a site icon (e.g., the site icon  704  of  FIG. 7 ). Consequently, a site identifier  816  can be provided to indicate the site, to which the menu  802  is specific. In some examples, a request for the base screen is provided to the DMS  160 ′ in response to user selection of an icon from the sites screen  700 . In some examples, the request indicates the site that was selected. In some examples, a user-facility index can be accessed to determine a configuration of a menu to be displayed in the base screen. For example, and for a given site (facility), the user can have an associated profile, user-defined patient groups, context-specific workflows and/or facility-specific workflows. Consequently, the DMS  160 ′ can provide instructions for displaying a user-specific, site-specific base screen, such as the example base screen  800  of  FIG. 8 . More particularly, the instructions can include instructions for displaying a user-specific, site-specific menu  802  for the base screen  800 . 
     In the depicted example, the menu  802  provides icons for initiating respective displays of patient data/information. In the menu  802 , the icons are displayed in icon groups, or menu groups  804   a,    804   b.  It is appreciated that more or fewer icon groups can be displayed. In the example of  FIG. 8 , the icon group  804   a  can be provided as a default icon group. For example, the icon group  804   a  includes icons “My Patients”  806 , “Recently Viewed”  808 , and “Find Patients”  810 . In some examples, the icons  806 ,  808 ,  810  are default icons. That is, for example, the icons  806 ,  808 ,  810  are not specific to the user and/or the facility (e.g., the icons  806 ,  808 ,  810  are displayed regardless of the particular user and/or the particular facility). In some examples, the icon group  804   a  can be customized by the user. For example, the user can define a patient group (e.g., “My Cardio Patients,” “My OB Patients”) and can associate one or more patients with the group. Consequently, an icon that is representative of a user-defined group can be displayed in the icon group  804   a.    
     In the example of  FIG. 8 , the icon group  804   b  can be provided as a user-specific and facility-specific icon group. For examples, the icon group  804   b  can be representative of a workflow (e.g., “Cardio”) associated with the user at the particular facility (e.g., as indicated by the identifier  816 ). Consequently, the icon group  804   a  can include icons that are relevant to the particular workflow. In the depicted example, the icon group  804   b  includes an “In Basket” icon  812  and an “EMS” icon  814 . In some examples, a workflow can include one or more tasks to be performed by the user as part of the user&#39;s role at a particular facility. 
     In some implementations, a request can be provided to the DMS  160 ′ in response to user selection of an icon from the menu  802 . In the example of  FIG. 8 , the user can select the “My Patients” icon  806 . In response, a request can be provided to the DMS  160 ′, the request indicating a request for a list of all patients that the user is associated with. The DMS  160 ′ can provide a response that includes instructions to display a list of all patients associated with the user and can include patient data/information for display. In some examples, and in response to the user selection of the “My Patients” icon  806 , the menu  802  is animated to slide-in to the edge of the screen. 
       FIG. 9  depicts an example historical strip segment viewer  900  in accordance with implementations of the present disclosure. The strip segment viewer  900  can be displayed on a device (e.g., the remote device  102 ) and can enable a user of the device to flip-through graphical representations of a waveform strip segment at different points in time to provide a graphical representation of changes to the particular strip segment over time. In the depicted example, the example waveform segment corresponds to fetal monitoring. As noted above, implementations of the present disclosure are applicable to any type of physiological data, including but not limited to, maternal/fetal heart rate, blood pressure, respiratory, vital signs, electrocardiogram, oximetry, anesthesia waveforms, and/or any other appropriate physiological data. 
     In accordance with the present disclosure, a waveform strip can be split into segments and strip segments can displayed in multiple layers. Example layers can include a primary layer  902 , future secondary layers  902   a,    902   b,    902   c,    902   d  and past secondary layers  902   e,    902   f,    902   g,    902   h . The primary layer  902  depicts a strip segment associated with a particular time interval (t i ). The future secondary layers  902   a,    902   b,    902   c,    902   d  depict strip segments associated with respective time intervals (t i+1 , t i+2 , t i+3 , t i+4 ) that occur later in time than the time interval (t i ). The past secondary layers  902   e,    902   f,    902   g,    902   h  depict strip segments associated with respective time intervals (t i−1 , t i−2 , t i−3 , t i−4 ) that occur earlier in time than the time interval (t i ). 
     In some implementations, the layers can be scrolled forward or backward in time to provide an animation-like flip through of the strip segments. For example, the layers can be scrolled forward in time, such that the primary layer  902  becomes the past secondary layer  902   e,  the future secondary layer  902   a  becomes the primary layer  902 , the future secondary layer  902   b  becomes the future secondary layer  902   a,  and so on. As another example, the layers can be scrolled backward in time, such that the primary layer  902  becomes the future secondary layer  902   a,  the future secondary layer  902   a  becomes the future secondary layer  902   b,  the past secondary layer  902   e  becomes the primary layer  902 , and so on. 
     In some implementations, scrolling of the layers can be provided in response to user input. In some examples, scrolling of the layers can be provided in response to a user swiping action on the touchscreen. For example, a user can swipe the touchscreen in a left-to-right direction to induce scrolling of the layers backward in time. As another example, a user can swipe the touchscreen in a right-to-left direction to induce scrolling of the layers forward in time. 
     In some implementations, animations can be provided and can include a forward animation and a reverse animation. In some examples, the animation can be provided as a slideshow of the strip segments. In some examples, a forward animation can begin with a depiction of the strip segment associated with an initial time period (to) (e.g., the time at which collection of patient data began) in the primary layer. The forward animation can progress with successive depictions of the strip segments scrolling forward in time until the strip segment associated with a final time period (t END ) (e.g., the time at which collection of patient data ended) is depicted in the primary layer. In some examples, a reverse animation can begin with a depiction of the strip segment associated with the final time period (t END ) in the primary layer. The reverse animation can progress with successive depictions of the strip segments scrolling backward in time until the strip segment associated with the initial time period (t 0 ) is depicted in the primary layer. 
     In some examples, historical strip segment viewer mimics the “real” paper strip review, which is standardly used by some healthcare providers, such as in obstetrics interventions. The historical strip segment viewer provides an animated view of the paper strip in digital format, enabling the healthcare provider to historically review the physiological waveforms divided into segments covering equitemporal intervals. 
     In some implementations, the currently viewed physiological waveform segment is centered and it is fully displayed (i.e., in the primary layer), while the waveform segments, which are further in the past or closer to the present, are only partially displayed (i.e., in the secondary layers). 
       FIG. 10  illustrates a “Strip viewer” screen  1000  in accordance with implementations of the present disclosure. More specifically,  FIG. 10  provides an example screenshot of the screen  1000  that can be displayed in response to user selection of one or more icons. In this example, the screen  1000  is user-specific and patient-specific. 
     The screen  1000  includes a display region  1004  and a menu  1006 . The menu  1006  provides icons for displaying respective patient data/information in the display region  1004 . In the depicted example, the menu  1006  includes a “Summary” icon  1008 , a “Vitals” icon  1010 , a “Labs” icon  1012 , a “Medications” icon  1014 , an “Imaging” icon  1016 , a “Documents” icon  1018 , and an “ECGs” icon  1020 . In the depicted example, the icon  1010  is selected. In some examples, in response to user selection of the icon  1010  and a “Monitors” icon  1022 , the display region  1004  displays one or more waveforms and one or more strips, as discussed in further detail herein. 
     In the example of  FIG. 10 , example waveforms correspond to fetal monitoring and include fetal heart rate waveforms, and maternal contraction waveforms. As noted above, implementations of the present disclosure are applicable to any type of physiological data, including but not limited to, maternal contractions/fetal heart rate, blood pressure, respiratory, vital signs, electrocardiogram, oximetry, anesthesia waveforms, and/or any other appropriate physiological data. 
     In the depicted example, a first strip view  1030 , a second strip view  1032  and a waveform view  1034 . The first strip view  1030  depicts a realistic graphical representation of a strip  1040 , and the second strip view depicts a realistic graphical representation of a strip  1042 . In some examples, the strip  1040  and the strip  1042  represent different segments of the same underlying strip. Each strip  1040 ,  1042  depicts waveforms  1044 ,  1046 . In the example context, the waveform  1044  corresponds to a fetal heart rate (e.g., based on data collected from a fetal heart rate monitor), and the waveform  1046  corresponds to maternal contractions (e.g., based on data collected from a contraction monitor). In the depicted example, the strips  1040 ,  1042  provide displayed graph scales. In the example context, scales include beats-per-minute (BPM) for the waveform  1044 , and pressure (e.g., kPa, mmHg) for the waveform  1046 . In some examples, the strips  1040 ,  1042  can include one or more timestamps  1048  indicating an approximate time, at which patient data was recorded by a remote monitoring device. 
     In the depicted examples, the strip  1040  includes a bowed portion  1050  toward the right edge of the screen  1000 . The bowed portion  1050  provides the appearance of an actual strip as it would feed out of a physical monitoring device (e.g., be rolled from a strip roll provided in the monitoring device). In some examples, the strip  1040  can be provided as a real-time strip, such that the strip  1040  is animated to move from right-to-left across the screen  1000  in real-time, as patient physiological data is provided from a remote monitoring device. In such an example, the right-most edge of the strip  1040  (e.g., in the bowed portion  1050 ) provides depicts the most recently received patient data, while the left-most edge of the strip depicts patient data received earlier in time. 
     In the depicted example, the strip  1042  includes a strip stack portion  1052  that depicts a stack of strip segments  1054 . That is, for example, the strip stack portion  1052  provides a realistic depiction of an actual strip that includes folded segments stacked together. Accordingly, the remainder of the strip  1042  (e.g., to the right of the strip stack portion  1052 ) provides a realistic depiction of an actual strip as it is unfolded from a strip stack. In some examples, the strip  1042  can be provided as a historical strip, such that the strip  1042  is animated to move from left-to-right or right-to-left across the screen  1000  in response to user input. More particularly, a user can provide a scrolling gesture to the screen  1000  associated with the strip  1042  (e.g., contact the screen over the strip  1042  and provide a swipe gesture). In response to the scrolling gesture, the strip can be animated to display portions of the waveforms  1044 ,  1046  earlier in time or later in time. In some examples, animated folding and un-folding of strip segments  1054  to or from the strip stack portion  1052  can be provided. For example, in response to user input indicating scrolling of the strip  1042  from left-to-right, the strip  1042  can be animated such that strip segments  1054  unfold from the strip stack portion  1052 . As another example, in response to user input indicating scrolling of the strip  1042  from right-to-left, the strip  1042  can be animated such that strip segments  1054  fold into the strip stack portion  1052 . 
     In view of the foregoing, and in the example context, the strips  1040 ,  1042  individually and collectively provide a realistic depiction of a physical fetal monitoring strip that a healthcare provider would review as it was fed from a patient monitoring device. 
     In the example of  FIG. 10 , the waveform view  1034  depicts waveforms  1060 ,  1062  that respectively correspond to the waveforms  1044 ,  1046  of the strips  1040 ,  1042 . In some examples, the waveform viewer  1034  provides an overall view of waveform data. In some examples, the waveforms  1060 ,  1062  can representative of the extent of the collected patient data, or a portion of the collected patient data. In the depicted example, the waveform viewer includes a scrubber bar  1064  and associated interface element  1066 . In some examples, the scrubber bar  1064  can provide a reference to associate the waveforms  1044 ,  1046  to the waveforms  1060 ,  1062 . In some examples, the user can interact with the interface element  1066  to move the scrubber bar  1064  along the waveforms  1060 ,  1062 . For example, the user can touch the touchscreen over the interface element  1066  and can provide a swiping gesture (e.g., left-to-right, right-to-left). In response to the swiping gesture, the scrubber bar  1064  and the interface element  1066  are moved linearly along the waveforms  1060 ,  1062 . In some examples, and in response to movement of the scrubber bar  1064  and the interface element  1066 , one or both of the strips  1040 ,  1042  correspondingly scroll (e.g., scrolling with animation), as discussed above. 
       FIG. 11  depicts an example process  1100  that can be executed in accordance with implementations of the present disclosure. In some examples, the example process  1100  can be provided in one or more computer-executable programs that can be executed using one or more computing devices (e.g., the mobile device  102  and/or the DMS  160 ,  160 ′). 
     A command to display a waveform strip screen is received ( 1102 ). In some examples, user input is provided to a mobile device, the user input indicating a user command to display a waveform strip screen. Patient data and/or patient information are retrieved ( 1104 ). In some examples, in response to the user input, patient data/information associated with a particular patient is retrieved, and information regarding one or more waveforms is determined. In some examples, retrieved patient-specific specific data and/or waveform information are processed to determine one or more waveforms that are to be displayed. Instructions are provided for displaying the waveform strip screen ( 1108 ). The waveform strip screen is displayed on the mobile device. For example, the mobile device processes the instructions to display the waveform strip screen. In some examples, the waveform strip screen provides a realistic depiction of a physical waveform strip that a healthcare provider would review as it was fed from a patient monitoring device. 
     It is determined whether scrolling has been selected ( 1110 ). In some examples, user input to the waveform strip screen can be determined, the user input indicating scrolling of one or more waveform(s). If it is determined that scrolling has been selected, instructions are provided for animating the waveform strip(s) displayed in the waveform strip screen ( 1112 ), and the example process  1100  loops back. 
     If it is determined that scrolling has not been selected, it is determined whether a new screen is to be displayed ( 1114 ). For example, the user can choose to navigate to a different screen from the timeline screen. If it is determined that a new screen is to be displayed, the new screen is displayed ( 1116 ). If it is determined that a new screen is not to be displayed, the example process  1100  loops back. 
     Implementations of the present disclosure can be provided using digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. In some examples, implementations can be provided one or more computer program products, e.g., a computer program tangibly embodied in a machine-readable storage device, for execution by, or to control the operation of, data processing apparatus, and/or a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. Such a computer program can include modules and/or code segments for executing one or more of the features, aspects and/or implementations provided herein. 
     Operations in accordance with implementations of the present disclosure can be performed by one or more programmable processors executing a computer program product to perform functions by operating on input data and generating output. By way of example, a computer program product can include modules and/or code segments corresponding to each of the method steps, aspects and/or features provided herein. Method steps can also be performed by, and apparatus of the present disclosure can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). 
     Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer can include a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer can also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry. 
     The present disclosure can be implemented in a system including, but not limited to the example systems described herein, which include a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client device, such as the mobile device  102 , having a graphical user interface or a Web browser through which a user can interact with an implementation of the invention, or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. 
     A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. For example, steps of the present disclosure can be performed in a different order and still achieve desirable results. Accordingly, other implementations are within the scope of the following claims.