See. (12) Patent Application Publication (10) Pub. No.: US 2014/ A1. (19) United States. (43) Pub. Date: Sep. 18, M00re et al.

Transcription

1 (19) United tate (12) Patent Application Publication (10) Pub. No.: U 2014/ A1 M00re et al. U A1 (43) Pub. Date: ep. 18, 2014 (54) (71) (72) (73) (21) (22) (60) YTEMI AND METHOD FOR AND DIPLAYING PATIENT DATA Applicant: Airtrip IP Holding, LLC, an Antonio, TX (U) Inventor: tephen Trey Moore, an Antonio, TX (U); Neil R. McQueen, an Antonio, TX (U) Aignee: Airtrip IP Holding, LLC, an Antonio, TX (U) Appl. No.: 14/193,246 Filed: Feb. 28, 2014 Related U.. Application Data Proviional application No. 61/788,233, filed on Mar. 15, Publication Claification (51) Int. Cl. G06O 50/22 ( ) G06Q 10/10 ( ) (52) U.. Cl. CPC... G06O 50/22 ( ); G06Q 10/10 ( ) UPC /2 (57) ABTRACT Implementation are directed to providing a uer of a mobile device acce to patient information and patient phyiological data. Action can include receiving uer input, the uer input indicating a uer command to diplay a tak creen, in repone to the uer input, proceing uer-pecific data to determine one or more patient icon, each patient icon repre enting a time-enitive, patient-aociated tak, and diplay ing the tak creen on the mobile device, the tak creen diplaying one or more patienticon group, each patient icon group including a patient icon of the one or more patient 1CO. 104 Connectivity Interface() Input ee Comm

2 Patent Application Publication ep. 18, 2014 heet 1 of 11 U 2014/ A1 V (5 o. ve v. 16 we' CD CN to. & CD CD P. E.9 C> CD \ i CR 2?h O we w 5 CD CD E 3 a O d &/1] w

3 Patent Application Publication ep. 18, 2014 heet 2 of 11 U 2014/ A1 GN (5 U o w a f NM C) CN Q v. O CN V & re & / t CD Hv C > > u Od CD C O 71 &

4 Patent Application Publication ep. 18, 2014 heet 3 of 11 U 2014/ A1

5 Patent Application Publication ep. 18, 2014 heet 4 of 11 U 2014/ A1

6 Patent Application Publication ep. 18, 2014 heet 5 of 11 U 2014/ A1

7 Patent Application Publication ep. 18, 2014 heet 6 of 11 U 2014/ A1 #709

8 Patent Application Publication ep. 18, 2014 heet 7 of 11 U 2014/ A1

9 Patent Application Publication ep. 18, 2014 heet 8 of 11 U 2014/ A1 ly. O O

10 Patent Application Publication ep. 18, 2014 heet 9 of 11 U 2014/ A1 y. n Cn.

11 Patent Application Publication ep. 18, 2014 heet 10 of 11 U 2014/ A1 we wi d y we o we w V c e

12 Patent Application Publication ep. 18, 2014 heet 11 of 11 U 2014/ A Receive uer input Diplay tak Creen Diplay creen FIG 11

13 U 2014/ A1 ep. 18, 2014 YTEM AND METHOD FOR AND DIPLAYING PATIENT DATA CRO-REFERENCE TO RELATED APPLICATION Thi application claim the benefit of and priority to U.. Proviional Application No. 61/788,233 filed on Mar. 15, 2013, the dicloure of which i exprely incorporated herein by reference in the entirety. BACKGROUND 0002 Patient information can be tored acro multiple facilitie aociated with repective health care provider. For example, healthcare continua can include hopital, clinic, laboratorie, and/or other healthcare facilitie. In ome intance, each healthcare facility had it own data ource for toring patient information and data aociated with ervice provided at the repective facility. For example, multiple, different electronic medical record (EMR) can be provided for a particular patient acro a healthcare continuum. In ome example, uch EMR are vendor-pecific, toring data and information i diparate format Phyician and other healthcare provider may be required to acce patient data and information from acro a healthcare continuum. The diparate nature, in which data and information may be tored, can complicate retrieval and diplay of relevant patient information to healthcare provid C. UMMARY 0004 Implementation of the preent dicloure provide method for providing a uer of a mobile device acce to patient information and patient phyiological data. In ome example, method include action of receiving uer input, the uer input indicating a uer command to diplay a tak creen, in repone to the uer input, proceing uer-pecific data to determine one or more patienticon, each patient icon repreenting a time-enitive, patient-aociated tak, and diplaying the tak creen on the mobile device, the tak creen diplaying one or more patient icon group, each patienticon group including a patient icon of the one or more patient icon. Other implementation of thi apect include correponding ytem, apparatu, and computer program, configured to perform the action of the method, encoded on computer torage device Thee and other implementation can each option ally include one or more of the following feature: the time enitive, patient-aociated tak of each patienticon include a pending tak; action further include, in repone to uer election of a patient icon, diplaying a tak-pecific creen, the tak-pecific creen including patient data and/or patient information aociated with an underlying tak; action fur ther include receiving uer input indicating completion of the time-enitive, patient-aociated tak of a patienticon, and in repone, providing a ignal to a back-end ytem indicating completion of the time-enitive, patient-aociated tak: action further include removing the patient icon from di play in the tak creen; action further include each time enitive, patient-aociated tak i determined to be within a threhold time period; and a time-enitive, patient-aoci ated tak i determined to be within the threhold time period when a difference between a current time and a time aoci ated with the tak i within the threhold time period Other apect of the preent dicloure provide y tem including one or more proceor, and a computer readable medium coupled to the one or more proceor hav ing intruction tored thereon which, when executed by the one or more proceor, caue the one or more proceor to perform one or more of the method provided herein It i appreciated that method in accordance with the preent dicloure can include any combination of the apect and feature decribed herein. That i to ay that method in accordance with the preent dicloure are not limited to the combination of apect and feature pecifically decribed herein, but alo include any combination of the apect and feature provided The detail of one or more implementation are et forth in the accompanying drawing and the decription below. Other feature, object, and advantage will be appar ent from the decription and drawing, and from the claim. DECRIPTION OF DRAWING The patent or application file contain at leat one drawing executed in color. Copie of thi patent or patent application publication with color drawing() will be pro vided by the Office upon requet and payment of the nece ary fee FIG. 1 i a chematic illutration of an example ytem architecture in accordance with implementation of the preent dicloure FIG. 2 i a chematic illutration of another example ytem architecture in accordance with implementation of the preent dicloure FIG. 3 i a functional block diagram of an example ytem in accordance with implementation of the preent dicloure FIG. 4 i a more detailed view of the functional block diagram of FIG FIG. 5 depict an example platform for providing integrated and unified view of patient data and patient infor mation FIG. 6 depict example component and ub-com ponent that can be included in core component of FIG FIG depict example graphical uer interface (GUI) for providing integrated and unified view of patient data and patient information in accordance with implemen tation of the preent dicloure FIG. 11 i a flowchart illutrating an example pro ce that can be executed in accordance with implementation of the preent dicloure Like reference ymbol in the variou drawing indicate like element. DETAILED DECRIPTION Implementation of the preent dicloure are gen erally directed to an enterprie calable, data- and Vendor agnotic mobility architecture to ecurely deliver patient data and information from medical device, electronic medical record (EMR) and patient monitor to healthcare provider anywhere acro a healthcare continuum. More particularly, implementation of the preent dicloure provide integrated and unified view of patient data and patient information on mobile device (e.g., martphone, tablet) from a plurality of data ource acro the healthcare continuum. A dicued in further detail herein, implementation of the preent diclo ure enable timely and collaborative clinical deciion-mak

14 U 2014/ A1 ep. 18, 2014 ing, and enable healthcare ytem to better track quality metric, empower a mobile workforce, expand network, and achieve clinical tranformation Example ytem and method that can be included in implementation of the preent dicloure are provided in U.. Proviional Application er. No. 61/771,591, filed Mar. 1, 2013, the content of which are exprely incorporated herein by reference in the entirety Referring now to FIG. 1, an example ytem archi tecture 100 i illutrated, and include a mobile device 102, connectivity interface() 104, a network 106, a firt facility ytem 108, and a econd facility ytem 110. A dicued in further detail herein, data i tranferred from each of the firt and econd facility ytem 108, 110 through the network 106 and connectivity interface() 104 for preentation, or diplay on the mobile device 102. Further, data can be tranferred from the mobile device 102 through the connectivity interface () 104 and the network 106 to each of the firt and econd facility ytem 108, 110. Although a ingle mobile device 102 i illutrated, it i contemplated that one or more mobile device 102 can communicate with each of the firt and ec ond facility ytem 108, 110 through the network 106 and the connectivity interface() 104. imilarly, although two facility ytem are illutrated, implementation of the preent dicloure can include one or more facility ytem The mobile device 102 can include any number of example device. uch example device include, but are not limited to, a mobile phone, a martphone, a tablet computing device, a peronal digital aitant (PDA), a laptop peronal computer (PC), a dektop PC, and/or appropriate combina tion thereof. In the depicted example, the mobile device 102 include a diplay 122, a proceor 124, memory 126, an input interface 128, and a communication interface 130. The proceor 124 can proce intruction for execution of implementation of the preent dicloure. The intruction can include, but are not limited to, intruction tored in the memory 126 to diplay graphical information on the diplay 122. Example diplay include, but are not limited to, a thin film-tranitor (TFT) liquid crytal diplay (LCD), or an organic light emitting diode (OLED) diplay. The memory 126 tore information within the mobile device 102. In ome implementation, the memory 126 can include a volatile memory unit or unit, and/or a non-volatile memory unit or unit. In other implementation, removable memory can be provided, and can include, but i not limited to, a memory card. Example memory card can include, but are not limited to, a ecure digital (D) memory card, a mini-d memory card, a UB tick, and the like In ome example, the input interface 128 can include a keyboard, a touchcreen, a moue, a trackball, a microphone, a touchpad, and/or appropriate combination thereof. In ome implementation, an audio codec (not hown) can be provided, which receive audible input from a uer or other ource through a microphone, and convert the audible input to uable digital information. The audio codec can generate audible ound. uch a through a peaker that i provided with the mobile device 102. Example ound can include ound from Voice telephone call, recorded ound (e.g., voice meage, muic file, etc.), and/or ound gener ated by application operating on the mobile device The mobile device 102 may communicate wire lely through the communication interface() 104, which can include digital ignal proceing circuitry. The commu nication interface() 104 may provide communication under variou mode or protocol including, but not limited to, GM voice call, M, EM or MM meaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, and/or GPR. uch communication may occur, for example, through a radio frequency tranceiver (not hown). Further, the mobile device can be capable of hort-range communication uing feature including, but not limited to, Bluetooth and/or WiFi tran ceiver (not hown) The mobile device 102 communicate with the net work 106 through the connectivity interface() 104. In ome example, the connectivity interface() 104 can include a atellite receiver, cellular network, a Bluetooth ytem, a Wi-Fi ytem (e.g., 802.x), a cable modem, a DL/dial-up interface, a private branch exchange (PBX) ytem, and/or appropriate combination thereof. Each of thee connectivity interface 104 enable data to be tranmitted to/from the network 106. In ome example, the network 106 can be provided a a local area network (LAN), a wide area network (WAN), a wirele LAN (WLAN), a metropolitan area net work (MAN), a peronal area network (PAN), the Internet, and/or combination thereof In the example ytem of FIG. 1 and 2, the firt facility ytem 108 include a plurality of facilitie 140, and the econd facility ytem 110 include a facility 140. It i contemplated that each facility ytem 108, 110 can include one or more facilitie, and i not limited to the example arrangement decribed herein. In the cae of multiple facili tie, the facilitie can be remotely located from one another, and/or can be located at a common location, or ite (e.g., eparate department in a common (the ame) building). Each facility ytem 108, 110 can be provided a a medical care ytem, for example, which medical care ytem can include one or more hopital, hopital ytem, clinic, phyician office, and the like In ome example, each facility 140 include an aociated information ytem 142, computer interface() 144, and patient monitoring device() 146. Example informa tion ytem can include, but are not limited to, a clinical information ytem (CI), an EMR ytem, an electronic health record (EHR) ytem, and/or a hopital information ytem (HI). Each information ytem 142 can be provided a a erver, and upport the acquiition, torage, modifica tion, and ditribution of clinical information, uch a patient data, throughout the facility 140 and/or facility ytem 108, 110. In ome example, each information ytem 142 can communicate with one or more ancillary information ytem (not hown) that can include, but are not limited to, a phar macy management ytem, a laboratory management ytem, and/or a radiology management ytem. Although the example ytem architecture 100 include an information ytem 142 located at each facility 140, it i contemplated that the facilitie 140 can communicate with a common informa tion ytem 142 that i remotely located from either facility 140, or that i located at one of the facilitie 140 within the facility ytem 108, In ome example, the computer interface 144 can communicate with the information ytem 142 to enable acce to information that i tored within, and managed by the information ytem 142. In ome example, the computer interface 144 can include a peronal computer (PC) (e.g., dektop, laptop, or tablet). Although a ingle computer inter face 144 i illutrated in the example architecture decribed herein, it i contemplated that one or more computer inter face 144 can communicate with the information ytem 142.

15 U 2014/ A1 ep. 18, 2014 Communication between each computer interface 144 and the information ytem 142 can be achieved via a direct connection, or remotely through a network (not hown) that can include, but i not limited to, a LAN, a WAN, a WLAN, and/or the Internet In ome example, each patient monitoring device 146 monitor phyiological characteritic of a particular patient 150, and generate data ignal baed thereon. A dicued in further detail herein, implementation of the preent dicloure provide patient monitoring device that include a computing device. uch a a tablet computing device. The data ignal are communicated to the information ytem 142, which collect patient data baed thereon, and tore the data to a patient record that i aociated with the particular patient. An example patient record can include an electronic medical record (EMR). Although a ingle patient monitoring device 146 i illutrated per each patient 150, it i contemplated that multiple patient monitoring device 146 can monitor a particular patient 150. The patient monitoring device() 146 can communicate with the information ytem 142 via a direct connection, or remotely through a network (not hown) that can include, for example, a LAN, a WAN, a WLAN, and/or the Internet In ome example, the patient data i made available for diplay on the computer device 144. A healthcare provider (e.g., a nure and/or phyician) can augment the patient data by inputting patient information that i alo tored to the information ytem 144. More pecifically, the healthcare provider can input patient information correponding to a particular patient 150, which patient information can be tored to the patient record (e.g., EMR). A one example, a nure can input nuring note, which nuring note can be tored to the patient record in the information ytem. Example patient information can include any non-phyi ological information correponding to a patient (e.g., name, age, date-of-birth (DOB), gender) A dicued above, each information ytem 142 tore patient data that can be collected from the patient monitoring device 146, a well a additional patient infor mation, that can include information that i input by a health care provider. The information ytem 144 communicate the patient data and/or the additional patient data to a data man agement ytem (DM) 160. The DM 160 can be provided a a erver, or a virtual erver, that run erver oftware component, and can include data torage including, for example, a databae and/or flat file. In the example ytem architecture 100 of FIG. 1, each facility ytem 108, 110 include a correponding DM 160. In uch an arrangement, each information ytem 142 communicate patient data, and/or additional patient data to the DM 160. Furthermore, and a dicued in further detail below, the DM 160 can communicate ancillary information to the information y tem 142. Communication between the DM 160 and the information ytem() 142 can be achieved via a direct con nection, or remotely through a network (not hown) that can include, for example, a LAN, a WAN, a WLAN, and/or the Internet In ome example, a DM 160 correponding to a particular facility ytem can be remotely located from any of the facilitie 140 of the facility ytem 108, 110, or can be located at a particular facility 140 of the facility ytem 108, 110. In the example ytem architecture 100 of FIG. 1, the DM 160 i remotely located from either facility 140 within each of the facility ytem 108, 110. It i contemplated, however, that the DM 160 can be located at one of the facilitie 140, and remote from the other facility In the example ytem architecture 100' of FIG. 2, a DM 160' i provided that i common to (the ame for) the facility ytem 108, 110. For example, the DM 160' can be decribed a being common to variou facility ytem 108, 110, and i not aociated with a particular facility ytem 108, 110. For example, the DM 160' can be hoted by a third-party vendor (e.g., a cloud ervice provider). In ome example, each information ytem 42 communicate with the DM 160" via a direct connection, or remotely through a network (not hown) that can include, but i not limited to, a LAN, a WAN, a WLAN, and/or the Internet. In the example arrangement of FIG. 2, the DM 160 communicate with each of the information ytem 142 through the network 106. The information ytem 142 communicate patient data and/ or patient information to the DM 160', and the DM 160' can communicate ancillary information to the information y tem 142, a dicued in further detail below In the example ytem architecture 100 of FIG. 1, the facility 140, or facility ytem 108, 110 intall the DM 160 a a local DM, and the DM 160 it at the local ite with other erver that can include, for example, the information ytem 142. In ome implementation, the DM 160 can be ectioned off, or eparated from a logical network perpec tive, but till phyically exit with the other erver that belong to the repective facility 140. In ome example, erver component are intalled on the DM 160, which component can include, for example, a databae component, a databae ynchronization component, a web ervice com ponent, and/or a tructured query language (QL) compo nent. An information ytem interface can alo be intalled on the DM 160, and function a the interface to the informa tion ytem 142. A one example, the information ytem interface can include OBLink, provided by GE Healthcare. In ome implementation, the DM 160 can be arranged in a multiple erver configuration, in which one erver only hot web ervice related component and i logically egregated, and another erver ha the remaining neceary erver com ponent intalled The example ytem architecture 100' of FIG. 2, provide for the remote location of data collection at the DM 160'. In uch implementation, the DM 160' can be provided at a third-party ite, remote from any of the facilitie 140, or facility ytem 108, 110. The third-party function a a DM hot, and the neceary erver component are intalled on the remotely hoted DM 160'. In ome implementation, a bui ne-to-buine (B2B) virtual private network (VPN) can be created between the remotely hoted DM 160' and the net work of the facility 140 or facility ytem 108, 110. In thi manner, the facility 140 and/or facility ytem 108, 110 for goe the purchae and/or maintenance of another phyical erver, or DM 160. Further, the up-time and the tatu of availability of the DM 160" are eaier to manage on the part of a dedicated third-party. The DM acce to the network can be attended to by the third-party, a oppoed to burdening the facility 140, or the facility ytem 108, 110. Further, the third-party can implement virtual erver technologie to leverage multiple DM intallation on a ingle phyical erver. In uch implementation, a plurality of virtual erver are logically partitioned in a ingle phyical erver, and each virtual erver ha the capability of running it own operating ytem and erver component, and can be independently booted.

16 U 2014/ A1 ep. 18, In accordance with implementation of the preent dicloure, the DM 160, 160' ynchronize and tranfer data between the mobile device 102, or multiple mobile device 102, and the information ytem 142, or multiple information ytem 142. More pecifically, the DM 160, 160" procee and prepare the patient data and/or patient information for tranfer to and preentation on the mobile device 102, or multiple mobile device 102, from the infor mation ytem 142, and/or other ytem, a dicued in further detail herein. The DM 160, 160' alo procee and prepare ancillary information for tranfer to and torage in the information ytem 142 from the mobile device 102, or multiple mobile device 102 for potential preentation at a correponding computer device 144. Example DM can include, but are not limited to, the Airtrip erver provided by Airtrip Technologie, LLC, which Airtrip erver include Airtrip erver Component intalled therein Referring now to FIG. 3 and 4, example module tructure, or ytem 300 that can be implemented to provide feature of the preent dicloure will be decribed in detail. In ome example, the example ytem 300 enable patient data and patient information to be communicated to/from, and to be exchanged between mobile device and data ource acro healthcare continua. In ome example, each module can be provided a one or more computer-executable pro gram that are executed uing one or more computing device (e.g., computing device provided a part of a DM, comput ing device located at one or more facilitie of a facility ytem) FIG.3 illutrate an overview of the example ytem 300. In the depicted example, the module tructure include module located at a DM 301, a firt facility ytem 302 and a econd facility ytem 304. In ome example, the firt facility ytem 302 and the econd facility 304 can be included in at leat a portion of a healthcare continuum, dicued in further detail herein. The facility ytem 302 include apatient record module 303 (e.g., EMR module) that accee one or more patient record managed and tored by the facility ytem 302. The facility ytem 304 include a patient record module 305 (e.g., EMR module) that accee one or more patient record managed and tored by the facil ity ytem In the depicted example, and a dicued in further detail herein, patient data and/or information can be provided for integrated and unified diplay on the mobile device 102 through the network 106 and the DM 301 from acro healthcare continua (e.g., the facility ytem 302, 304). In ome example, patient data and/or information can be pro vided for diplay on a mobile device 102', 102" through the network 106 from a facility ytem (e.g., the facility ytem 302, 304). In ome example, the mobile device 102, 102'. 102" are the ame device. That i, for example, a mobile device can receive patient data and/or information from acro a healthcare continuum, and/or from individual facility ytem In ome implementation, the DM 301 include a web module 310, a hot module 312, a data cache module 314 and an adapter module 316, web module 320, a hot module 322, a data cache module 324, a collector module 326. In general, module of the DM 301 enable the DM 301 to retrieve and combine data from multiple facility ytem (e.g., the facility ytem 302, 304) acro healthcare con tinua. In ome example, the web module 310 provide a firt-level network facing interface to the DM infratructure. In ome example, and in repone to a requet from a mobile device (e.g., the mobile device 102), the web module 310 perform requet validation and uer authentication and route the requet to the hot module 312. In ome example, the web module 310 include one or more ub-module. Example ub-module include a requet validation ub-mod ule, which validate received requet, a uer authentication module, which authenticate an identity of the uer and/or mobile device from which a requet i received, and a requet routing ub-module, which route requet after validation and authentication In ome implementation, the hot module 312 orchetrate requet proceing. In ome example, the hot module 312 include one or more ub-module. Example ub-module include a requet paring ub-module that pare received requet, a pipeline aembly ub-module, a pipeline proceing ub-module, an operation execution ub module, a data acce ub-module, a reult formatting ub module, an acce control ub-module, an encryption ub module, a data conditioning ub-module, and a logging ub module. In ome example, the hot module 312 parer a received requet (e.g., uing the requet paring ub-module) to determine, for example, what type of device iued the requet, which application executing on the device iued the requet, and/or patient data/information (or other data uch a analytical data, dicued below) i needed to fulfill the requet. In ome example, and baed on the pared informa tion, the hot module 312 build a pipeline (e.g., uing the pipeline aembly ub-module). In ome example, a pipeline can be provided a a lit of tak that need to be executed to fulfill the requet. Example tak can include retrieving par ticular patient data/information, proceing retrieved patient data to generate additional data and/or data viualization (e.g., analytical data, trend graph, dicued below), encrypting/decrypting retrieved data, performing acce con trol to retrieve data, generating log of tak In ome implementation, the hot module 312 coordinate data retrieval with the data cache module 314 (e.g., uing the data acce ub-module). The retrieved data i provided back to the hot module 312. In ome example, the hot module 312 procee the retrieved data (e.g., uing the operation execution ub-module, the reult formatting ub module and/or the data conditioning ub-module). In ome example, the retrieved data i proceed to generate addi tional data (e.g., data ued for data viualization). In ome example, the retrieved data and/or the additional data are conditioned to provide efficient tranfer back to the requet ing mobile device. In ome example, conditioning can include converting databaed on tranmiion protocol, for matting data for optimal diplay on the particular device, and/or packaging data to end to the requeting device In ome implementation, the data cache module 314 enable acce to and optional torage of detailed patient data/information ued by other component of the ytem 300. In ome example, the data cache module 314 include one or more ub-module and/or data tore. An example ub-module can include a cache ervice ub-module. In ome example, the data cache module 314 can operate in a pa-through mode (real-time mode) and a repoed mode. In ome example, patient data/information required to atify a given requet can be directly acceed from a ource ytem (e.g., the facility ytem 302, 304) in real-time. In uch example, the data cache module 314 operate in a pa through mode, retrieving the patient data/information from

17 U 2014/ A1 ep. 18, 2014 multiple data ource and paing the patient data/informa tion onward for reponding to the requet. In ome example, an application program interface (API), or other program matic mechanim can be ued to retrieve the patient data/ information. In ome example, in the pa-through mode, patient data/information i not tored in a peritent data tore acceed by the data cache module 314. In ome implemen tation, it might be deired to improve retrieval performance. Conequently, the data cache module 314 can tore data iden tifier and/or pointer in a peritent data tore. When in the pa-through mode, the data cache module 314 ue the adapter module 316 to perform the actual retrieval of patient data/information from one or more facility ytem In ome example, the patient data/information that i required to atify a requet cannot be directly acceed from the facility ytem (e.g., the facility ytem 302,304). In uch example, the data cache module 314 operate in the repoed mode. In ome example, in the repoed mode, the data cache module 314 tore a detailed copy of the patient data/information in the peritent data tore. That i, for example, tored patient data/information i tored at the DM-level, but had been retrieved from remote data ource (e.g., data ource located at the facility ytem 302,304). In ome example, when a requet i made for patient data/ information in the repoed mode, the patient data/information i retrieved directly from the peritent data tore (e.g., by the cache ervice ub-module) In ome implementation, the adapter module 316 enable the retrieval of patient data/information from acro healthcare continua. Conequently, the adapter module 316 can be referred to a a federated adapter module. In ome example, in repone to receiving a requet from the mobile device 102 for patient data/information from multiple data ource (e.g., the facility ytem 302, 304), the data cache module 314 utilize the adapter module 316 to retrieve the requeted patient data/information from the multiple data ource. In ome example, the adapter module 316 commu nicate with local hot module (dicued in further detail below) of the repective facility ytem In ome implementation, the requet proceing operation of the DM 301 i tatele. More particularly, the module of the DM 301 handle each received requet a a ditinct unit and, once a requet i handled, tore no tate information aociated with a completed requet. In other word, after the DM 301 ha proceed a requet, the DM 301 (e.g., module within the DM 302 that handled the requet) forget that the requet even occurred. In thi man ner, ubequently received requet are not influenced by (e.g., handled baed on) previouly proceed requet In ome example, operation of the DM 301 i tatele, but the DM 301 can till provide a log of requet handled (e.g., uing the logging ub-module). For example, a requet log can be acceed during an audit of the ytem In ome implementation, each facility ytem 302, 304 include one or more local web module 320,330, one or more local hot module 322, 332, one or more local data cache module 324,334, and one or more vocabulary ervice module 328,338. In the depicted example, the facility y tem 302 include one or more collector module 326, and the facility ytem 304 include one or more patient record (EMR) adapter module In ome example, each of the web module 320, 330 provide functionality a imilarly dicued above with repect to the web module 310. More particularly, the web module 320, 330 operate at a local level (e.g., local to the repective facility ytem 302, 304), each performing requet validation and uer authentication, and routing requet to the repective local hot module 322, 332. For example, the web module 320,330 can receive requet from the repective mobile device 102', 102", can validate the requet and authenticate the repective uer/mobile device, and route the requet accordingly. In ome example, each web module 320, 330 include one or more ub-module. Example ub-module include a requet Vali dation ub-module, which validate received requet, a uer authentication module, which authenticate an identity of the uer and/or mobile device from which a requet i received, and a requet routing ub-module, which route requet after validation and authentication In ome example, each of the local hot module 322,332 provide functionality a imilarly dicued above with repect to the hot module 312. More particularly, the local hot module 322,332 operate at a local level (e.g., local to the repective facility ytem 302,304), each orchetrat ing requet proceing. In ome example, the local hot module 322,332 orchetrate requet proceing for requet received from the mobile device 102 through the DM 301, and/or from the repective mobile device 102', 102" through the repective local web module 320, 330. In ome example, each local hot module 322, 332 include one or more ub-module. Example ub-module include a requet paring ub-module that pare received requet, a pipeline aembly ub-module, a pipeline proceing ub-module, an operation execution ub-module, a data acce ub-module, an acce control ub-module and an encryption ub-module In ome example, each of the local data cache mod ule 324, 334 provide functionality a imilarly dicued above with repect to the data cache module 314. More par ticularly, the local data cache module 324, 334 operate at a local level (e.g., local to the repective facility ytem 302, 304), each enabling acce to and optional torage of detailed patient data/information ued by other component of the ytem 300. In ome example, the each data cache module 324, 334 can operate in a pa-through mode and a repoed mode, a dicued above with repect to the data cache module 314. In the pa-through mode, the local data cache module 324, 334 retrieve the patient data/information from one or more local data ource and paed the patient data/ information onward for reponding to the requet. In ome example, it might be deired to improve retrieval perfor mance. Conequently, the local data cache module 324,334 can tore data identifier and/or pointer in a peritent data tore. When in the pa-through mode, the local data cache module 324, 334 ue the collector module 326 and the patient record adapter module 336, repectively, to perform the actual retrieval of patient data/information from local data ource() (e.g., the patient record module 303 and the patient record module 305, repectively). In ome example, when in the pa-through mode, the local data cache module 324,334 can write data back to the repective patient record module 303, In ome example, the patient data/information that i required to atify a requet (e.g., from the mobile device 102', 102") cannot be directly acceed from the local data ource (e.g., the patient record module 303, 305). In uch example, each local data cache module 324,334 can operate in the repoed mode. In ome example, in the repoed mode, the local data cache module 324,334 tore a detailed copy of

18 U 2014/ A1 ep. 18, 2014 the patient data/information in the peritent data tore. That i, for example, tored patient data/information i tored at the local level, having been previouly received from local data ource() (e.g., the patient record module 303,305). In ome example, when a requet i made for patient data/informa tion in the repoed mode, the patient data/information i retrieved directly from the peritent data tore (e.g., by the cache ervice ub-module) In ome implementation, the collector module 326 and the adapter module 336 are pecific to the type of patient record module 303,305, repectively. In the example of FIG. 3, the patient record module 303 can be acceed baed on a particular meaging protocol. An example meaging proto col can include the Health Level 7 (HL7) meaging protocol. In ome example, patient data/information provided baed on uch meaging protocol i repoed by the data cache module 324. Conequently, requet for uch data can be fulfilled baed on operation of the data cache module 314 and/or the local data cache module 324 in the repoed mode, a dicued above. In ome example, change to patient record in the patient record module 303 can trigger updating of repoed patient data/information by the data cache mod ule 314, 324. For example, the collector module 326 can automatically receive a meage from the patient record mod ule 303 in repone to a change/updated, triggering updating/ changing of repoed patient data/information In the example of FIG. 3, the patient record module 305 upport programmatic interface (e.g., API) acce. In ome example, patient data/information provided through programmatic interface i paed-through the data cache module 314 and/or the data cache module 334. Conequently, requet for uch data can be fulfilled baed on operation of the data cache module 314 and/or the local data cache module 334 in the pa-through mode, a dicued above. In thi manner, uch patient data/information i not perited by the data cache module 314, Although the example of FIG. 3 depict facility ytem 302, 304 having different type of patient record module 303, 305, it i appreciated that facility ytem can include any appropriate combination of type of patient record module and any number of patient record module (e.g., patient record module 303, 305), and repective adapter module (e.g., module 326,336). Further, although the example of FIG. 3 depict two facility ytem, imple mentation of the preent dicloure are applicable in intance include any number of facility ytem In ome implementation, the vocabulary ervice module 328,338 perform tranlation between the vendor pecific Vocabularie and a tandard Vocabulary. In thi man ner, patient data/information retrieved through the module 303, 305 ue tandard vocabulary to be provided back to the mobile device 102 in a unified manner. For example, the patient record module 303, 305 can each be provided by a repective third-party (e.g., a vendor) and can record data/ information baed on a vocabulary that i pecific to the particular vendor. Conequently, data ource provided from different third-partie can refer to the ame data/information or type of data/information uing different terminology. In ome example, each vocabulary ervice module 328,338 i pecific to a repective patient record module 303, FIG. 4 i a more detailed view of the functional block diagram of FIG. 3, depicting additional component of the example ytem 300. In the depicted example, the DM 301 further include a patient lit import module 400, a patient memberhip portal module 402, a patient matching ervice module 404, a provider management (mgmt) module 406, a patient information data tore 408, and a directory information data tore 410. In ome example, the patient information data tore 408 tore patient demographic infor mation 420, a data pointer cache 422, a patient-to-provider index 424 and a patient-to-facility index 426. In ome example, the directory information data tore 410 tore a facility directory 430, a provider directory 432, and provider to-facility index In ome implementation, the patient lit import module 400 enable initial and ongoing import of patient lit and patient demographic information for patient. In ome example, the patient lit import module 400 provide an interface to receive a patient lit, e.g., provided in a computer readable document, and procee the patient lit to populate the patient information data tore 408 (e.g., the demographic information 420). In ome example, the patient memberhip portal module 402 provide an interface that enable uer (e.g., an adminitrator) to etablih relationhip between patient data/information tored acro healthcare continua and particular patient. In ome example, healthcare provid er, facilitie and/or facility ytem acro healthcare con tinua can be included in a healthcare organization (e.g., an accountable care organization (ACO)). In ome example, the patient memberhip portal module 402 enable a uer to define relationhip between multiple patient record (e.g., baed on repective medical record number (MRN)) to the healthcare organization. In ome example, relationhip information defined through the patient memberhip portal module 402 can be tored in the patient information data tore In ome implementation, the patient matching er vice module 404 can be acceed by the hot module 312 and the patient memberhip portal module 402. In ome example, the patient matching ervice module 404 can be acceed by an application executed on a mobile device (e.g., the mobile device 102) through the hot module 312. In ome example, the patient matching ervice module 404 procee patient data and/or patient information to identify potential patient matche between diparate data ource (e.g., mul tiple, different EMR acro the healthcare continuum). In ome example, patient information aociated with con firmed matche (e.g., confirmed by an adminitrator through the patient memberhip portal module 402, confirmed by a healthcare provider uing a mobile device through the hot module 312) can be tored in the patient information data tore 408. In ome example, a patient matching uer inter face (UI) i provided (e.g., diplayed on a mobile device) and can be ued by a healthcare provider to earch for patient and etablih, record and/or confirm relationhip between patient record in different ytem that are related to a ingle patient In ome example, the demographic information 420 include information that can be ued to identify any patient that ha been etablihed in the ytem. In ome example, the demographic information 420 can be ued to earch for patient, dicued in further detail herein. Example demographic information can include name, age and/or gender. In ome example, the data pointer cache 422 tore identifier aociated with detailed patient data. In ome example, the identifier point to particular data tore, in which to be retrieved patient data/information i tored. In thi manner, retrieval performance (e.g., peed) can be

19 U 2014/ A1 ep. 18, 2014 improved. In ome example, the patient-to-provider index 424 map particular patient to one or more healthcare pro vider, and/or particular healthcare provider to one or more patient. For example, apatient can be treated by a plurality of healthcare provider (e.g., member of a patient care team, dicued below). A another example, a healthcare provider can treat a plurality of patient. In ome example, the patient to-facility index 426 map particular patient to one or more facilitie and/or facility ytem. In ome example, a patient can be mapped to particular facilitie baed on repective MRN of the patient at the repective facilitie. For example, a healthcare continuum for a particular patient can include a hopital and a clinic. In thi example, the patient-to-facility index can map the patient to the MRN of the hopital and the MRN of the clinic In ome implementation, the provider management portal module 406 provide an interface (e.g., web portal) to enable member of a healthcare organization (e.g., ACO) to update healthcare provider directory information and/or healthcare provider-to-facility relationhip. For example, a phyician can be aociated with one or more facility ytem of the healthcare organization and credential (e.g., for log on and/or authentication) can be provided to enable the phyi cian to acce patient data/information provided from the one or more facility ytem In ome example, the facility directory 430 pro vide a directory of the facilitie interfaced to by the ytem (e.g., the DM 301). In ome example, the facility directory 430 alo provide configuration parameter to enable com munication (meaging) between the ytem and computing device aociated with the repective facilitie. In ome example, the provider directory 432 include a directory of healthcare provider (e.g., nure, phyician, pecialit, and the like) that are able to acce patient data/information through the ytem (e.g., the DM 301). In ome example, the provider-to-facility index 434 map each healthcare pro vider (e.g., in the provider directory) to one or more facilitie. For example, a healthcare provider can treat patient at mul tiple facilitie. In ome example, the provider-to-facility index 434 ecurely tore credential of healthcare provider for facilitie that the healthcare provider i mapped to. For example, a healthcare provider can have firt credential for acceing patient data/information at a firt facility, and can have econd credential for acceing patient data/informa tion at a econd facility. In ome example, the provider-to facility index 434 upport ingle ign-on functionality di cued in further detail herein An example data flow will be dicued to illutrate implementation of the preent dicloure. It i appreciated that implementation of the preent dicloure are equally applicable to other data flow. The example data flow can be initiated in repone to a requet received from a mobile device (e.g., the mobile device 102). In ome example, the requet include a uer identifier, a device identifier, a patient identifier, patient data identifier, patient information identi fier and additional data identifier. In ome example, the uer identifier can be ued to determine the particular uer that ha iued the requet, and the device identifier can be ued to determine the particular device that tranmitted the requet. In ome example, the patient identifier identifie the particu lar patient that i the ubject of the requet, the patient data identifier identify the particular patient data that ha been requeted, the patient information identifier identify the par ticular patient information that ha been requeted, and the additional data identifier identify additional data that ha been requeted. For example, the patient data identifier can indicate that patient vital data ha been requeted, and the additional data identifier can indicate that vital alarm data and vital data trend viualization have alo been requeted In the example data flow, the web module 310 receive the requet and procee the requet to validate the requet and to authenticate the uer, who ubmitted the requet (e.g., baed on the uer identifier and/or the device identifier). Upon validation and authentication, the web mod ule 310 provide the requet to the hot module 312. The hot module 312 procee the requet, a dicued above. In ome example, it can be determined that patient data/infor mation required to fulfill the requet can be provided from the data cache module 314 (e.g., repoed mode). In uch example, the patient data/information i provided to the hot module 312 from the data cache module 314. In ome example, it can be determined that that patient data/informa tion required to fulfill the requet i to be retrieved from one or more data ource acro a healthcare continuum of the patient (e.g., federated mode) In ome example, if patient data/information required to fulfill the requet i to be retrieved from one or more data ource acro the healthcare continuum (e.g. fed erated mode), requet information (e.g., aembled by the hot module 312, a dicued above) i provided to the adapter module 316 by data cache module 314. In ome example, the adapter module 316 accee information tored in the directory tore 410 to requet data from one or more facility ytem (e.g., the facility ytem 304). For example, the adapter module 316 can be aware of which facility ytem to retrieve patient data/information from (e.g., baed on the patient-to-facility index 426) and can acce the provider-to-facility index 434 to retrieve uer cre dential for the particular provider (e.g., uer that iued the requet). In thi manner, the adapter module 316 can provide appropriate uer credential to repective facility ytem for patient data/information retrieval In ome example, the adapter module 316 end requet to identified facility ytem, each requet identify ing patient data/information and providing appropriate uer credential. In ome example, repective hot module (e.g., the hot module 332) of the facility ytem receive the requet from the adapter module 316, and can proce the requet a imilarly dicued above with reference to the hot module 312. The repective hot module fulfill the requet and provide the requeted patient data/information back to the adapter module 316. In ome example, the adapter module 316 provide the retrieved patient data/infor mation to the hot module 312, which complete proceing of the requet, a dicued above, and provide a repone to the mobile device that iued the requet A dicued at the outet, the preent dicloure provide a healthcare provider, or uer of the mobile device 102, with ecure, remote acce to patient data and/or patient information. Example patient data can include phyiological data. In ome example, phyiological data can be obtained from patient monitoring device(). In ome example, phyi ological data can be obtained by a local healthcare provider (e.g., a nure, or phyician meauring blood preure, tem perature, heart rate). In ome example, phyiological data can be recorded in one or more patient record (e.g., EMR). In the example cae of a maternity patient, patient data can include delivery progre information uch a cervical exam

20 U 2014/ A1 ep. 18, 2014 tatu, membrane tatu, gravida, para, epidural tatu, and/or whether the patient i attempting a vaginal birth after cearean (VBAC). In ome example, the term patient information refer to information correponding to aparticular patient that i, for example, input into the information ytem 142 by the local healthcare provider. Example patient information can include the patient' name, the name of the doctor() aigned to the patient, the nure() aigned to the patient, a facility identification, a patient bed identification, a ummary of patient data, and/or chart annotation. The term patient infor mation can alo refer to patient information provided from one or more patient record (e.g., EMR) The patient data and/or patient information pro vided to the remotely located uer can be provided a real time data, and/or a hitorical data and information. The patient data and/or patient information i communicated between the mobile device 102 and the DM 160, 160' uing a ecure connection that i etablihed over the network 106. A ecure log-in, or ign-on proce i provided, which i preferably compliant with the proviion of the Health Inur ance Portability and Accountability Act (HIPAA). The ecure ign-on authenticate the identity of the uer of the mobile device 102 baed on a unique uer ID and paword combi nation. Both the uer ID and the paword mut be correct in order to etablih the ecure communication between the mobile device 102 and the DM 160, 160' In ome example, a cenu, or patient lit i pro vided, which capture a variety of the information and/or data decribed herein that i aociated with each of one or more monitored patient 150. trip charting i alo provided, in which patient data and/or information can be preented to the uer in graphical form. In the example cae of a maternity patient, a fetal trip and maternal contraction information can be provided for a particular patient 150. More pecifically, the particular patient 150 i elected from the patient lit, and the patient information and/or data i ubequently preented. The preented information and/or data can include a fetal trip and maternal contraction waveform, the patient name, the hopital name, the patient room and/or bed number, and the date and time. The trip charting can provide a real-time view of the patient data, a well a a hitorical view of the patient data. More pecifically, the waveform diplay can be updated in real-time, uch that the uer of the mobile device 102 oberve the patient data a it occur and/or i recorded. The uer can croll through the waveform diplay, to view hitorical patient data, a decribed in further detail below everal navigation feature can be provided that enable the uer to manipulate a view of the waveform diplay. In ome implementation, the uer can Zoom in/out of the diplayed image. In thi manner, the uer can view very pecific waveform information, and/or other waveform micro-characteritic by Zooming in, for example, and/or can view pattern or other waveform macro-characteritic by Zooming out, for example. In ome implementation, the uer can croll forward or backward through the waveform di play. In thi manner, the uer can view hitorical patient data A patient data diplay can alo be provided. In ome implementation, the patient data diplay can overlay the trip charting decribed herein. In other implementation, the patient data diplay can be provided a an overlay, and/or a a eparate diplay. The patient data diplay can include, but i not limited to, the patient name, age, fetal getation, gravida, parity, cervical exam information, and phyician ac Implementation of the preent dicloure can be realized on any one of a number of operating ytem, or platform 302 aociated with the particular mobile device 102. Example platform include, but are not limited to, RIM Blackberry, Apple io and/or O X, M Pocket PC, Win Mobile (Pocket PC, martphone), Win Mobile (tandard, profeional) and/or any other appropriate platform (e.g., Google Android, and Hewlett-Packard WebO, Microoft Window, Unix, Linux) A dicued in detail herein, implementation of the preent dicloure are directed to ytem and method of providing integrated and unified view of patient data and patient information from diparate data ource and/or prod uct. More particularly, implementation of the preent di cloure provide integrated and unified view of patient data and patient information retrieved from acro a healthcare continuum. In ome example, the healthcare continuum can include a plurality of diparate clinical data ource. In ome example, a clinical data ource can correpond to one or more categorie of healthcare ervice. Example categorie can include emergency medical ervice (EM), outpatient ervice, inpatient ervice, ambulatory ervice, pot-acute ervice, home ervice and tand-alone ervice. Example EM can include emergency department (e.g., emergency room (ER) of a hopital), urgent care facilitie and tranport (e.g., ambulance). Example outpatient ervice and/or inpa tient ervice can include hopital and/or critical acce ho pital (CAH). Example ambulatory ervice can include clinic, phyician group/office, urgery center and pre acute care. Example pot-acute ervice can include killed nuring facilitie, long-term care hopital, rehabilitation center and home healthcare. Example tand-alone ervice can include imaging center (e.g., MIR), oncology center, laboratorie, virtual call center and retail clinic. (0074 FIG.5 depict an example platform 500 for provid ing integrated and unified view of patient data and patient information. The example platform 500 include one or more product application 502 and core component 504. The example platform enable the tranfer of patient data/infor mation to/from one or more data ource 506 for diplay on a mobile device (e.g., the mobile device 102). In ome example, the example platform 500 i provided a one or more computer-executable program that are executed uing one or more computing device (e.g., the DM 160, 160"). Example data ource 506 can include one or more medical device (e.g., bedide monitor), one or more EMR, health information exchange (HIE) data 512, image data 514 (e.g., X-ray data), and enor data In ome implementation, the example platform 500 can include a mobile application platform 520. An example mobile application platform 520 can include the mobile application platform dicloed in U.. application er. No. 13/716,974, filed Dec. 17, 2012, and which claim the benefit of U.. Prov. App. No. 61/579,954, filed Dec. 23, 2011, the dicloure of which are exprely incorporated herein by reference in their entiretie In ome example, the mobile application platform 520 eparate native graphical uer interface (GUI) and oper ating ytem component from the application logic. In thi manner, the mobile application platform 520 tranlate and interpret application logic into the native language of each operating ytem of mobile device to/from which patient data/information i to be tranferred, and embrace the unique propertie, feature, function, and uability of each operating

21 U 2014/ A1 ep. 18, 2014 ytem. In ome implementation, the mobile application platform 520 embodie a template-baed approach, where one or more template are provided, each template corre ponding to a view of patient data/information that i to be preented on a mobile device. In ome example, and a dicued in further detail herein, default template can be provided, which provide default view of patient data/infor mation. In ome example, cutom template can be pro vided, and can include template cutomized by a uer of a mobile device In ome example, the mobile application platform 520 procee patient data/information baed on a template that define a view to be diplayed on the mobile device. In ome example, the mobile application platform 520 gener ate intruction for rendering graphic baed on the patient data/information and the template, and provide intruction to the mobile device, the mobile device executing the intruc tion to provide the template-baed view of the patient data/ patient (e.g., rendering the patient data/information in a view diplayed on the mobile device) In ome example, the product application 502 can include medical oftware application that enable mobility in healthcare. For example, product can enable patient infor mation and patient data (e.g., waveform and other critical data from EMR, bedide monitor and device, pharmacy, lab, and other clinical information ytem) to be ecurely and natively acceed by healthcare provide on mobile device. Example product can include an obtetric (OB) product (e.g., Airtrip OB provided by Airtrip Technologie, LLC), a cardiologiy product (e.g., Airtrip CARDIO provided by Airtrip Technologie, LLC), a patient monitoring product (e.g., Airtrip PATIENT MONITORING provided by Air trip Technologie, LLC), and an EMR extenion product (e.g., Airtrip EMR EXTENDER provided by Airtrip Tech nologie, LLC) FIG. 6 depict example component and ub-com ponent that can be included in the core component 504 of FIG. 5. In ome example, each component and/or ub-com ponent can be provided a one or more computer-executable program that can be executed uing one or more computing device (e.g., computing device of the DM 160, 160' of FIG. 1 and 2). In ome example, the core component provide ecure data acce and data tranport, ingle ign-on and profile/context management, interoperability (data adapter and interface), intelligent meage routing, mater patient indice (e.g., EMPI) and care collaboration In the depicted example, the core component 504 include a ecurity component 600, a care coordination and collaboration interface component 602, a data and workflow integration component 604, a data ource adapter compo nent 606 and a ervice component 608. In the depicted example, the ecurity component 600 include a ingle ign on ub-component 610 and a uer context/profile ub-com ponent 612. In the depicted example, the care coordination and collaboration interface component 602 include a voice ub-component 614, a video ub-component 616 and a me aging ub-component 618. In the depicted example, the data and workflow integration component 604 include a patient index (or indice) component 620 and an intelligent routing ub-component 622. In ome example, the data ource adapter component 606 can include adapter ervice ub component 624 (e.g., the adapter ervice module 324 of FIG.3). In the depicted example, the ervice component 608 include a reporting and analytic ub-component 626, a clinical tranformation ub-component 628 and an imple mentation and upport ub-component In ome example, the ingle ign-on ub-compo nent 610 upport ingle ign-on functionality, dicued herein. In ome example, a uer can be authenticated once (e.g., by providing log-in credential to an application executed on a mobile device) and can be provided acce to data acro a plurality of data ource, without being authen ticated for each data ource individually. In ome example, the uer context/profile ub-component 612 upport uer pecific cutomization baed on a context of the uer and/or a profile of the uer, a dicued in further detail herein. Example context can include the uer being an attending phyician at one hopital and a part-time phyician at another hopital. In ome example, one or more profile can be aociated with the uer, each profile reflecting one or more cutomization aociated with the particular uer. For example, the uer can cutomize a default view that can be diplayed on a mobile device, to provide a cutomized view. Conequently, after the uer i authenticated, one or more uer-defined (uer-cutomized) view can be provided to the mobile device. I0082 In ome example, the care coordination and col laboration interface component 602 upport collaboration between member of a patient care team. For example, patient care team can include a phyician, a conultant, a pecialit, an intenivit and a nure. In ome example, the voice ub-component 614 provide voice-baed collabora tion between care team member (e.g., teleconferencing). In ome example, the video ub-component 616 provide Video-baed collaboration between care team member (e.g., Video conferencing). In ome example, the meaging ub component 618 provide meaging-baed collaboration between care team member (e.g., M/MM text meag ing). In ome example, the care coordination and collabora tion component 602 provide ecurity in remote collaboration between care team member (e.g., ecure teleconferencing, ecure video conferencing and/or ecure meaging). I0083. In ome example, the data and workflow integra tion component 604 integrate data from a plurality of data ource and route data for diplay on mobile device. In ome example, the patient index (or indice) component 620 provide one or more indice for mapping uer to facilitie and/or patient. In ome example, one or more indice can be provided to aociate a uer (e.g., a phyician) with a facility or multiple facilitie (e.g., hopital), to aociate a patient with a facility or multiple facilitie, and/or to aociate a uer with one or more patient. In ome example, an index can be baed on an ACO. In ome example, the ACO include one or more healthcare provider acro a healthcare continuum and can provide cro-acce to patient data/information. In ome example, the intelligent routing ub-component 622 pro vide intelligent routing functionality, dicued above In ome example, the data ource adapter compo nent 606 provide adapter functionality. In the depicted example, the ervice component 608 include a reporting and analytic ub-component 626, a clinical tranformation ub-component 628 and an implementation and upport ub component 630. I0085. A dicued in further detail herein, patient data and patient information can be provided from one or more diparate patient data ource (e.g., example depicted in FIG. 5). In ome example, a patient can be aociated with one or more healthcare ervice acro the healthcare con

22 U 2014/ A1 ep. 18, 2014 tinuum. Conequently, and for each patient, patient data and patient information can be ditributed acro the healthcare continuum. For example, a patient can be taken to a hopital by EM (e.g., ambulance), can be treated in an emergency department of the hopital (e.g., ER), can tay in the hopital on an inpatient bai, can frequent a rehabilitation center (e.g., phyical therapy), can be undergoing home healthcare (e.g., home nuring care), and patient ample can be ent to a laboratory for analyi (e.g., blood analyi provided by an external laboratory). In thi example, treatment of the particu lar patient touche multiple facilitie acro the healthcare continuum, and each facility can generate it own patient data, patient information and patient record (EMR). I0086. In general, an EMR can be decribed a a digital medical record provided a an electronic document that can be proceed (e.g., read from/written to) by one or more computer program executed by one or more computing device. Further, each entity or organization (e.g., clinic, ho pital, phyician, rehabilitation center, laboratory) that treat a patient can include it own, tand-alone information ytem that provide an EMR that i pecific to the information ytem. Conequently, multiple, diparate EMR can be pro vided for a ingle patient acro the healthcare continuum. Within the context of the example above, a firt EMR can be provided for the patient by an ambulance ervice that tran ported the patient to the hopital, a econd EMR can be provided for the patient by the hopital, 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 nuring company that i providing home nuring care to the patient. In ome example, and a noted above, EMR can be generated from diparate information ytem. Conequently, format and yntax of one EMR can be different from the format and yntax of another EMR In ome example, hitorical patient data and infor mation can be provided for viewing by a healthcare provider, a well a providing real-time patient data for viewing to the healthcare provider. Extending the example above, the patient can be re-admitted to the hopital on an inpatient bai and can be connected to one or more patient monitoring device that generate patient phyiological data baed on patient phyiological activity. In accordance with implementation of the preent dicloure, and a dicued in further detail herein, patient data and information from one or more of the firt EMR, the econd EMR, the third EMR and the fourth EMR, a well a real-time patient data can be provided for diplay to a healthcare provider (e.g., a phyician attending to the patient) on a mobile device in an integrated and unified manner. For example, real-time and/or hitorical patient phyiological data can be provided for diplay by multiple product (e.g., a cardiology product and a patient monitoring product). Implementation of the preent dicloure enable integration and unification of the patient phyiological data acro the product In accordance with implementation of the preent dicloure, patient data can be diplayed to a uer of a com puting device. In ome implementation, the uer provide log-in credential to an application that i executed on the mobile device. For example, the application can open and can provide a log-in creen for the uer to provide credential. In ome example, the credential can include a peronal iden tification number (PIN). If the PIN i not authenticated (e.g., the uer-input PIN i not the ame a a pre-tored PIN), an error i diplayed. If the PIN i authenticated (e.g., the uer input PIN i the ame a a pre-tored PIN), a ite creen or a bae creen can be diplayed. In ome example, authentica tion can be provided baed on a peronal identifier (e.g., the PIN) and another identifier. In ome example, another iden tifier can include an identifier that i unique to a mobile device that the uer i uing. For example, the PIN and a unique device identifier can be provided for authentication. I0089 FIG. 7 depict an example ite creen 700. In ome implementation, the ite creen 700 provide a GUI includ ing one or more ite icon that can be elected (e.g., clicked on) by the uer. In ome example, a ite can include a pecific facility (e.g., hopital clinic), a ytem of facilitie (e.g., a hopital ytem including one or more hopital, one or more clinic, and/or one or more laboratorie, and the like). In ome example, an index (e.g., a uer-facility index) can be acceed baed on an identifier aociated with the uer, to determine the one or more ite icon that are to be diplayed to the uer. In ome example, in repone to the PIN being authenticated, an identifier aociated with the uer can be provided to the DM 160', for example, by the mobile device 102 (ee FIG. 1 and 2). In ome example, the DM 160' tore an index (e.g., a uer-facility index) that i acceed baed on the identifier. In ome example, the index map the identifier aociated with the uer to one or more facilitie that the uer i aociated with. In repone, the DM 160" pro vide intruction to the mobile device 102 to diplay the ite creen 700 including the one or more ite icon 702,704,706, 708, 710, 712, 714, 716, each ite icon being a graphical repreentation of a facility of facilitie that the uer i aoci ated with In ome implementation, and a noted above, the uer can be aociated with more than one ite (e.g., 702, 704, 706, 708, 710, 712, 714, 716). In ome implementation, the uer i affiliated with a ingle ite, which i included in a network that include a plurality of inter-communicating ite aociated therewith. In ome example, a ite can include a medical center, a dipenary, a hopital, an infirmary, ur gery center, an ambulatory etting, a nuring home, a ret home, a anatorium, a anitarium, or any other appropriate healthcare facility. In ome implementation, the ite creen 700 can provide a ummary of each ite and/or pecific ite, with which the uer i aociated. In ome example, a ite ummary can include a plurality of electable icon (e.g. a ite acce icon, a ite information icon, a patient information icon, etc.). In ome implementation, each ite ummary can include attribute (e.g. patient count). (0091) Uer input can be provided to the ite creen 700, the uer input indicating a election of a ite icon of the one or more ite icon. In ome example, uer input can include touching of a touchcreen diplay with a digit (e.g., finger), a tylu, and/or other pointing device, a well a with a digital curor and/or a keypad In ome implementation, a bae creen can be di played. In accordance with implementation of the preent dicloure, and a dicued in further detail herein, the bae creen can include a menu. In ome example, the menu provide a GUI, through which the uer can requet diplay of patient data/information. In ome example, the menu i a uer-pecific menu. In ome example, the menu i pecific to one or more uer context. In ome example, the menu i pecific to a ite elected by the uer. In ome example, the bae creen i diplayed in repone to the PIN being authen ticated. In ome example, the bae creen i diplayed in repone to uer input to the ite creen.

23 U 2014/ A1 ep. 18, In accordance with implementation of the preent dicloure, the menu i provided a a lide-out menu that i animated in repone to uer election of an icon. In ome example, the menu can be animated uch that the menu appear to lide-out from an edge of the bae creen (e.g., left-ide edge). In ome example, the menu i animated uch that the menu appear to lide-into the edge of the bae creen in repone to uer election of an icon from the menu In accordance with implementation of the preent dicloure, the menu can include icon group. In ome example, the icon group can be provided a default icon group. For example, a default icon group can be diplayed in the menu, the default icon group being agnotic to the par ticular uer (e.g., diplayed for any uer). In ome example, the icon group can include uer-cutomized icon group. For example, the menu can include a uer-cutomized icon group that i pecific to (e.g., that wa defined by) the uer. In ome example, the icon group can include uer-pecific and/or ite-pecific icon group. For example, an icon group can include a workflow icon group that i pecific to the role of the uer (e.g., an attending phyician) at a pecific facility FIG. 8 illutrate an example creen-hot of a bae creen 800 that include a menu 802. The example bae creen 800 of FIG. 8 i uer-pecific and ite-pecific. For example, the bae creen 800 can be diplayed in repone to uer election of a ite icon (e.g., the ite icon 704 of FIG. 7). Conequently, a ite identifier816 can be provided to indicate the ite, to which the menu 802 i pecific. In ome example, a requet for the bae creen i provided to the DM 160' in repone to uer election of an icon from the ite creen 700. In ome example, the requet indicate the ite that wa elected. In ome example, a uer-facility index can be acceed to determine a configuration of a menu to be di played in the bae creen. For example, and for a given ite (facility), the uer can have an aociated profile, uer-defined patient group, context-pecific workflow and/or facility pecific workflow. Conequently, the DM 160' can provide intruction for diplaying a uer-pecific, ite-pecific bae creen, uch a the example bae creen 800 of FIG.8. More particularly, the intruction can include intruction for di playing a uer-pecific, ite-pecific menu 802 for the bae creen In the depicted example, the menu 802 provide icon for initiating repective diplay of patient data/infor mation. In the menu 802, the icon are diplayed in icon group, or menu group 804a, 804b. It i appreciated that more or fewericon group can be diplayed. In the example of FIG. 8, the icon group 804a can be provided a a default icon group. For example, the icon group 804a include icon My Patient' 806, Recently Viewed 808, and Find Patient' 810. In ome example, the icon 806, 808, 810 are default icon. That i, for example, the icon 806, 808, 810 are not pecific to the uer and/or the facility (e.g., the icon 806, 808, 810 are diplayed regardle of the particular uer and/or the particular facility). In ome example, the icon group 804a can be cutomized by the uer. For example, the uer can define a patient group (e.g., My Cardio Patient. My OB Patient') and can aociate one or more patient with the group. Conequently, an icon that i repreentative of a uer defined group can be diplayed in the icon group 804a In the example of FIG. 8, the icon group 804b can be provided a a uer-pecific and facility-pecific icon group. For example, the icon group 804b can be repreentative of a workflow (e.g., Cardio') aociated with the uer at the particular facility (e.g., a indicated by the identifier 816). Conequently, the icon group 804a can include icon that are relevant to the particular workflow. In the depicted example, the icon group 804b include an In Baket' icon 812 and an EM' icon 814. In ome example, a workflow can include one or more tak to be performed by the uer a part of the uer' role at a particular facility In ome implementation, a requet can be provided to the DM 160" in repone to uer election of an icon from the menu 802. In the example of FIG. 8, the uer can elect the My Patient' icon 806. In repone, a requet can be pro vided to the DM 160', the requet indicating a requet for a lit of all patient that the uer i aociated with. The DM 160" can provide a repone that include intruction to di play a lit of all patient aociated with the uer and can include patient data/information for diplay. In ome example, and in repone to the uer election of the My Patient' icon 806, the menu 802 i animated to lide-into the edge of the creen Implementation of the preent dicloure enable remote execution of patient-aociated tak. In ome example, patient-aociated tak can be time enitive. For example, review and confirmation of a patient ECG by a cardiologit can be required to be executed within a pre determined time period. Although review and confirmation of a patient ECG will be ued herein a an example patient aociated tak, it i contemplated that implementation of the preent dicloure are applicable to other appropriate patient aociated tak. In ome example, if a patient-aociated tak i not executed within the pre-determined time period aociated cot will not be reimbured (e.g., by a health inurance provider, by government adminitered program). Conequently, implementation of the preent dicloure pro vide time-enitive, patient-aociated tak for diplay on mobile device, and enable uer to remotely execute uch tak, a dicued in further detail herein In ome implementation, information aociated with one or more patient-aociated tak can be provided from one or more back-end ytem (e.g., ECG management ytem, perinatal ytem, patient intake ytem, any appro priate clinical information ytem). In the example context, ECG information can be provided from an ECG management ytem. In ome example, patient-aociated tak that are within the pre-determined time period are diplayed to a uer of a mobile device. In ome example, an initial timetamp of a patient-aociated tak can be compared to a current time. In ome example, if a difference between the current time and the initial timetamp i below a threhold time (e.g., the pre-determined time period), a graphical repreentation of the patient-aociated tak i diplayed to the uer. In the example context, it can be provided that an ECG mut be reviewed and confirmed within 24 hour of the ECG having been taken. Conequently, if a difference between a current time, and the time at which the ECG wa taken exceed a threhold time (e.g., 24 hour), a graphical repreentation of the patient aociated tak i not diplayed to the uer In ome implementation, graphical repreentation of time-enitive, patient-aociated tak can be diplayed to the uer in a firt Tak' creen (firt creen). In ome example, the firt creen diplay graphical repreentation of patient-aociated tak that are till within the pre-deter mined time period. In ome example, the firt creen exclu ively diplay graphical repreentation of patient-aoci ated tak that are till within the pre-determined time period.

24 U 2014/ A1 ep. 18, 2014 In ome implementation, graphical repreentation of time enitive, patient-aociated tak can be diplayed to the uer in a econd "Tak' creen (econd creen). In ome example, the econd creen diplay graphical repreenta tion of patient-aociated tak that are already outide of the pre-determined time period. For example, although a patient aociated tak wa not completed within the pre-determined time period, the patient-aociated tak i till indicated to the uer, uch that the patient-aociated tak can till be executed by the uer. In ome example, the econd creen diplay graphical repreentation of patient-aociated tak that are outide of the pre-determined time period. In ome example, the econd creen diplay graphical repreentation of patient-aociated tak that are till within the pre-deter mined time period, and graphical repreentation of patient aociated tak that are outide of the pre-determined time period In ome implementation, and a depicted below with reference to FIG. 9 and 10, the uer can perform patient-aociated tak on the mobile device. In ome example, in repone to the uer performing a patient-ao ciated tak, a ignal and/or data can be provided to a back-end ytem. In thi manner, the back-end ytem can record when the patient-aociated tak wa executed and/or determine whether the patient-aociated tak wa completed with the pre-determined time period. (0103 FIG. 9 and 10, dicued in further detail below, depict an example context for remote diplay and execution of time-enitive, patient-aociated tak. The example con text include reviewing and confirming one or more pending ECG. In ome example, requet and/or ECG information can be provided from an appropriate information ource (e.g., an ECG management ytem) FIG. 9 illutrate an example creenhot of a Time enitive Tak' creen 900 that can be diplayed in repone to uer election of a "Cardiology' icon in a bae creen, and a time-enitive icon. In thi example, the creen 900 i uer pecific and ite-pecific (e.g., pecific to General Hopital), and include a menu 902 that provide icon for initiating repective diplay of location map and patient data/infor mation. In the example menu 902, Recently Viewed' icon 904, a My Patient' icon 906, a Conult' icon 908, a Cardiology icon 910, an OB' icon 912, a Location' icon 914, and a Find Patient' icon 916. The creen 900 further include a time-enitive icon In the depicted example, the icon 910 and the icon 920 are elected. Conequently, graphical repreentation of time-enitive, patient-aociated tak are diplayed. More particularly, the creen 900 provide icon group 922, 924, each icon group 922,924 including one or more patienticon 930 that repreent a time-enitive, patient-aociated tak. For example, the patient icon 930 repreent time-enitive, patient-aociated tak that are till within a pre-determined time period. In the depicted example, the a pre-determined time period include 23 hour, indicating that each patient aociated tak ha been initiated within the lat 23 hour and till need to be completed. In ome example, a drop-dead time period can be provided and can be greater than the pre-determined time period. For example, a drop-dead time period can include 24 hour, while the pre-determined time period include 23 hour. In ome example, the drop-dead time period can be a time period that, if exceeded, provide an advere reult (e.g., non-reimburement for the cot of the underlying ECG). In ome example, the pre-determined time period provide an indication of how cloe time-eni tive, patient-aociated tak are to reaching the drop-dead time period In the example of FIG.9, the patient icon 930 each include patient information and patient data. The example patient information can include patient name, the patientgen der, an identifier aociated with the patient, an ECG um mary, and/or patient date of birth (DOB). It i appreciated that implementation of the preent dicloure can include addi tional and/or other patient data/information in a patient icon. In ome example, the patient data/information provided in the patient icon 930 can include recorded patient data/infor mation. In ome example, the patient data/information pro vided in the patient icon 930 can include real-time patient data/information. For example, a patient icon 930 can be repreentative of a patient that i currently being monitored by one or more patient monitoring device (e.g., a depicted in FIG. 1 and 2), and the patient data diplayed in the patient icon 930 can be updated in real-time baed on data provided from the monitoring device() In the depicted example, the icon group are ao ciated with location and/or department of the particular facility. For example, the icon group 922 i aociated with the intenive care unit (ICU) of the facility, and the icon group 924 i aociated with the Eat Wing of the facility. In ome example, icon group can be aociated with time before pre-determined time period and/or drop-dead time period are exceeded. For example, a firt icon group can be aoci ated with 1 hour before a pre-determined time period or a drop-dead time period will be exceeded, and a econd icon group can be aociated with 12 hour before the pre determined time period or the drop-dead time period will be exceeded. In thi manner, more urgent time-enitive, patient aociated tak can be eparated from or highlighted relative to le urgent time-enitive, patient-aociated tak In accordance with implementation of the preent dicloure, the uer can elect a patient icon 930 from the creen 900 to initiate execution of a repective time-enitive, patient aociated tak. In the example context, in repone to uer election of a patient icon 930, an ECG creen aociated with a repective patient i diplayed FIG. 10 depict an example ECG creen 1000 graphically repreenting an ECG on the diplay of a mobile device. In ome example, the ECG creen i diplayed in repone to uer election of a patient icon (e.g., a patienticon 930) from a Time-enitive Tak' creen (e.g., a Time enitive Tak' creen 900). The example ECG dicued herein correpond to a 12-lead ECG. Implementation of the preent dicloure are applicable to any appropriate type of ECG. The ECG creen 1000 provide graphical information relating to the data collected from a patient monitoring device. In particular, the ECG creen 1000 provide cardiol ogy information relating to data collected from an ECG moni toring device coupled to a patient The ECG creen 1000 include a diplay region 1002 and a diplay region In the depicted example, the diplay region 1002 provide a grid of ECG trace window 1010a (e.g., 4 column by 3 row, the firt column including the lead I, II and III, the econd column including the lead avr, avlandavf, and the lat two column includ ing the lead V-V). Each trace window 1010a include a repective voltage trace 1005a correpond ing to the repective lead over a period of time. In ome example, the trace window 1010a can be ued to

25 U 2014/ A1 ep. 18, 2014 Zoom in and out of and to croll along egment of the repec tive voltage trace 1005a The diplay region 1004 include expanded trace window, each expanded trace window correponding to a trace window provided in the diplay region In the example of FIG. 10, expanded trace window 1012a, 1012b are diplayed and correpond to the trace window 1010a, 1010b, repectively, of the diplay region In ome example, the expanded traced window can be crolled upward/downward within the diplay region 1004 to reveal additional expanded trace window. For example, un-di played expanded trace window (e.g., expanded trace win dow 1012c-10121), or partially diplayed, expanded trace window (e.g., expanded trace window 1012b) can be crolled into full view, while diplayed trace window (e.g., expanded trace window 1012a, 1012b) can be crolled from V1eW The diplay region 1004 can diplay expanded trace window 1012a having repective voltage trace 1013a-10131, each voltage trace 1013a correpond ing to voltage trace 1005a The voltage trace 1013a are each provided a full trace for a particular period of time, graphically repreenting the ECG data collected over the particular period of time. In ome example, the uer define a deired time period for viewing ECG data by Zoom ing in/out of and/or crolling along one of the Voltage trace 1005a to diplay a deired egment of the voltage trace 1005a within the trace window 1010a Accordingly, the trace diplay window 1010a repec tively diplay egment of the voltage trace 1005a-10051, the egment correponding to repective egment of the voltage trace 1013a diplayed in the expanded trace window 1012a That i, each trace window 1010a can diplay a full trace or Zoomed-in voltage trace 1005a correponding to a voltage trace 1013a In ome example, the voltage trace 1005a are yn chronized with each other, uch that crolling and/or Zooming of a voltage trace 1005a in one trace window 1010a reult in an equivalent crolling and/or Zooming in each of the other trace window 1010a Conequently, each trace window 1010a diplay it repective volt age trace 1005a for the ame time period With continued reference to FIG. 10, a beveled crubber bar 1020 can be provided in each of the trace win dow 1012a The beveled crubber bar 1020 provide a viewing area 1022 having a width w. The viewing area 1022 diplay a portion of the voltage trace 1013a corre ponding to the portion of the voltage trace 1005a diplayed in trace diplay window 1010a Accord ingly, the width w generally correpond to the time period of the voltage trace 1005a In the example of FIG. 10, the width w correpond to the time period between time t and ta. The beveled crubber bar 1020 provide a graphical indicator that enable a uer to quickly dicern which portion of the voltage trace 1013a correpond to the voltage trace Further detail of example ECG diplay are pro vided in International App. No. PCT/U2012/021677, which claim the benefit of U.. Prov. App. No. 61/433,824, the dicloure of which are exprely incorporated herein by reference in their entiretie In accordance with implementation of the preent dicloure, the creen 1000 include an edit icon In ome example, uer input to the editicon 1040 (e.g., tap on) induce diplay of one or more option icon. In ome example, a drop-down menu i diplayed, the drop-down menu including the one or more option icon. In ome example, the uer i able to add a diagnoi, edit a diagnoi, delete a diagnoi and confirm a diagnoi. In ome example, the uer can review the ECG in the creen 1000 and can elect the edit icon 1040 to add, edit and/or delete a diagnoi. In ome example, the uer can elect the edit icon to confirm a diagnoi. For example, the uer can elect the editicon 1040 to diplay the drop-down menu, the drop-down menu includ ing a confirm icon. The uer can elect the confirm icon to confirm a diagnoi aociated with the particular ECG. In ome example, a confirmation ignal aociated with the particular ECG can be tranmitted to the back-end ytem in repone to election of the confirm icon. In ome example, once the ECG ha been confirmed, the patient-aociated tak (e.g., ECG conult) i determined to be completed FIG. 11 depict an example proce 1100 that can be executed in accordance with implementation of the preent dicloure. In ome example, the example proce 1100 can be provided in one or more computer-executable program that can be executed uing one or more computing device (e.g., the mobile device 102 and/or the DM 160, 160') Uer input i received (1102) and a tak creen i diplayed (1104). In ome example, the tak creen i a Time-enitive Tak' creen that provide one or more patient icon that repreent a time-enitive, patient-aoci ated tak (e.g., the creen 900 of FIG. 9). It i determined whether an icon i elected (1104). For example, it i deter mined whether a patient icon repreentative of a time-eni tive, patient-aociated tak i elected. If an icon i not elected, it i determined whether a new creen i to be di played (1114). For example, the uer can chooe to navigate to a different creen from the tak-pecific creen. If it i determined that a new creen i to be diplayed, the new creen i diplayed (1116). If it i determined that a new creen i not to be diplayed, the example proce 1100 loop back If an icon i elected, a tak-pecific creen i di played (1108). In ome example, a tak-pecific creen di play patient data/information aociated with the underlying time-enitive tak and enable the uer to complete the tak (e.g., the creen 1000 of FIG. 10). It i determined whether completion of the tak i confirmed (1110). For example, the uer can elect a confirm option from the tak-pecific creen. If completion of the tak i confirmed, a ignal i tranmitted to a back-end ytem (1112). In thi manner, a back-end ytem managing the underlying tak can be informed that the tak ha been attended to. If completion of the tak i not confirmed, it i determined whether a new creen i to be diplayed (1114). For example, the uer can chooe to navi gate to a different creen from the tak-pecific creen. If it i determined that a new creen i to be diplayed, the new creen i diplayed (1116). If it i determined that a new creen i not to be diplayed, the example proce 1100 loop back. 0119) Implementation of the preent dicloure can be provided uing digital electronic circuitry, or in computer hardware, firmware, oftware, or in combination thereof. In ome example, implementation can be provided one or more computer program product, e.g., a computer program tangibly embodied in a machine-readable torage device, for execution by, or to control the operation of data proceing apparatu, and/or a programmable proceor, a computer, or

26 U 2014/ A1 ep. 18, 2014 multiple computer. A computer program can be written in any form of programming language, including compiled or interpreted language, and it can be deployed in any form, including a a tand-alone program or a a module, compo nent, ubroutine, or other unit uitable for ue in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computer at one ite or ditributed acro multiple ite and interconnected by a communication network. uch a computer program can include module and/or code egment for executing one or more of the feature, apect and/or implementation pro vided herein Operation in accordance with implementation of the preent dicloure can be performed by one or more programmable proceor executing a computer program product to perform function by operating on input data and generating output. By way of example, a computer program product can include module and/or code egment corre ponding to each of the method tep, apect and/or feature provided herein. Method tep can alo be performed by, and apparatu of the preent dicloure can be implemented a, pecial purpoe logic circuitry, e.g., an FPGA (field program mable gate array) or an AIC (application-pecific integrated circuit) Proceor uitable for the execution of a computer program include, by way of example, both general and pecial purpoe microproceor, and any one or more proceor of any kind of digital computer. Generally, a proceor will receive intruction and data from a read-only memory or a random acce memory or both. Element of a computer can include a proceor for executing intruction and one or more memory device for toring intruction and data. Gen erally, a computer can alo include, or be operatively coupled to receive data from or tranfer data to, or both, one or more ma torage device for toring data, e.g., magnetic, mag neto-optical dik, or optical dik. Information carrier uit able for embodying computer program intruction and data include all form of non-volatile memory, including by way of example emiconductor memory device, e.g., EPROM, EEPROM, and flah memory device; magnetic dik uch a internal hard dik and removable dik; magneto-optical dik; and CD-ROM and DVD-ROM dik. The proceor and the memory can be upplemented by, or incorporated in pecial purpoe logic circuitry. 0122) The preent dicloure can be implemented in a ytem including, but not limited to the example ytem decribed herein, which include a back-end component, e.g., a a data erver, or that include a middleware component, e.g., an application erver, or that include a front-end com ponent, e.g., a client device. uch a the mobile device 102. having a graphical uer interface or a Web brower through which a uer can interact with an implementation of the invention, or any combination of uchback-end, middleware, or front-end component. The component of the ytem can be interconnected by any form or medium of digital data communication, e.g., a communication network A number of implementation have been decribed. Neverthele, it will be undertood that variou modification may be made without departing from the pirit and cope of the dicloure. For example, tep of the preent dicloure can be performed in a different order and till achieve deir able reult. Accordingly, other implementation are within the cope of the following claim. 1. A computer-implemented method for providing a uer of a mobile device acce to patient information and patient phyiological data, the method being executed uing one or more proceor and compriing: receiving, by the one or more proceor, uer input, the uer input indicating a uer command to diplay a tak creen; in repone to the uer input, proceing, by the one or more proceor, uer-pecific data to determine one or more patient icon, each patient icon repreenting a time-en itive, patient-aociated tak; and diplaying the tak creen on the mobile device, the tak creen diplaying one or more patient icon group, each patienticon group compriingapatienticon of the one or more patient icon. 2. The method of claim 1, wherein the time-enitive, patient-aociated tak of each patienticon comprie a pend ing tak. 3. The method of claim 1, further compriing, in repone to uer election of a patient icon, diplaying a tak-pecific creen, the tak-pecific creen compriing patient data and/ or patient information aociated with an underlying tak. 4. The method of claim 1, further compriing receiving uer input indicating completion of the time-enitive, patient-aociated tak of a patient icon, and in repone, providing a ignal to a back-end ytem indicating comple tion of the time-enitive, patient-aociated tak. 5. The method of claim 1, further compriing removing the patient icon from diplay in the tak creen. 6. The method of claim 1, wherein each time-enitive, patient-aociated tak i determined to be within a threhold time period. 7. The method of claim 6, wherein a time-enitive, patient aociated tak i determined to be within the threhold time period when a difference between a current time and a time aociated with the tak i within the threhold time period. 8. A computer-readable torage device coupled to one or more proceor and having intruction tored thereon which, when executed by the one or more proceor, caue the one or more proceor to perform operation for provid ing a uer of a mobile device acce to patient information and patient phyiological data, the operation compriing: receiving, by the one or more proceor, uer input, the uer input indicating a uer command to diplay a tak creen; in repone to the uer input, proceing, by the one or more proceor, uer-pecific data to determine one or more patient icon, each patient icon repreenting a time-en itive, patient-aociated tak; and diplaying the tak creen on the mobile device, the tak creen diplaying one or more patient icon group, each patienticon group compriingapatienticon of the one or more patient icon. 9. A ytem, compriing: one or more proceor; and a computer-readable torage medium in communication with the one or more proceor and having intruction tored thereon which, when executed by the one or more proceor, caue the one or more proceor to perform operation for providing a uer of a mobile device acce to patient information and patient phyiological data, the operation compriing: