US20140222467A1 - Patient portal - Google Patents

Patient portal Download PDF

Info

Publication number
US20140222467A1
US20140222467A1 US14/246,963 US201414246963A US2014222467A1 US 20140222467 A1 US20140222467 A1 US 20140222467A1 US 201414246963 A US201414246963 A US 201414246963A US 2014222467 A1 US2014222467 A1 US 2014222467A1
Authority
US
United States
Prior art keywords
data
patient
aggregated
medical
contributing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/246,963
Inventor
Ali Adel Hussam
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Universal Research Solutions LLC
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US14/246,963 priority Critical patent/US20140222467A1/en
Assigned to UNIVERSAL RESEARCH SOLUTIONS, LLC reassignment UNIVERSAL RESEARCH SOLUTIONS, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HUSSAM, ALI ADEL
Priority to US14/321,098 priority patent/US20140316816A1/en
Publication of US20140222467A1 publication Critical patent/US20140222467A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G06F19/322
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H15/00ICT specially adapted for medical reports, e.g. generation or transmission thereof
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms

Definitions

  • EMR electronic medical record
  • An electronic medical record is a computerized medical record created in an organization that delivers care, such as a hospital and/or a doctor's office. EMRs may be a part of a local stand-alone health data system that allows storage, retrieval and modification of records.
  • a computer-implemented method includes receiving, from one or more contributing channels, medical data; assigning the received medical data to one or more data silos; and generating a graphical user interface that when rendered on a display device renders a visual representation of a patient portal, with the patient portal including: one or more visual representations of the one or more data silos for data associated with a user that requested the patient portal.
  • Implementations of the disclosure may include one or more of the following features.
  • the method includes receiving a request for the patient portal; and identifying, from the request, an identity of the user requesting the patient portal.
  • the method includes querying, at least partly based on the identity of the user, the one or more data silos for medical data associated with the user.
  • the method includes receiving, based on querying, data associated with the user that requested the patient portal, and wherein the one or more visual representations of the one or more data silos include one or more visual representations of the received data.
  • the one or more data silos are configured to store a particular type of medical data for a plurality of users.
  • the method includes parsing the received medical data; identifying, based on parsing, one or more types of medical data in the received medical data; for at least one of the identified types of medical data, determining a data silo configured to store the identified type of medical data; and assigning to the determined data silo the at least one identified type of medical data.
  • the graphical user interface dynamically displays the data silos and is generated in real-time.
  • the method includes performing one or more pre-processing operations on the received medical data, wherein the one or more pre-processing operations include one or more of: using the received medical data in generating one or more discrete data elements; or indexing the received medical data in a search engine.
  • one or more machine-readable media are configured to store instructions that are executable by one or more processing devices to perform operations including receiving, from one or more contributing channels, medical data; assigning the received medical data to one or more data silos; and generating a graphical user interface that when rendered on a display device renders a visual representation of a patient portal, with the patient portal including: one or more visual representations of the one or more data silos for data associated with a user that requested the patient portal. Implementations of this aspect of the present disclosure can include one or more of the foregoing features.
  • an electronic system includes one or more processing devices; and one or more machine-readable media configured to store instructions that are executable by the one or more processing devices to perform operations including: receiving, from one or more contributing channels, medical data; assigning the received medical data to one or more data silos; and generating a graphical user interface that when rendered on a display device renders a visual representation of a patient portal, with the patient portal including: one or more visual representations of the one or more data silos for data associated with a user that requested the patient portal.
  • All or part of the foregoing may be implemented as a computer program product including instructions that are stored on one or more non-transitory machine-readable storage media, and that are executable on one or more processing devices. All or part of the foregoing may be implemented as an apparatus, method, or electronic system that may include one or more processing devices and memory to store executable instructions to implement the stated functions.
  • FIG. 1 is a conceptual diagram of a system for generating a patient portal.
  • FIG. 2 is a block diagram of components of the system for generating a patient portal.
  • FIG. 3A is a flow chart of a process for updating a data repository with contributing channel data.
  • FIG. 3B is a flow chart of a process for generating a patient portal.
  • FIGS. 4-8 are example graphical user interfaces included in a patient portal. Like reference symbols in the various drawings indicate like elements.
  • a patient portal includes a graphical user interface that when rendered on a display device allows a patient (and/or any other user of the system) to access and to view data.
  • the patient may access registration data, appointment data, medical form data, feedback data, education data, and outcome data.
  • the system receives the various types of medical data related to the patient from different data sources, entities and/or channels that contribute medical data to the system. These numerous, different data sources, entities and/or channels are collectively referred to herein as “contributing channels,” without limitation, for purposes of convenience.
  • FIG. 1 illustrates a particular exemplary embodiment describe herein.
  • FIG. 1 is a conceptual diagram of system 100 for generating a patient portal.
  • System 100 includes server 102 .
  • Server 102 includes data aggregator 105 .
  • data aggregator is configured to receive contributing channel data from numerous contributing channels.
  • contributing channel data includes, without limitation, registration data 116 , appointment data 118 , medical forms data 120 , feedback data 122 , education data 124 , and outcome data 126 .
  • contributing channels include client devices 104 , 106 , 108 , 110 , 112 , 114 .
  • client device 104 is a device that sends registration data 116 to data aggregator 105 .
  • registration data may include data pertaining to a patient's registration within a healthcare facility, a hospital, a clinic, and so forth.
  • registration data 116 does not have to be for a particular patient. Rather registration data 116 could be for a number of patients. That is, registration data 116 could be a stream of data that is received by data aggregator 105 .
  • Data aggregator 105 receives registration data 116 and parses registration data 116 to associate registration data 116 with various patients.
  • appointment data 118 may be sent by client device 106 which may include a computing device configured to store data pertaining to medical appointments.
  • appointment data 118 may pertain to a single patient or may pertain to a number of patients.
  • appointment data 118 may be a stream of data combining medical appointment data for a plurality of patients.
  • Another contributing channel sends medical forms data 120 .
  • medical forms data 120 is sent to data aggregator 105 by client device 108 .
  • client device 108 may be a device that is configured to store medical forms, for example, as described in U.S. application Ser. No. 12/699,522, the entire contents of which are incorporated herein by reference.
  • Another contributing channel sends feedback data 122 .
  • feedback data 122 may be sent to data aggregator 105 by user device 110 .
  • user device 110 is a device that is configured to collect from a patient feedback data, for example, as described in U.S. application Ser. No. 13/069,353, the entire contents of which are incorporated herein by reference.
  • feedback data is indicative of patient satisfaction with a medical procedure, a medical facility with a particular doctor and/or with particular medical staff.
  • education data 124 is sent from the client device 112 to data aggregator 105 .
  • education data 124 includes data that is meant to educate a patient about a particular medical condition, a particular medical procedure, symptoms of a particular medical condition, allergic reactions, particular types of medication, and so forth.
  • outcome data 126 is sent by client device 114 to data aggregator 105 .
  • client device 114 may include a system that is configured to receive data indicative of an outcome of a medical procedure, of medication and/or of a medical study as described in U.S. application Ser. No. 13/046,028, the entire contents of which are incorporated herein by reference.
  • data aggregator 105 receives outcome data 126 and stores outcome data 126 .
  • data aggregator 105 receives contributing channel data from the various contributing channels 104 , 106 , 108 , 110 , 112 , 114 .
  • Data aggregator 105 stores the contributing channel data that is received from the various contributing channels 104 , 106 , 108 , 110 , 112 , 114 .
  • data aggregator 105 stores the contributing channel data in a manner that is compliant with the Health Insurance Portability and Accountability Act (“HIPPA”), secure, encrypted, and protected (e.g., protected health information (“PHI”)).
  • HPI Health Insurance Portability and Accountability Act
  • Data aggregator 105 may be configured to store the contributing channel data received from the contributing channels 104 , 106 , 108 , 110 , 112 , 114 by a type of contributing channel data. For example, registration data 116 may be stored with other registration data. Appointment data 118 may be stored with other appointment data. Medical forms data 120 may be stored with other medical forms data and so forth.
  • data aggregator 105 may be configured to receive the contributing channel data from the various contributing channels 104 , 106 , 108 , 110 , 112 , 114 , parse the data to identify associations between portions of the data and various patient, and tag the data with information identifying which portions of the data are associated with which patients.
  • a tag includes a data container in which data is stored in accordance with a pre-defined standard. The process of associating data with a tag is commonly referred to as “tagging.”
  • registration data 116 may include data for two patients, namely, John Johnson and Sally Hayes.
  • Appointment data 118 may also include data for these patients, John Johnson and Sally Hayes.
  • data aggregator 105 is configured to parse registration data 116 to identify the portion of registration data 116 that is for John Johnson and to also identify the other portion of registration data 116 that is for Sally Hayes.
  • data aggregator 105 is configured to tag this data accordingly such that the tag identifies an identity of the patient associated with the portions of registration data 116 .
  • the portion of registration data 116 that is for John Johnson is tagged with data specifying a patient identity of John Johnson.
  • the portion of registration data 116 that is tagged for Sally Hayes is associated with data specifying that this portion of registration data 116 is for Sally Hayes.
  • data aggregator 105 may also be configured to store numerous different types of contributing channel data on a per patient basis.
  • the contributing channel data for John Johnson may be collected and correlated together and stored in a portion of data repository 130 that is specific for John Johnson.
  • the contributing channel data for Sally Hayes may be collected and correlated together in an area of database 130 that is designated for Sally Hayes.
  • data repository 130 is configured to store contributing channel data received from the various contributing channels 104 , 106 , 108 , 110 , 112 , 114 including, for example, registration data 116 , appointment data 118 , medical forms data 120 , feedback data 122 , education data 124 , and outcome data 126 .
  • data repository 130 is configured to store contributing channel data in various data structures, including, e.g., silo data structures (“silos”).
  • silo includes a data structure that provides storage and/or access to a particular type of data.
  • Data repository 130 includes numerous silos including, for example, silo 134 , silo 136 , silo 138 , silo 140 , silo 142 , silo 144 .
  • data repository 130 includes a silo for each type of contributing channel. That is, data repository 130 includes a correspondence between a silo and a type of contributing channel.
  • silo 134 stores registration data 116 .
  • silo 136 stores appointments data 118 .
  • Silo 138 stores medical forms data 120 .
  • Silo 140 stores feedback data 122 .
  • Silo 142 stores education data 124 .
  • Silo 144 stores outcome data 126 .
  • silos 134 , 136 , 138 , 140 , 142 , 144 may be configured to store medical data for a plurality of patients.
  • silo 134 may be configured to store registration data 116 for both John Johnson and Sally Hayes.
  • data repository 130 may include silos that are specific for particular patients and/or for particular types of contributing channel data.
  • data repository 130 may include a silo (not shown) for registration data 116 for John Johnson.
  • Data repository 130 may also include different silo (not shown) for registration data 116 for Sally Hayes.
  • data repository 130 may be configured to store silos including numerous, different types of contributing channel data for a patient.
  • data repository 130 may include a silo that includes registration data 116 , appointment data 118 , medical forms data 120 , feedback data 122 , education data 124 , and outcome data 126 for John Johnson.
  • Data repository 130 may include another different silo that includes registration data 116 , appointment data 118 , medical forms data 120 , feedback data 122 , education data 124 , and outcome data 126 for Sally Hayes.
  • system 100 includes another client device, namely, client device 128 .
  • client device 128 is used by a patient to access patient portal 132 .
  • data aggregator 105 generates patient portal 132 which may be, for example, a graphical user interface that when rendered on client device 128 renders visual representations of silos 134 , 136 , 138 , 140 , 142 , 144 .
  • visual representations of the foregoing silos may be represented as virtual silos, including, for example, virtual silo 146 , virtual silo 148 , virtual silo 150 , virtual silo 152 , virtual silo 154 , and virtual silo 156 .
  • virtual silo 146 pertains to registration data 116 and provides the user with a visual representation of silo 134 . That is, virtual silo 146 corresponds to silo 134 .
  • virtual silo 148 pertains to appointment data 118 and provides the user with a visual representation of silo 136 .
  • Virtual silos 150 , 152 , 154 and 156 each provide a user with visual representations of their respective silos in data repository 130 .
  • graphical user interface 132 displays data that is for a particular patient. That is, virtual silos 146 , 148 , 150 , 152 , 154 , 156 display data that is particular to a specific patient.
  • silos 134 , 136 , 138 , 140 , 142 , 144 are silos that include contributing channel data for numerous patients including, for example, John Johnson and Sally Hayes in the foregoing example.
  • silos 134 , 136 , 138 , 140 , 142 , 144 include a particular type of contributing channel data for numerous patients
  • data aggregator 105 is configured to query each of these silos 134 , 136 , 138 , 140 , 142 , 144 to obtain data that corresponds to the patient that is requesting patient portal 132 .
  • the user of client device 128 may be John Johnson.
  • John Johnson accesses patient portal 132 .
  • data aggregator 105 generates a graphical user interface that renders a visual representation of patient portal 132 .
  • data aggregator 105 queries silos 134 , 136 , 138 , 140 , 142 , 144 for data associated and/or tagged with data specifying a patient name of John Johnson.
  • data aggregator 105 is able to select this data from the various silos 134 , 136 , 138 , 140 , 142 , 144 and make this data accessible through virtual silos 146 , 148 , 150 , 152 , 154 , 156 in patient portal 132 .
  • FIG. 2 illustrates a particular exemplary embodiment describe herein.
  • FIG. 2 is a block diagram of components of system 100 for generating a patient portal.
  • Client devices 104 , 106 , 108 , 110 , 112 , 114 , 128 can be any sort of computing devices capable of taking input from a user and communicating over a network (not shown) with server 102 and/or with other client devices.
  • client devices 104 , 106 , 108 , 110 , 112 , 114 , 128 can be mobile devices, desktop computers, laptops, cell phones, personal digital assistants (“PDAs”), servers, embedded computing systems, and so forth.
  • PDAs personal digital assistants
  • server 102 can be any of a variety of computing devices capable of receiving data, such as a server, a distributed computing system, a desktop computer, a laptop, a cell phone, a rack-mounted server, and so forth.
  • Server 102 may be a single server or a group of servers that are at a same location or at different locations.
  • the illustrated server 102 can receive data from client devices 104 , 106 , 108 , 110 , 112 , 114 , 128 via input/output (“I/O”) interface 200 .
  • I/O interface 200 can be any type of interface capable of receiving data over a network, such as an Ethernet interface, a wireless networking interface, a fiber-optic networking interface, a modem, and so forth.
  • Server 102 also includes a processing device 202 and memory 204 .
  • a bus system 206 including, for example, a data bus and a motherboard, can be used to establish and to control data communication between the components of server 102 .
  • the illustrated processing device 202 may include one or more microprocessors. Generally, processing device 202 may include any appropriate processor and/or logic that is capable of receiving and storing data, and of communicating over a network (not shown).
  • Memory 204 can include a hard drive and a random access memory storage device, such as a dynamic random access memory, or other types of non-transitory machine-readable storage devices. As shown in FIG. 2 , memory 204 stores computer programs that are executable by processing device 202 . Among these computer programs is data aggregator 105 .
  • Memory 204 is also configured to execute a processing engine (not shown).
  • the processing engine is configured to perform pre-processing operations to prepare contributing channel data for processing by data aggregator 105 and/or to prepare data for processing and generating as cross-channel data, e.g., which is described in U.S. Ser. No. 13/159,155, the contents of which are incorporated herein by reference.
  • the pre-processing operations include search engine indexing operations and generation of discrete data elements operations.
  • the processing engine may execute on client devices 104 , 106 , 108 , 110 , 112 , 114 , e.g., rather than or in addition to executing on server 110 .
  • a client device executes the processing engine to prepare contributing channel data for transfer to server 110 .
  • the processing engine uses data stored on the client device and/or retrieved by the client device and generates discrete data elements that may be transferred to server 110 . That is, after the processing engine of the client device has generated the discrete data elements, the processing engine may contribute (e.g., transfer) the discrete data elements to data aggregator 105 .
  • the processing engine receives data and generates discrete data elements by using a data filter to format data from a first data format to a second data format, for example, as described in U.S. Ser. No. 12/774,694, the entire contents of which are incorporated herein by reference.
  • the processing engine generates the discrete data elements by performing optical character recognition (“OCR”) on the contributing channel data.
  • OCR optical character recognition
  • the processing engine (e.g., executing on a client device and/or on server 110 ) includes a search component (e.g., a search engine).
  • the search component indexes the contributing channel data, e.g., that is stored in data repository 130 , for example using indexing techniques that are well known in the art.
  • the search component includes a spider (e.g., a web traversal portion of a search engine) that collects contributing channel data (e.g., discrete data elements) for indexing in data repository 130 , e.g., as is commonly known in the art.
  • a user may search data repository 130 for a particular type of data (e.g., discrete data elements) and/or for data received from a particular type of contributing entity and/or for historic, live data, and so forth.
  • a user may access the search component to search for patients having particular conditions.
  • the user may access the search component to search for patients associated with particular medical codes and/or medical forms.
  • data aggregator 105 performs OCR on the received contributing channel data.
  • the user may perform word searches in identifying different types of data.
  • FIG. 3A illustrates a particular exemplary embodiment describe herein.
  • FIG. 3A is a flow chart of process 300 for updating data repository 130 with contributing channel data 116 , 118 , 120 , 122 , 124 , 126 .
  • data aggregator 105 receives contributing channel data 116 , 118 , 120 , 122 , 124 , 126 from contributing channels 104 , 106 , 108 , 110 , 112 , 114 .
  • Data aggregator 105 tags ( 304 ) the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 with a patient identifier identifying the patient associated with the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 .
  • portions of the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 include patient identifying information.
  • Data aggregator 105 parses the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 to identify the patient identifying information and to identify which portions of the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 are associated with which portions of the patient identifying information.
  • data aggregator 105 tags the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 with information specifying a correspondence between portions of the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 and various patients.
  • data aggregator 105 updates ( 306 ) data repository 130 with the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 .
  • data repository 130 updates ( 306 ) data repository 130 with the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 .
  • data aggregator 105 updates ( 308 ) silos 134 , 136 , 138 , 140 , 142 and 144 with the received contributing channel data 116 , 118 , 120 , 122 , 124 , 126 , which may be tagged as described in the foregoing example.
  • data aggregator 105 may determine which silo corresponds to a particular type of contributing channel data and update that silo by storing the received contributing channel data for that particular type in the appropriate silo.
  • received registration data 116 is stored (e.g., in real-time and automatically) in an appropriate silo, namely, silo 134 , at least because silo 134 is configured to store registration data 116 .
  • FIG. 3B illustrates a particular exemplary embodiment describe herein.
  • FIG. 3B is a flow chart of process 350 for generating patient portal 132 .
  • data aggregator 105 receives ( 352 ) a request for patient portal 132 , for example, by a user accessing a website that is associated with the patient portal and/or logging into a website that is associated with the patient portal.
  • data aggregator 105 parses ( 354 ) the request for patient portal 132 .
  • data aggregator 105 determines ( 356 ) the patient identity of the patient that has requested the patient portal, for example, based on the user name and password information that the user used to log into the website.
  • Data aggregator 105 queries ( 358 ) data repository 130 for contributing channel data associated with the identified patient.
  • the data aggregator 105 may query silos 134 , 136 , 138 , 140 , 142 , 144 for data associated with the patient that has requested patient portal 132 .
  • data aggregator 105 determines from the request the name of the patient that has requested patient portal 132 .
  • Data aggregator 105 queries silos 134 , 136 , 138 , 140 , 142 , 144 for data associated with the same patient name that was included in the request.
  • silos 134 , 136 , 138 , 140 , 142 , 144 may include tables of data with a portion of the table including the contributing channel data and with the other portion of the table associating the contributing channel data with a patient identifier, for example, the name of the patient.
  • data aggregator 105 submits to silos 134 , 136 , 138 , 140 , 142 , 144 the patient identifier.
  • data repository 130 determines contributing channel data that is tagged with information corresponding to the patient identifier and/or contributing channel data that is otherwise associated with the patient identifier (e.g., through the foregoing table).
  • data aggregator 105 receives ( 360 ) from data repository 130 appropriate contributing channel data for the user requesting patient portal 132 . Using the received contributing channel data, data aggregator 105 generates ( 362 ) patient portal 132 , as described herein, for example, by generating virtual silos for each type of received contributing channel data (e.g., virtual silos 146 , 148 , 150 , 152 , 154 , 156 ).
  • virtual silos for each type of received contributing channel data (e.g., virtual silos 146 , 148 , 150 , 152 , 154 , 156 ).
  • FIG. 4 illustrates a particular exemplary embodiment describe herein.
  • FIG. 4 is an example of graphical user interface 400 included in patient portal 132 .
  • data aggregator 105 generates virtual silos 402 , 404 , 406 , 408 , 410 , 412 , including, e.g., visual representations of silos 134 , 136 , 138 , 140 , 142 , 144 .
  • data aggregator 105 is configured to dynamically and in real-time update visual representations of silos 134 , 136 , 138 , 140 , 142 , 144 , for example, based on newly received contributing channel data.
  • virtual silo 402 providers a user with registration data 116 , including, e.g., names of medical facilities with which the user is currently registered, forms that may be used by the user to register at additional medical facilities, and so forth.
  • Virtual silo 404 provides the user with appointment data 118 , including, e.g., medical appointments that the user has scheduled and/or needs to schedule.
  • Virtual silo 406 provides the user with medical forms data 120 , including, e.g., medical questionnaires for the user to fill out prior to an appointment with a physician, medical assessment forms for the user to fill out assist a physician and/or automated medical assessment system in diagnosing an ailment of the user, and so forth.
  • Virtual silo 408 provides the user with feedback data 122 , including, e.g., online forms through which the user can submit feedback for a particular medical professional, medical facility, medical procedure, and so forth.
  • Virtual silo 410 provides the user with education data 124 , including, e.g., data pertaining to a physical ailment of the patient, data describing medical conditions, data describing various side-effects of a medication, and so forth.
  • Virtual silo 412 provides the user with outcome data 126 , including, e.g., data indicative of the outcome a medical procedure, such as whether the procedure was a success and/or a failure.
  • Graphical user interface 400 also includes portion 414 through which a user may access and view additional data that is specific to the user.
  • portion 414 includes a selectable link, selection of which causes data aggregator 105 to display the data that is specific to the user.
  • Graphical user interface 400 also includes portion 416 for a user to login into patient portal 132 .
  • the user may log into the patient portal by entering into text boxes 418 , 420 , 422 , 424 data identifying the user, including, e.g., first name data, last name data, date of birth data, and social security data.
  • the user may also log into patient portal 132 via a user account that uniquely identifies the user.
  • the user enters the user account data into text boxes 426 , 428 .
  • FIG. 5 illustrates a particular exemplary embodiment describe herein.
  • FIG. 5 is an example of graphical user interface 500 included in the patient portal.
  • graphical user interface 500 is generated by data aggregator 105 after the user logs into the patient portal.
  • data aggregator 105 retrieves contributing channel data 502 , 504 , 506 , 508 , 510 , 512 (e.g., from silos 134 , 136 , 138 , 140 , 142 , 144 ) that is associated with the user.
  • data aggregator 105 is configured to retrieve contributing channel data 502 , 504 , 506 , 508 , 510 , 512 in real-time from silos 134 , 136 , 138 , 140 , 142 , 144 .
  • data aggregator 105 sends real-time requests to data repository 130 for contributing channel data 502 , 504 , 506 , 508 , 510 , 512 , for example, when the user log into patient portal 132 .
  • data aggregator 105 sends the user's login information to data repository 130 to promote an ability of data repository 130 to identify contributing channel data that is specific to the user (e.g., by identifying contributing channel data that is tagged with data corresponding to the login information) and to send this contributing channel data to data aggregator 105 .
  • At least a portion of contributing channel data 502 , 504 , 506 , 508 , 510 , 512 includes selectable data, selection of which allows the user to view and to access a particular item of contributing channel data.
  • a particular item of contributing channel data is juxtaposed to a link, selection of which allows the user to view the particular item of contributing channel data.
  • juxtaposition includes a placement of an item of data in proximity to another item of data.
  • virtual silos 402 , 404 , 406 , 408 , 410 , 412 includes selectable areas, selection of which enables a user to view data included in the selected silo.
  • FIG. 6 illustrates a particular exemplary embodiment describe herein.
  • FIG. 6 is an example of graphical user interface 600 included in patient portal.
  • the user has selected virtual silo 406 to view medical forms that are associated with the user.
  • graphical user interface 600 includes menu area 602 that displays for the user the different types of medical forms that are associated with the user.
  • Menu area 602 also includes data indicative of a completion status for each of the forms.
  • menu area 602 includes completion status indicators 604 , 606 , 608 , 610 .
  • Completion status indicators 604 , 606 , 608 , 610 provide the user with data specifying a status of a particular medical form, including, e.g., whether the medical form is complete, incomplete, and/or if no data has been provided for the medical form.
  • visual representations 614 , 616 are juxtaposed to completion status indicators 604 , 606 , 608 , 610 .
  • Visual representations 614 , 616 provide the user with a visual indicator (e.g., a check mark or other visual indicator) that a particular medical form has been completed by the user.
  • Graphical user interface 600 also includes portion 618 that provides the user with the contents of a selected form.
  • portion 618 is populated with data indicative of the medical history of the user.
  • FIG. 7 illustrates a particular exemplary embodiment describe herein.
  • FIG. 7 is an example of graphical user interface 7 included in the patient portal.
  • the user has selected another link in virtual silo 406 .
  • the user has selected to view the dash form 704 .
  • selected medical form is incomplete, e.g., as indicated by completion status indicator 610 .
  • portion 702 is populated with contents of dash form 704 to assist the user in completing the form.
  • FIG. 8 illustrates a particular exemplary embodiment describe herein.
  • FIG. 8 is an example of graphical user interface 800 included in patient portal 132 .
  • data aggregator 105 enables the patient to view physical notes and progress data, via, graphical user interface 800 .
  • graphical user interface 800 includes virtual silos 402 , 404 , 406 , 408 , 410 , 412 .
  • the patient has selected area 802 to view the patient's personal records.
  • the patient's personal record includes visual representation 804 .
  • Visual representation 804 includes a representation of the patient's first visit to a physician (and/or a medical facility), including a patient statement, the physician's findings, and the satisfaction level that has been indicated by the patient.
  • Graphical user interface 800 also includes visual representation 806 which includes a visual representation of the dates of treatment for the patient (e.g., associated with the first visit) and an illustrative diagram of the areas of the patient's body in which the patient has received treatment.
  • Graphical user interface 800 also includes visual representation 808 that includes data indicative of a patient's second visit to the physician.
  • Graphical user interface 800 also includes visual representation 810 including an additional visual representation of the treatment that the patient has received on a different date.
  • Graphical user interface 800 also includes visual representation 812 including data indicative a patient's third visit to the physician.
  • a visual representation of trends over visits may be shown.
  • trends over visits include information indicative of trends and/or progressions in patient health over a period of time and/or over a number of office visits. For example, if a patient has cholesterol measured each time the patient visits the physician, data aggregator 105 may be configured to generate a visual representation of the patient's cholesterol measurements over a period of time (e.g., for each of the office visits).
  • data aggregator 105 is configured to identify stale data (e.g., in the silos) and to generate alerts to notify users of the stale data.
  • stale data refers to data that is older than a predefined period of time.
  • data aggregator 105 is configured to generate an alert to notify a viewer of the graphical user interface that at least a portion of the data is stale.
  • Data aggregator 105 is also configured to generate reminders (e.g., automated reminders) to notify users of the patient portal of upcoming appointments, of forms that need to be filled out and other tasks to be performed.
  • reminders e.g., automated reminders
  • users may set reminder dates for certain tasks and/or functionality that is provided through the patient portal.
  • Data aggregator 105 is also configured to provide semantic highlighting and semantic color coding for contributing channel data. For example, a particular type of contributing channel data may assigned a particular color (e.g., purple) and a different type of contributing channel data may be assigned another, different color (e.g., blue).
  • the contributing channel is displayed in a graphical user interface in accordance with the assigned semantic color coding, e.g., to promote an ability of a user to visually identify certain types of contributing channel, e.g., based on the semantic color coding.
  • Embodiments can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof.
  • An apparatus can be implemented in a computer program product tangibly embodied or stored in a machine-readable storage device for execution by a programmable processor; and method actions can be performed by a programmable processor executing a program of instructions to perform functions by operating on input data and generating output.
  • the embodiments described herein, and other embodiments of the invention can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device.
  • Each computer program can be implemented in a high-level procedural or object oriented programming language, or in assembly or machine language if desired; and in any case, the language can be a compiled or interpreted language.
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read-only memory or a random-access memory or both.
  • the essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • Computer readable media for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto optical disks e.g., CD ROM and DVD-ROM disks.
  • the processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry. Any of the foregoing can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
  • ASICs application-specific integrated circuits
  • embodiments can be implemented on a computer having a display device, e.g., a LCD (liquid crystal display) monitor, for displaying data to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.
  • a display device e.g., a LCD (liquid crystal display) monitor
  • a keyboard and a pointing device e.g., a mouse or a trackball
  • Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
  • Embodiments can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of embodiments, or any combination of such back end, middleware, or front end components.
  • the components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
  • LAN local area network
  • WAN wide area network
  • the system and method or parts thereof may use the “World Wide Web” (Web or WWW), which is that collection of servers on the Internet that utilize the Hypertext Transfer Protocol (HTTP).
  • HTTP is a known application protocol that provides users access to resources, which may be data in different formats such as text, graphics, images, sound, video, Hypertext Markup Language (HTML), as well as programs.
  • the client computer Upon specification of a link by the user, the client computer makes a TCP/IP request to a Web server and receives data, which may be another Web page that is formatted according to HTML. Users can also access other pages on the same or other servers by following instructions on the screen, entering certain data, or clicking on selected icons.
  • any type of selection device known to those skilled in the art such as check boxes, drop-down boxes, and the like, may be used for embodiments using web pages to allow a user to select options for a given component.
  • Servers run on a variety of platforms, including UNIX machines, although other platforms, such as Windows 2000/2003, Windows NT, Sun, Linux, and Macintosh may also be used.
  • Computer users can view data available on servers or networks on the Web through the use of browsing software, such as Firefox, Netscape Navigator, Microsoft Internet Explorer, or Mosaic browsers.
  • the computing system can include clients and servers.
  • a client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Abstract

A computer-implemented includes receiving, from one or more contributing channels, medical data; assigning the received medical data to one or more data silos; and generating a graphical user interface that when rendered on a display device renders a visual representation of a patient portal, with the patient portal including: one or more visual representations of the one or more data silos for data associated with a user that requested the patient portal.

Description

    CLAIM OF PRIORITY
  • This application is a continuation of and claims priority under 35 U.S.C. §120 to U.S. application Ser. No. 14/104,349, which was filed Dec. 12, 2013, which is a continuation of and claims priority under 35 U.S.C. §120 to U.S. application Ser. No. 13/181,461, which was filed Jul. 12, 2011, the entire contents of each of which are hereby incorporated by reference.
  • BACKGROUND
  • An electronic medical record (“EMR”) is a computerized medical record created in an organization that delivers care, such as a hospital and/or a doctor's office. EMRs may be a part of a local stand-alone health data system that allows storage, retrieval and modification of records.
  • SUMMARY
  • In one aspect of the present disclosure, a computer-implemented method includes receiving, from one or more contributing channels, medical data; assigning the received medical data to one or more data silos; and generating a graphical user interface that when rendered on a display device renders a visual representation of a patient portal, with the patient portal including: one or more visual representations of the one or more data silos for data associated with a user that requested the patient portal.
  • Implementations of the disclosure may include one or more of the following features. In some implementations, the method includes receiving a request for the patient portal; and identifying, from the request, an identity of the user requesting the patient portal. In other implementations, the method includes querying, at least partly based on the identity of the user, the one or more data silos for medical data associated with the user. In still other implementations, the method includes receiving, based on querying, data associated with the user that requested the patient portal, and wherein the one or more visual representations of the one or more data silos include one or more visual representations of the received data.
  • In some implementations, the one or more data silos are configured to store a particular type of medical data for a plurality of users. In still implementations, the method includes parsing the received medical data; identifying, based on parsing, one or more types of medical data in the received medical data; for at least one of the identified types of medical data, determining a data silo configured to store the identified type of medical data; and assigning to the determined data silo the at least one identified type of medical data. In still other implementations, the graphical user interface dynamically displays the data silos and is generated in real-time. In some implementations, the method includes performing one or more pre-processing operations on the received medical data, wherein the one or more pre-processing operations include one or more of: using the received medical data in generating one or more discrete data elements; or indexing the received medical data in a search engine.
  • In another aspect of the disclosure, one or more machine-readable media are configured to store instructions that are executable by one or more processing devices to perform operations including receiving, from one or more contributing channels, medical data; assigning the received medical data to one or more data silos; and generating a graphical user interface that when rendered on a display device renders a visual representation of a patient portal, with the patient portal including: one or more visual representations of the one or more data silos for data associated with a user that requested the patient portal. Implementations of this aspect of the present disclosure can include one or more of the foregoing features.
  • In still another aspect of the disclosure, an electronic system includes one or more processing devices; and one or more machine-readable media configured to store instructions that are executable by the one or more processing devices to perform operations including: receiving, from one or more contributing channels, medical data; assigning the received medical data to one or more data silos; and generating a graphical user interface that when rendered on a display device renders a visual representation of a patient portal, with the patient portal including: one or more visual representations of the one or more data silos for data associated with a user that requested the patient portal. Implementations of this aspect of the present disclosure can include one or more of the foregoing features.
  • All or part of the foregoing may be implemented as a computer program product including instructions that are stored on one or more non-transitory machine-readable storage media, and that are executable on one or more processing devices. All or part of the foregoing may be implemented as an apparatus, method, or electronic system that may include one or more processing devices and memory to store executable instructions to implement the stated functions.
  • The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.
  • BRIEF DESCRIPTION OF THE FIGURES
  • FIG. 1 is a conceptual diagram of a system for generating a patient portal.
  • FIG. 2 is a block diagram of components of the system for generating a patient portal.
  • FIG. 3A is a flow chart of a process for updating a data repository with contributing channel data.
  • FIG. 3B is a flow chart of a process for generating a patient portal.
  • FIGS. 4-8 are example graphical user interfaces included in a patient portal. Like reference symbols in the various drawings indicate like elements.
  • DETAILED DESCRIPTION
  • Described herein is a system for generating a patient portal to allow a patient to access different types of medical data that is related to the patient. Generally, a patient portal includes a graphical user interface that when rendered on a display device allows a patient (and/or any other user of the system) to access and to view data. For example, though the patient portal, the patient may access registration data, appointment data, medical form data, feedback data, education data, and outcome data. The system receives the various types of medical data related to the patient from different data sources, entities and/or channels that contribute medical data to the system. These numerous, different data sources, entities and/or channels are collectively referred to herein as “contributing channels,” without limitation, for purposes of convenience.
  • FIG. 1 illustrates a particular exemplary embodiment describe herein. In particular, FIG. 1 is a conceptual diagram of system 100 for generating a patient portal. System 100 includes server 102. Server 102 includes data aggregator 105. In the illustrative example of FIG. 1, data aggregator is configured to receive contributing channel data from numerous contributing channels. In an example, contributing channel data includes, without limitation, registration data 116, appointment data 118, medical forms data 120, feedback data 122, education data 124, and outcome data 126.
  • In the illustrative example of FIG. 1, contributing channels include client devices 104, 106, 108, 110, 112, 114. In an exemplary embodiment, client device 104 is a device that sends registration data 116 to data aggregator 105. In this example registration data may include data pertaining to a patient's registration within a healthcare facility, a hospital, a clinic, and so forth. In the example of FIG. 1, registration data 116 does not have to be for a particular patient. Rather registration data 116 could be for a number of patients. That is, registration data 116 could be a stream of data that is received by data aggregator 105. Data aggregator 105 receives registration data 116 and parses registration data 116 to associate registration data 116 with various patients.
  • In an exemplary embodiment described herein, another contributing channel sends appointment data 118 to data aggregator 105. In particular, appointment data 118 may be sent by client device 106 which may include a computing device configured to store data pertaining to medical appointments. As described above with regard to registration data 116, appointment data 118 may pertain to a single patient or may pertain to a number of patients. In particular, appointment data 118 may be a stream of data combining medical appointment data for a plurality of patients.
  • Another contributing channel sends medical forms data 120. In the illustrative example of FIG. 1, medical forms data 120 is sent to data aggregator 105 by client device 108. In this example, client device 108 may be a device that is configured to store medical forms, for example, as described in U.S. application Ser. No. 12/699,522, the entire contents of which are incorporated herein by reference. Another contributing channel sends feedback data 122. In this example, feedback data 122 may be sent to data aggregator 105 by user device 110. In this example, user device 110 is a device that is configured to collect from a patient feedback data, for example, as described in U.S. application Ser. No. 13/069,353, the entire contents of which are incorporated herein by reference. For example, feedback data is indicative of patient satisfaction with a medical procedure, a medical facility with a particular doctor and/or with particular medical staff.
  • Another type of contributing channel sends education data 124. In the illustrative example of FIG. 1, education data 124 is sent from the client device 112 to data aggregator 105. In this example, education data 124 includes data that is meant to educate a patient about a particular medical condition, a particular medical procedure, symptoms of a particular medical condition, allergic reactions, particular types of medication, and so forth.
  • Another type of contributing channel data that is received by data aggregator 105 is outcome data 126. In the illustrative example of FIG. 1, outcome data 126 is sent by client device 114 to data aggregator 105. In this example, client device 114 may include a system that is configured to receive data indicative of an outcome of a medical procedure, of medication and/or of a medical study as described in U.S. application Ser. No. 13/046,028, the entire contents of which are incorporated herein by reference. In the illustrative example of FIG. 1, data aggregator 105 receives outcome data 126 and stores outcome data 126.
  • Still referring to FIG. 1, data aggregator 105 receives contributing channel data from the various contributing channels 104, 106, 108, 110, 112, 114. Data aggregator 105 stores the contributing channel data that is received from the various contributing channels 104, 106, 108, 110, 112, 114. In an example, data aggregator 105 stores the contributing channel data in a manner that is compliant with the Health Insurance Portability and Accountability Act (“HIPPA”), secure, encrypted, and protected (e.g., protected health information (“PHI”)). Data aggregator 105 may be configured to store the contributing channel data received from the contributing channels 104, 106, 108, 110, 112, 114 by a type of contributing channel data. For example, registration data 116 may be stored with other registration data. Appointment data 118 may be stored with other appointment data. Medical forms data 120 may be stored with other medical forms data and so forth.
  • In another example, data aggregator 105 may be configured to receive the contributing channel data from the various contributing channels 104, 106, 108, 110, 112, 114, parse the data to identify associations between portions of the data and various patient, and tag the data with information identifying which portions of the data are associated with which patients. Generally, a tag includes a data container in which data is stored in accordance with a pre-defined standard. The process of associating data with a tag is commonly referred to as “tagging.”
  • For example, registration data 116 may include data for two patients, namely, John Johnson and Sally Hayes. Appointment data 118 may also include data for these patients, John Johnson and Sally Hayes. In this example, data aggregator 105 is configured to parse registration data 116 to identify the portion of registration data 116 that is for John Johnson and to also identify the other portion of registration data 116 that is for Sally Hayes.
  • Once data aggregator 105 has identified the portions of registration data 116 that are for John Johnson and Sally Hayes, respectively, data aggregator 105 is configured to tag this data accordingly such that the tag identifies an identity of the patient associated with the portions of registration data 116. For example, the portion of registration data 116 that is for John Johnson is tagged with data specifying a patient identity of John Johnson. Similarly, the portion of registration data 116 that is tagged for Sally Hayes is associated with data specifying that this portion of registration data 116 is for Sally Hayes.
  • In another exemplary embodiment described herein, data aggregator 105 may also be configured to store numerous different types of contributing channel data on a per patient basis. For example, the contributing channel data for John Johnson may be collected and correlated together and stored in a portion of data repository 130 that is specific for John Johnson. Similarly, the contributing channel data for Sally Hayes may be collected and correlated together in an area of database 130 that is designated for Sally Hayes.
  • Still referring to FIG. 1, data repository 130 is configured to store contributing channel data received from the various contributing channels 104, 106, 108, 110, 112, 114 including, for example, registration data 116, appointment data 118, medical forms data 120, feedback data 122, education data 124, and outcome data 126.
  • In an example, data repository 130 is configured to store contributing channel data in various data structures, including, e.g., silo data structures (“silos”). Generally, a silo includes a data structure that provides storage and/or access to a particular type of data. Data repository 130 includes numerous silos including, for example, silo 134, silo 136, silo 138, silo 140, silo 142, silo 144. In this example, data repository 130 includes a silo for each type of contributing channel. That is, data repository 130 includes a correspondence between a silo and a type of contributing channel. Accordingly, in the exemplary embodiment of FIG. 1, silo 134 stores registration data 116. Similarly, silo 136 stores appointments data 118. Silo 138 stores medical forms data 120. Silo 140 stores feedback data 122. Silo 142 stores education data 124. Silo 144 stores outcome data 126.
  • In the illustrative example of FIG. 1, silos 134, 136, 138, 140, 142, 144 may be configured to store medical data for a plurality of patients. For example, silo 134 may be configured to store registration data 116 for both John Johnson and Sally Hayes. In a variation of FIG. 1, data repository 130 may include silos that are specific for particular patients and/or for particular types of contributing channel data. For example, data repository 130 may include a silo (not shown) for registration data 116 for John Johnson. Data repository 130 may also include different silo (not shown) for registration data 116 for Sally Hayes.
  • In still another variation of FIG. 1, data repository 130 may be configured to store silos including numerous, different types of contributing channel data for a patient. For example, data repository 130 may include a silo that includes registration data 116, appointment data 118, medical forms data 120, feedback data 122, education data 124, and outcome data 126 for John Johnson. Data repository 130 may include another different silo that includes registration data 116, appointment data 118, medical forms data 120, feedback data 122, education data 124, and outcome data 126 for Sally Hayes.
  • Still referring to FIG. 1, system 100 includes another client device, namely, client device 128. In this example, client device 128 is used by a patient to access patient portal 132. As illustrated in FIG. 1, data aggregator 105 generates patient portal 132 which may be, for example, a graphical user interface that when rendered on client device 128 renders visual representations of silos 134, 136, 138, 140, 142, 144. In particular, visual representations of the foregoing silos may be represented as virtual silos, including, for example, virtual silo 146, virtual silo 148, virtual silo 150, virtual silo 152, virtual silo 154, and virtual silo 156.
  • In the illustrative example of FIG. 1, virtual silo 146 pertains to registration data 116 and provides the user with a visual representation of silo 134. That is, virtual silo 146 corresponds to silo 134. Similarly, virtual silo 148 pertains to appointment data 118 and provides the user with a visual representation of silo 136. Virtual silos 150, 152, 154 and 156 each provide a user with visual representations of their respective silos in data repository 130.
  • In the illustrative example of FIG. 1, graphical user interface 132 displays data that is for a particular patient. That is, virtual silos 146, 148, 150, 152, 154, 156 display data that is particular to a specific patient. In this example, silos 134, 136, 138, 140, 142, 144 are silos that include contributing channel data for numerous patients including, for example, John Johnson and Sally Hayes in the foregoing example. Because silos 134, 136, 138, 140, 142, 144 include a particular type of contributing channel data for numerous patients, data aggregator 105 is configured to query each of these silos 134, 136, 138, 140, 142, 144 to obtain data that corresponds to the patient that is requesting patient portal 132.
  • For example, the user of client device 128 may be John Johnson. In this example, John Johnson accesses patient portal 132. To provide John Johnson access to patient portal 132, data aggregator 105 generates a graphical user interface that renders a visual representation of patient portal 132. In generating virtual silos 146, 148, 150, 152, 154, 156, data aggregator 105 queries silos 134, 136, 138, 140, 142, 144 for data associated and/or tagged with data specifying a patient name of John Johnson. Once data aggregator 105 has identified this data in the various silos 134, 136, 138, 140, 142, 144, data aggregator 105 is able to select this data from the various silos 134, 136, 138, 140, 142, 144 and make this data accessible through virtual silos 146, 148, 150, 152, 154, 156 in patient portal 132.
  • FIG. 2 illustrates a particular exemplary embodiment describe herein. FIG. 2 is a block diagram of components of system 100 for generating a patient portal.
  • Client devices 104, 106, 108, 110, 112, 114, 128 can be any sort of computing devices capable of taking input from a user and communicating over a network (not shown) with server 102 and/or with other client devices. For example, client devices 104, 106, 108, 110, 112, 114, 128 can be mobile devices, desktop computers, laptops, cell phones, personal digital assistants (“PDAs”), servers, embedded computing systems, and so forth.
  • In the exemplary embodiment of FIG. 2, server 102 can be any of a variety of computing devices capable of receiving data, such as a server, a distributed computing system, a desktop computer, a laptop, a cell phone, a rack-mounted server, and so forth. Server 102 may be a single server or a group of servers that are at a same location or at different locations.
  • The illustrated server 102 can receive data from client devices 104, 106, 108, 110, 112, 114, 128 via input/output (“I/O”) interface 200. I/O interface 200 can be any type of interface capable of receiving data over a network, such as an Ethernet interface, a wireless networking interface, a fiber-optic networking interface, a modem, and so forth. Server 102 also includes a processing device 202 and memory 204. A bus system 206, including, for example, a data bus and a motherboard, can be used to establish and to control data communication between the components of server 102.
  • The illustrated processing device 202 may include one or more microprocessors. Generally, processing device 202 may include any appropriate processor and/or logic that is capable of receiving and storing data, and of communicating over a network (not shown). Memory 204 can include a hard drive and a random access memory storage device, such as a dynamic random access memory, or other types of non-transitory machine-readable storage devices. As shown in FIG. 2, memory 204 stores computer programs that are executable by processing device 202. Among these computer programs is data aggregator 105.
  • Memory 204 is also configured to execute a processing engine (not shown). The processing engine is configured to perform pre-processing operations to prepare contributing channel data for processing by data aggregator 105 and/or to prepare data for processing and generating as cross-channel data, e.g., which is described in U.S. Ser. No. 13/159,155, the contents of which are incorporated herein by reference. As described in further detail below, the pre-processing operations include search engine indexing operations and generation of discrete data elements operations.
  • In another example, the processing engine may execute on client devices 104, 106, 108, 110, 112, 114, e.g., rather than or in addition to executing on server 110. In this example, a client device executes the processing engine to prepare contributing channel data for transfer to server 110. The processing engine uses data stored on the client device and/or retrieved by the client device and generates discrete data elements that may be transferred to server 110. That is, after the processing engine of the client device has generated the discrete data elements, the processing engine may contribute (e.g., transfer) the discrete data elements to data aggregator 105.
  • In an example, the processing engine receives data and generates discrete data elements by using a data filter to format data from a first data format to a second data format, for example, as described in U.S. Ser. No. 12/774,694, the entire contents of which are incorporated herein by reference. In still another example, the processing engine generates the discrete data elements by performing optical character recognition (“OCR”) on the contributing channel data.
  • In still another example, the processing engine (e.g., executing on a client device and/or on server 110) includes a search component (e.g., a search engine). The search component indexes the contributing channel data, e.g., that is stored in data repository 130, for example using indexing techniques that are well known in the art. In this example, the search component includes a spider (e.g., a web traversal portion of a search engine) that collects contributing channel data (e.g., discrete data elements) for indexing in data repository 130, e.g., as is commonly known in the art.
  • Through the search component, a user may search data repository 130 for a particular type of data (e.g., discrete data elements) and/or for data received from a particular type of contributing entity and/or for historic, live data, and so forth. In an example, a user may access the search component to search for patients having particular conditions. In another example, the user may access the search component to search for patients associated with particular medical codes and/or medical forms. In still another example, data aggregator 105 performs OCR on the received contributing channel data. In this example, the user may perform word searches in identifying different types of data.
  • FIG. 3A illustrates a particular exemplary embodiment describe herein. In particular, FIG. 3A is a flow chart of process 300 for updating data repository 130 with contributing channel data 116, 118, 120, 122, 124, 126. In operation, data aggregator 105 receives contributing channel data 116, 118, 120, 122, 124, 126 from contributing channels 104, 106, 108, 110, 112, 114. Data aggregator 105 tags (304) the received contributing channel data 116, 118, 120, 122, 124, 126 with a patient identifier identifying the patient associated with the received contributing channel data 116, 118, 120, 122, 124, 126.
  • For example, portions of the received contributing channel data 116, 118, 120, 122, 124, 126 include patient identifying information. Data aggregator 105 parses the received contributing channel data 116, 118, 120, 122, 124, 126 to identify the patient identifying information and to identify which portions of the received contributing channel data 116, 118, 120, 122, 124, 126 are associated with which portions of the patient identifying information. Using the correspondence between portion of the patient identifying information and other portions of the received contributing channel data 116, 118, 120, 122, 124, 126, data aggregator 105 tags the received contributing channel data 116, 118, 120, 122, 124, 126 with information specifying a correspondence between portions of the received contributing channel data 116, 118, 120, 122, 124, 126 and various patients.
  • Still referring to FIG. 3A, data aggregator 105 updates (306) data repository 130 with the received contributing channel data 116, 118, 120, 122, 124, 126. In the illustrative example of FIG. 1, where the received contributing channel data 116, 118, 120, 122, 124, 126 is stored in silos 134, 136, 138, 140, 142, 144, data aggregator 105 updates (308) silos 134, 136, 138, 140, 142 and 144 with the received contributing channel data 116, 118, 120, 122, 124, 126, which may be tagged as described in the foregoing example. For example, data aggregator 105 may determine which silo corresponds to a particular type of contributing channel data and update that silo by storing the received contributing channel data for that particular type in the appropriate silo. For example, received registration data 116 is stored (e.g., in real-time and automatically) in an appropriate silo, namely, silo 134, at least because silo 134 is configured to store registration data 116.
  • FIG. 3B illustrates a particular exemplary embodiment describe herein. In particular, FIG. 3B is a flow chart of process 350 for generating patient portal 132. In operation, data aggregator 105 receives (352) a request for patient portal 132, for example, by a user accessing a website that is associated with the patient portal and/or logging into a website that is associated with the patient portal. In response, data aggregator 105 parses (354) the request for patient portal 132. Using the results of parsing, data aggregator 105 determines (356) the patient identity of the patient that has requested the patient portal, for example, based on the user name and password information that the user used to log into the website. Data aggregator 105 queries (358) data repository 130 for contributing channel data associated with the identified patient. In particular, the data aggregator 105 may query silos 134, 136, 138, 140, 142, 144 for data associated with the patient that has requested patient portal 132.
  • In this example, data aggregator 105 determines from the request the name of the patient that has requested patient portal 132. Data aggregator 105 queries silos 134, 136, 138, 140, 142, 144 for data associated with the same patient name that was included in the request. In this example, silos 134, 136, 138, 140, 142, 144 may include tables of data with a portion of the table including the contributing channel data and with the other portion of the table associating the contributing channel data with a patient identifier, for example, the name of the patient. In this example, data aggregator 105 submits to silos 134, 136, 138, 140, 142, 144 the patient identifier. Using the patient identifier, data repository 130 determines contributing channel data that is tagged with information corresponding to the patient identifier and/or contributing channel data that is otherwise associated with the patient identifier (e.g., through the foregoing table).
  • Still referring to FIG. 3B, data aggregator 105 receives (360) from data repository 130 appropriate contributing channel data for the user requesting patient portal 132. Using the received contributing channel data, data aggregator 105 generates (362) patient portal 132, as described herein, for example, by generating virtual silos for each type of received contributing channel data (e.g., virtual silos 146, 148, 150, 152, 154, 156).
  • FIG. 4 illustrates a particular exemplary embodiment describe herein. In particular, FIG. 4 is an example of graphical user interface 400 included in patient portal 132. In the illustrative example of FIG. 4, data aggregator 105 generates virtual silos 402, 404, 406, 408, 410, 412, including, e.g., visual representations of silos 134, 136, 138, 140, 142, 144. In an example, data aggregator 105 is configured to dynamically and in real-time update visual representations of silos 134, 136, 138, 140, 142, 144, for example, based on newly received contributing channel data.
  • In the illustrative example of FIG. 4, virtual silo 402 providers a user with registration data 116, including, e.g., names of medical facilities with which the user is currently registered, forms that may be used by the user to register at additional medical facilities, and so forth. Virtual silo 404 provides the user with appointment data 118, including, e.g., medical appointments that the user has scheduled and/or needs to schedule. Virtual silo 406 provides the user with medical forms data 120, including, e.g., medical questionnaires for the user to fill out prior to an appointment with a physician, medical assessment forms for the user to fill out assist a physician and/or automated medical assessment system in diagnosing an ailment of the user, and so forth.
  • Virtual silo 408 provides the user with feedback data 122, including, e.g., online forms through which the user can submit feedback for a particular medical professional, medical facility, medical procedure, and so forth. Virtual silo 410 provides the user with education data 124, including, e.g., data pertaining to a physical ailment of the patient, data describing medical conditions, data describing various side-effects of a medication, and so forth. Virtual silo 412 provides the user with outcome data 126, including, e.g., data indicative of the outcome a medical procedure, such as whether the procedure was a success and/or a failure.
  • Graphical user interface 400 also includes portion 414 through which a user may access and view additional data that is specific to the user. In this illustrative example of FIG. 4, portion 414 includes a selectable link, selection of which causes data aggregator 105 to display the data that is specific to the user. Graphical user interface 400 also includes portion 416 for a user to login into patient portal 132. In an example, the user may log into the patient portal by entering into text boxes 418, 420, 422, 424 data identifying the user, including, e.g., first name data, last name data, date of birth data, and social security data. The user may also log into patient portal 132 via a user account that uniquely identifies the user. In the illustrative example of FIG. 4, the user enters the user account data into text boxes 426, 428.
  • FIG. 5 illustrates a particular exemplary embodiment describe herein. In particular, FIG. 5 is an example of graphical user interface 500 included in the patient portal. In the illustrative example of FIG. 5, graphical user interface 500 is generated by data aggregator 105 after the user logs into the patient portal. After the user logs into the patient portal, data aggregator 105 retrieves contributing channel data 502, 504, 506, 508, 510, 512 (e.g., from silos 134, 136, 138, 140, 142, 144) that is associated with the user.
  • In an example, data aggregator 105 is configured to retrieve contributing channel data 502, 504, 506, 508, 510, 512 in real-time from silos 134, 136, 138, 140, 142, 144. In this example, data aggregator 105 sends real-time requests to data repository 130 for contributing channel data 502, 504, 506, 508, 510, 512, for example, when the user log into patient portal 132. In this example, data aggregator 105 sends the user's login information to data repository 130 to promote an ability of data repository 130 to identify contributing channel data that is specific to the user (e.g., by identifying contributing channel data that is tagged with data corresponding to the login information) and to send this contributing channel data to data aggregator 105.
  • In the illustrative example of FIG. 5, at least a portion of contributing channel data 502, 504, 506, 508, 510, 512 includes selectable data, selection of which allows the user to view and to access a particular item of contributing channel data. In an example, a particular item of contributing channel data is juxtaposed to a link, selection of which allows the user to view the particular item of contributing channel data. Generally, juxtaposition includes a placement of an item of data in proximity to another item of data. In another example, virtual silos 402, 404, 406, 408, 410, 412 includes selectable areas, selection of which enables a user to view data included in the selected silo.
  • FIG. 6 illustrates a particular exemplary embodiment describe herein. In particular, FIG. 6 is an example of graphical user interface 600 included in patient portal. In the illustrative example of FIG. 6, the user has selected virtual silo 406 to view medical forms that are associated with the user.
  • In the illustrative example of FIG. 6, graphical user interface 600 includes menu area 602 that displays for the user the different types of medical forms that are associated with the user. Menu area 602 also includes data indicative of a completion status for each of the forms. In the illustrative example of FIG. 6, menu area 602 includes completion status indicators 604, 606, 608, 610. Completion status indicators 604, 606, 608, 610 provide the user with data specifying a status of a particular medical form, including, e.g., whether the medical form is complete, incomplete, and/or if no data has been provided for the medical form. In an example, visual representations 614, 616 are juxtaposed to completion status indicators 604, 606, 608, 610. Visual representations 614, 616 provide the user with a visual indicator (e.g., a check mark or other visual indicator) that a particular medical form has been completed by the user.
  • Graphical user interface 600 also includes portion 618 that provides the user with the contents of a selected form. In the illustrative example of FIG. 6, the user has selected medical history link 620. Accordingly, portion 618 is populated with data indicative of the medical history of the user.
  • FIG. 7 illustrates a particular exemplary embodiment describe herein. In particular, FIG. 7 is an example of graphical user interface 7 included in the patient portal. In FIG. 7, the user has selected another link in virtual silo 406. In the illustrative example of FIG. 7, the user has selected to view the dash form 704. In this example, selected medical form is incomplete, e.g., as indicated by completion status indicator 610. Accordingly, portion 702 is populated with contents of dash form 704 to assist the user in completing the form.
  • FIG. 8 illustrates a particular exemplary embodiment describe herein. In particular, FIG. 8 is an example of graphical user interface 800 included in patient portal 132. In the exemplary embodiment of FIG. 8, data aggregator 105 enables the patient to view physical notes and progress data, via, graphical user interface 800. In the illustrative example of FIG. 8, graphical user interface 800 includes virtual silos 402, 404, 406, 408, 410, 412. In the illustrative example of FIG. 8, the patient has selected area 802 to view the patient's personal records. The patient's personal record includes visual representation 804. Visual representation 804 includes a representation of the patient's first visit to a physician (and/or a medical facility), including a patient statement, the physician's findings, and the satisfaction level that has been indicated by the patient. Graphical user interface 800 also includes visual representation 806 which includes a visual representation of the dates of treatment for the patient (e.g., associated with the first visit) and an illustrative diagram of the areas of the patient's body in which the patient has received treatment.
  • Graphical user interface 800 also includes visual representation 808 that includes data indicative of a patient's second visit to the physician. Graphical user interface 800 also includes visual representation 810 including an additional visual representation of the treatment that the patient has received on a different date. Graphical user interface 800 also includes visual representation 812 including data indicative a patient's third visit to the physician.
  • In a variation of FIG. 8, a visual representation of trends over visits may be shown. Generally, trends over visits include information indicative of trends and/or progressions in patient health over a period of time and/or over a number of office visits. For example, if a patient has cholesterol measured each time the patient visits the physician, data aggregator 105 may be configured to generate a visual representation of the patient's cholesterol measurements over a period of time (e.g., for each of the office visits).
  • In still another configuration, data aggregator 105 is configured to identify stale data (e.g., in the silos) and to generate alerts to notify users of the stale data. Generally, stale data refers to data that is older than a predefined period of time. In an example, when a graphical user interface includes a visual representation of a silo, and that silo includes stale data, data aggregator 105 is configured to generate an alert to notify a viewer of the graphical user interface that at least a portion of the data is stale.
  • Data aggregator 105 is also configured to generate reminders (e.g., automated reminders) to notify users of the patient portal of upcoming appointments, of forms that need to be filled out and other tasks to be performed. In an example, users may set reminder dates for certain tasks and/or functionality that is provided through the patient portal.
  • Data aggregator 105 is also configured to provide semantic highlighting and semantic color coding for contributing channel data. For example, a particular type of contributing channel data may assigned a particular color (e.g., purple) and a different type of contributing channel data may be assigned another, different color (e.g., blue). The contributing channel is displayed in a graphical user interface in accordance with the assigned semantic color coding, e.g., to promote an ability of a user to visually identify certain types of contributing channel, e.g., based on the semantic color coding.
  • Embodiments can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. An apparatus can be implemented in a computer program product tangibly embodied or stored in a machine-readable storage device for execution by a programmable processor; and method actions can be performed by a programmable processor executing a program of instructions to perform functions by operating on input data and generating output. The embodiments described herein, and other embodiments of the invention, can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program can be implemented in a high-level procedural or object oriented programming language, or in assembly or machine language if desired; and in any case, the language can be a compiled or interpreted language.
  • Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. Computer readable media for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry. Any of the foregoing can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
  • To provide for interaction with a user, embodiments can be implemented on a computer having a display device, e.g., a LCD (liquid crystal display) monitor, for displaying data to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
  • Embodiments can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of embodiments, or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
  • The system and method or parts thereof may use the “World Wide Web” (Web or WWW), which is that collection of servers on the Internet that utilize the Hypertext Transfer Protocol (HTTP). HTTP is a known application protocol that provides users access to resources, which may be data in different formats such as text, graphics, images, sound, video, Hypertext Markup Language (HTML), as well as programs. Upon specification of a link by the user, the client computer makes a TCP/IP request to a Web server and receives data, which may be another Web page that is formatted according to HTML. Users can also access other pages on the same or other servers by following instructions on the screen, entering certain data, or clicking on selected icons. It should also be noted that any type of selection device known to those skilled in the art, such as check boxes, drop-down boxes, and the like, may be used for embodiments using web pages to allow a user to select options for a given component. Servers run on a variety of platforms, including UNIX machines, although other platforms, such as Windows 2000/2003, Windows NT, Sun, Linux, and Macintosh may also be used. Computer users can view data available on servers or networks on the Web through the use of browsing software, such as Firefox, Netscape Navigator, Microsoft Internet Explorer, or Mosaic browsers. The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
  • Other embodiments are within the scope and spirit of the description claims. Additionally, due to the nature of software, functions described above can be implemented using software, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations. The use of the term “a” herein and throughout the application is not used in a limiting manner and therefore is not meant to exclude a multiple meaning or a “one or more” meaning for the term “a.” Additionally, to the extent priority is claimed to a provisional patent application, it should be understood that the provisional patent application is not limiting but includes examples of how the techniques described herein may be implemented.
  • A number of exemplary embodiments of the invention have been described. Nevertheless, it will be understood by one of ordinary skill in the art that various modifications may be made without departing from the spirit and scope of the invention.

Claims (22)

What is claimed is:
1. A computer-implemented method comprising:
receiving, from a first plurality of contributing organizations, medical form data for a patient;
receiving, from a second plurality of contribution organizations, medical education data;
aggregating the medical form data received from the first plurality of contributing organizations;
aggregating the medical education data received from the second plurality of contributing organizations; and
generating data for a graphical user interface that when rendered on a display device comprises:
a first portion that specifies that the aggregated medical form data for the patient is viewable, with selection of the first portion causing a display of the aggregated medical form data when the aggregated medical form data is available; or
a second portion that specifies that the aggregated medical education data for the patient is viewable, with selection of the second portion causing a display of the aggregated medical education data when the aggregated medical education data is available.
2. The computer-implemented method of claim 1, wherein the aggregated medical form data comprises medical summary data for the patient.
3. The computer-implemented method of claim 1, wherein at least one of the first plurality of contributing organizations differs from at least one of the second plurality of contributing organizations
4. The computer-implemented method of claim 1, wherein the graphical user interface comprises a first graphical user interface and wherein the method further comprises:
generating data for a second graphical user interface that when displayed on the display device displays data indicative of a clinical visit summary that chronicles one or more visits of the patient over a period of time.
5. The computer-implemented method of claim 4, wherein the clinical visit summary comprises one or more visual representations of one or more dates of patient visits for the patient.
6. The computer-implemented method of claim 4, wherein the clinical visit summary further comprises a diagram of one or more areas of a body of the patient in which the patient has received treatment.
7. The computer-implemented method of claim 1, further comprising:
receiving a request for the graphical user interface; and
identifying, from the request, an identity of the patient.
8. The computer-implemented method of claim 7, wherein a user who submits the request differs from the patient.
9. The computer-implemented method of claim 7, further comprising:
querying, at least partly based on the identity of the user, a data repository for medical data associated with the patient.
10. The computer-implemented method of claim 1, wherein the data for the graphical user interface is generated in real-time.
11. A computer-implemented method comprising:
retrieving, from a data repository, aggregated medical form data for a patient and aggregated medical education data for the patient;
wherein the aggregated medical form data for the patient is based on medical data from a first plurality of contributing organizations that is aggregated and the aggregated medical education data for the patient is based on medical data from a second plurality of contributing organizations that is aggregated; and
generating data for a graphical user interface that when rendered on a display device comprises:
a first portion that specifies that the aggregated medical form data for the patient is viewable, with selection of the first portion causing a display of the aggregated medical form data when the aggregated medical form data is available; and
a second portion that specifies that the aggregated medical education data for the patient is viewable, with selection of the second portion causing a display of the aggregated medical education data when the aggregated medical education data is available.
12. The computer-implemented method of claim 11, wherein at least one of the first plurality of contributing organizations is a same contributing organization as at least one of the second plurality of contributing organizations.
13. The computer-implemented method of claim 11, wherein at least one of the first plurality of contributing organizations differs from at least one of the second plurality of contributing organizations.
14. The computer-implemented method of claim 11, wherein the graphical user interface comprises a first graphical user interface and wherein the method further comprises:
generating data for a second graphical user interface that when displayed on the display device displays data indicative of a clinical visit summary that chronicles one or more visits of the patient over a period of time.
15. The computer-implemented method of claim 14, wherein the clinical visit summary comprises one or more visual representations of one or more dates of patient visits for the patient.
16. The computer-implemented method of claim 14, wherein the clinical visit summary further comprises a diagram of one or more areas of a body of the patient in which the patient has received treatment.
17. An electronic system comprising:
one or more processors;
one or more machine-readable hardware storage devices storing instructions that are executable to cause the one or more processors to perform operations comprising:
retrieving, from a data repository, aggregated medical form data for a patient and aggregated medical education data for the patient;
wherein the aggregated medical form data for the patient is based on medical data from a first plurality of contributing organizations that is aggregated and the aggregated medical education data for the patient is based on medical data from a second plurality of contributing organizations that is aggregated; and
generating data for a graphical user interface that when rendered on a display device comprises:
a first portion that specifies that the aggregated medical form data for the patient is viewable, with selection of the first portion causing a display of the aggregated medical form data when the aggregated medical form data is available; and
a second portion that specifies that the aggregated medical education data for the patient is viewable, with selection of the second portion causing a display of the aggregated medical education data when the aggregated medical education data is available.
18. The electronic system of claim 17, wherein at least one of the first plurality of contributing organizations is a same contributing organization as at least one of the second plurality of contributing organizations.
19. The electronic system of claim 17, wherein at least one of the first plurality of contributing organizations differs from at least one of the second plurality of contributing organizations.
20. The electronic system of claim 17, wherein the graphical user interface comprises a first graphical user interface and wherein the method further comprises:
generating data for a second graphical user interface that when displayed on the display device displays data indicative of a clinical visit summary that chronicles one or more visits of the patient over a period of time.
21. The electronic system of claim 20, wherein the clinical visit summary comprises one or more visual representations of one or more dates of patient visits for the patient.
22. One or more machine-readable hardware storage devices storing instructions that are executable to cause one or more processors to perform operations comprising:
retrieving, from a data repository, aggregated medical form data for a patient and aggregated medical education data for the patient;
wherein the aggregated medical form data for the patient is based on medical data from a first plurality of contributing organizations that is aggregated and the aggregated medical education data for the patient is based on medical data from a second plurality of contributing organizations that is aggregated; and
generating data for a graphical user interface that when rendered on a display device comprises:
a first portion that specifies that the aggregated medical form data for the patient is viewable, with selection of the first portion causing a display of the aggregated medical form data when the aggregated medical form data is available; and
a second portion that specifies that the aggregated medical education data for the patient is viewable, with selection of the second portion causing a display of the aggregated medical education data when the aggregated medical education data is available.
US14/246,963 2011-07-12 2014-04-07 Patient portal Abandoned US20140222467A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/246,963 US20140222467A1 (en) 2011-07-12 2014-04-07 Patient portal
US14/321,098 US20140316816A1 (en) 2011-07-12 2014-07-01 Patient portal

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/181,461 US8630870B2 (en) 2011-07-12 2011-07-12 Patient portal
US14/104,349 US8762170B2 (en) 2011-07-12 2013-12-12 Patient portal
US14/246,963 US20140222467A1 (en) 2011-07-12 2014-04-07 Patient portal

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US14/104,349 Continuation US8762170B2 (en) 2011-07-12 2013-12-12 Patient portal

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/321,098 Continuation US20140316816A1 (en) 2011-07-12 2014-07-01 Patient portal

Publications (1)

Publication Number Publication Date
US20140222467A1 true US20140222467A1 (en) 2014-08-07

Family

ID=47519426

Family Applications (4)

Application Number Title Priority Date Filing Date
US13/181,461 Active 2032-02-22 US8630870B2 (en) 2011-07-12 2011-07-12 Patient portal
US14/104,349 Active US8762170B2 (en) 2011-07-12 2013-12-12 Patient portal
US14/246,963 Abandoned US20140222467A1 (en) 2011-07-12 2014-04-07 Patient portal
US14/321,098 Abandoned US20140316816A1 (en) 2011-07-12 2014-07-01 Patient portal

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US13/181,461 Active 2032-02-22 US8630870B2 (en) 2011-07-12 2011-07-12 Patient portal
US14/104,349 Active US8762170B2 (en) 2011-07-12 2013-12-12 Patient portal

Family Applications After (1)

Application Number Title Priority Date Filing Date
US14/321,098 Abandoned US20140316816A1 (en) 2011-07-12 2014-07-01 Patient portal

Country Status (1)

Country Link
US (4) US8630870B2 (en)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9767173B2 (en) 2012-10-22 2017-09-19 Workday, Inc. Systems and methods for interest-driven data sharing in interest-driven business intelligence systems
US9934299B2 (en) 2012-10-22 2018-04-03 Workday, Inc. Systems and methods for interest-driven data visualization systems utilizing visualization image data and trellised visualizations
US9824127B2 (en) 2012-10-22 2017-11-21 Workday, Inc. Systems and methods for interest-driven data visualization systems utilized in interest-driven business intelligence systems
US9405812B2 (en) 2012-10-22 2016-08-02 Platfora, Inc. Systems and methods for providing performance metadata in interest-driven business intelligence systems
US20140129255A1 (en) * 2012-11-02 2014-05-08 James Thomas Woodson Medical Information and Scheduling Communication
US9405811B2 (en) * 2013-03-08 2016-08-02 Platfora, Inc. Systems and methods for interest-driven distributed data server systems
US20140280367A1 (en) * 2013-03-14 2014-09-18 Sap Ag Silo-aware databases
US20150019256A1 (en) * 2013-07-15 2015-01-15 Covidien Lp Patient status update portal
US20150081318A1 (en) * 2013-09-17 2015-03-19 Ali Adel Hussam Claim-based Data Collection for Generating Insurance Reports
US9892178B2 (en) 2013-09-19 2018-02-13 Workday, Inc. Systems and methods for interest-driven business intelligence systems including event-oriented data
WO2015060893A1 (en) 2013-10-22 2015-04-30 Platfora, Inc. Systems and methods for interest-driven data visualization systems utilizing visualization image data and trellised visualizations
US10453562B2 (en) * 2014-05-08 2019-10-22 ProductVisionaries, LLC Consumer-oriented biometrics data management and analysis system
US20160180023A1 (en) * 2014-12-20 2016-06-23 My Info LLC Personal health care records aggregation
US9942747B2 (en) 2015-08-07 2018-04-10 At&T Mobility Ii Llc Dynamic utilization of services by a temporary device
US10171537B2 (en) * 2015-08-07 2019-01-01 At&T Intellectual Property I, L.P. Segregation of electronic personal health information
US9934304B2 (en) 2015-08-18 2018-04-03 Workday, Inc. Systems and methods for memory optimization interest-driven business intelligence systems
US20170316161A1 (en) * 2016-04-28 2017-11-02 Barry Corel Sudduth Automated system and method for content management and communication based on patient data
TWI596563B (en) * 2016-08-23 2017-08-21 Respirator use patient care records and out of assessment methods
US11616836B2 (en) 2019-04-30 2023-03-28 CommuniCare Technology, Inc. Multiplexing of dedicated communication channels for multiple entities
US11212346B1 (en) 2021-06-04 2021-12-28 CommuniCare Technology, Inc. Multiplexing of dedicated communication channels for multiple entities
US11645344B2 (en) 2019-08-26 2023-05-09 Experian Health, Inc. Entity mapping based on incongruent entity data
JP2023543716A (en) * 2020-09-18 2023-10-18 ライブランプ インコーポレーテッド Data analytics privacy platform with quantified re-identification risk

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060080142A1 (en) * 2004-10-12 2006-04-13 Judi Hart System for managing patient clinical data
US20070273517A1 (en) * 2006-05-26 2007-11-29 Navin Govind Apparatus and method for integrated healthcare management
US20080027752A1 (en) * 2006-07-31 2008-01-31 Giang Trieu Phan Physician reviewed portable and network accessed electronic medical record
US20100076786A1 (en) * 2008-08-06 2010-03-25 H.Lee Moffitt Cancer Center And Research Institute, Inc. Computer System and Computer-Implemented Method for Providing Personalized Health Information for Multiple Patients and Caregivers
US20100114836A1 (en) * 2008-10-17 2010-05-06 Oracle International Corporation Data decay management

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8073712B2 (en) * 1999-04-02 2011-12-06 Cybernet Systems Corporation Method for consolidating medical records through the world wide web
US20070198296A1 (en) * 2006-02-21 2007-08-23 Visiontree Software, Inc. Patient health management portal
US20090216562A1 (en) * 2008-02-22 2009-08-27 Faulkner Judith R Method and apparatus for accommodating diverse healthcare record centers
NZ707796A (en) * 2010-09-28 2016-11-25 Lifetime Health Diary Ltd Systems and methods for medical data collection and display

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060080142A1 (en) * 2004-10-12 2006-04-13 Judi Hart System for managing patient clinical data
US20070273517A1 (en) * 2006-05-26 2007-11-29 Navin Govind Apparatus and method for integrated healthcare management
US20080027752A1 (en) * 2006-07-31 2008-01-31 Giang Trieu Phan Physician reviewed portable and network accessed electronic medical record
US20100076786A1 (en) * 2008-08-06 2010-03-25 H.Lee Moffitt Cancer Center And Research Institute, Inc. Computer System and Computer-Implemented Method for Providing Personalized Health Information for Multiple Patients and Caregivers
US20100114836A1 (en) * 2008-10-17 2010-05-06 Oracle International Corporation Data decay management

Also Published As

Publication number Publication date
US8630870B2 (en) 2014-01-14
US20140100887A1 (en) 2014-04-10
US20130018671A1 (en) 2013-01-17
US8762170B2 (en) 2014-06-24
US20140316816A1 (en) 2014-10-23

Similar Documents

Publication Publication Date Title
US8762170B2 (en) Patient portal
Damarell et al. General practitioner strategies for managing patients with multimorbidity: a systematic review and thematic synthesis of qualitative research
US10311036B1 (en) Database management for a logical registry
US20210225469A1 (en) Systems and methods of aggregating healthcare-related data from multiple data centers and corresponding applications
US10339500B2 (en) Patient education modules
US9460267B2 (en) Generation and data management of a medical study using instruments in an integrated media and medical system
US20150269316A1 (en) Online Referring Service Provider Portal
US20150039343A1 (en) System for identifying and linking care opportunities and care plans directly to health records
US20100280838A1 (en) Coaching Engine for a Health Coaching Service
US20110184781A1 (en) Tracking of Patient Satisfaction Levels within a Healthcare Facility
JP2018511894A (en) Context-aware care flow engine, platform, apparatus, system, method and computer-readable medium
US20210295262A1 (en) Patient Outcome-Based Data Store
Del Fiol et al. Disseminating context-specific access to online knowledge resources within electronic health record systems
US11669352B2 (en) Contextual help with an application
US10740547B2 (en) Managing data relationships of customizable forms
US20120323601A1 (en) Distributed sharing of electronic medical records
US10055544B2 (en) Patient care pathway shape analysis
US20200118231A1 (en) Generating and Processing Medical Alerts for Re-admission Reductions
US20120316895A1 (en) Generating Cross-Channel Medical Data
US11488691B2 (en) Medical registries
US20120054628A1 (en) Top200RX
Mooney et al. The electronic patient record as a guarantor of personalised mental health care
Bohra et al. Impact of Social Networking Sites on Healthcare
CA2770795A1 (en) Patient outcome-based data store

Legal Events

Date Code Title Description
AS Assignment

Owner name: UNIVERSAL RESEARCH SOLUTIONS, LLC, MISSOURI

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HUSSAM, ALI ADEL;REEL/FRAME:032620/0631

Effective date: 20110712

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION