System and method for accessing and sharing medical records

Abstract

A system includes a memory and at least one processor to receive a request from a patient and create a profile for the patient in a database, the request comprising patient authentication information, transmit a request for healthcare data on behalf of the patient to at least one EHR system, the request having a particular application programming interface (API) format, receive a response to the request having the particular API format, the response comprising the healthcare data associated with the patient from the at least one EHR system, store the healthcare data associated with the patient from the at least one EHR system in the profile for the patient in the database, and transmit a representation of the healthcare data associated with the patient from the at least one EHR system.

Description

SYSTEM AND METHOD FOR ACCESSING AND SHARING MEDICAL RECORDSCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Application No. 63 / 626,700 filed January 30, 2024, entitled “System and Method for Accessing and Sharing Medical Records”, the disclosure of which is hereby incorporated herein by reference.BACKGROUND

[0002] Computing devices have gradually become ubiquitous and a part of daily life. Users of smartphones and tablets have access to a portable device that is capable of communicating with others, capable of executing applications, and capable of sending information to other devices and receiving information from other devices.

[0003] It is difficult for patients to obtain medical record information because it is stored in a plurality of different locations with a plurality of different medical record systems. Patients do not know where the medical record information is stored and do not have control over where the medical record information is stored. In addition, patients do not have the ability to easily obtain their medical record information and do not have control over the ability to share their medical record information with others. This is particularly a problem for dependents of patients and family members of patients.

[0004] It is with these issues in mind, among others, that various aspects of the disclosure were conceived.SUMMARY

[0005] According to one aspect, a system accessing and sharing medical records includes a client computing device and a server computing device. The server computing device obtains medical record information and healthcare data from at least one electronic health record (EHR) system. Each EHR system may have a proprietary format and may communicate in a particular format. Thus, the server computing device determines a particular communication format and communicates with each EHR system differently, c.g., using a particular web application programming interface (API). The server computing device may store the medical record information in a database and transmit the medical record information to the client computing device for display on the client computing device, hi one example, the client computing devicemay be a mobile computing device. A patient may view their medical record information using the client computing device and obtain dependent medical record information from the server computing device. In addition, the patient may grant others access to their medical record information such as a spouse, partner, child, or other recipient.

[0006] According to an aspect, a system includes a memory and at least one processor to receive a request from a patient and create a profile for the patient in a database, the request comprising patient authentication information, transmit a request for healthcare data on behalf of the patient to at least one EHR system, the request having a particular application programming interface (API) format, receive a response to the request having the particular API format, the response comprising the healthcare data associated with the patient from the at least one EHR system, store the healthcare data associated with the patient from the at least one EHR system in the profile for the patient in the database, and transmit a representation of the healthcare data associated with the patient from the at least one EHR system.

[0007] According to another aspect, a method includes receiving, by at least one processor, a request from a patient and creating a profile for the patient in a database, the request comprising patient authentication information, transmitting, by the at least one processor, a request for healthcare data on behalf of the patient to at least one EHR system, the request having a particular application programming interface (API) format, receiving, by the at least one processor, a response to the request having the particular API format, the response comprising the healthcare data associated with the patient from the at least one EHR system, storing, by the at least one processor, the healthcare data associated with the patient from the at least one EHR system in the profile for the patient in the database, and transmitting, by the at least one processor, a representation of the healthcare data associated with the patient from the at least one EHR system.

[0008] According to an additional aspect, a non-transitory computer-readable storage medium includes instructions stored thereon that, when executed by a computing device cause the computing device to perform operations, the operations including receiving a request from a patient and creating a profile for the patient in a database, the request comprising patient authentication information, transmitting a request for healthcare data on behalf of the patient to at least one EHR system, the request having a particular application programming interface (API) format, receiving a response to the request having the particular API format, the response comprising the healthcare data associated with the patient from the at least one EHR system,storing the healthcare data associated with the patient from the at least one EHR system in the profile for the patient in the database, and transmitting a representation of the healthcare data associated with the patient from the at least one EHR system.

[0009] These and other aspects, features, and benefits of the present disclosure will become apparent from the following detailed written description of the preferred embodiments and aspects taken in conjunction with the following drawings, although variations and modifications thereto may be effected without departing from the spirit and scope of the novel concepts of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings illustrate embodiments and / or aspects of the disclosure and, together with the written description, serve to explain the principles of the disclosure. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like elements of an embodiment, and wherein:

[0011] FIG. 1 is a block diagram of a system for accessing and sharing medical records according to an example embodiment.

[0012] FIG. 2 shows a block diagram of a server computing device of the system according to an example embodiment.

[0013] FIG. 3 illustrates a flowchart for accessing medical records according to an example embodiment.

[0014] FIG. 4 illustrates a relationship diagram associated with a database of the system according to an example embodiment.

[0015] FIG. 5 illustrates a flow diagram of the system according to an example embodiment.

[0016] FIG. 6 illustrates populating a user profile by the system according to an example embodiment.

[0017] FIG. 7 illustrates another flow diagram of the system according to an example embodiment.

[0018] FIG. 8 illustrates a flow diagram of the system according to an example embodiment.

[0019] FIG. 9 illustrates a block diagram of the system according to an example embodiment.

[0020] FIG. 10 illustrates another block diagram of the system according to an example embodiment.

[0021] FIG. 11 illustrates a block diagram of the system according to an example embodiment.

[0022] FIG. 12 illustrates a block diagram of the system according to an example embodiment.

[0023] FIG. 13 illustrates a patient / provider diagram of the system according to an example embodiment.

[0024] FIG. 14 illustrates a sequence diagram of the system according to an example embodiment.

[0025] FIG. 15 illustrates a block diagram of a computing device according to an example embodiment.DETAILED DESCRIPTION

[0026] Aspects of a system and method for accessing and sharing medical records includes a client computing device that is in communication with a server computing device via a communication network. The server computing device obtains medical record information such as healthcare data from at least one EHR system. Each EHR system may have a proprietary format and may communicate in a particular format. Thus, the server computing device determines a particular communication format and communicates with each EHR system differently, e.g., using a particular web application programming interface (API) to communicate with a particular server. The server computing device may store the medical record information in a database and transmit the medical record information to the client computing device for display on the client computing device. In one example, the client computing device may be a mobile computing device. A patient may view their medical record information using the client computing device and obtain dependent medical record information from the server computingdevice. In addition, the patient may grant others access to their medical record information such as a spouse, partner, child, or other recipient.

[0027] The system may include a memory and at least one processor to receive a request from a patient and create a profile for the patient in a database, the request comprising patient authentication information, transmit a request for healthcare data on behalf of the patient to at least one EHR system, the request having a particular application programming interface (API) format, receive a response to the request having the particular API format, the response comprising the healthcare data associated with the patient from the at least one EHR system, store the healthcare data associated with the patient from the at least one EHR system in the profile for the patient in the database, and transmit a representation of the healthcare data associated with the patient from the at least one EHR system.

[0028] The system is designed to assist patients in locating and matching optimal service providers with specific needs. The system may further allow service providers to obtain patient information and enable them to obtain insurance and personal information prior to a patient’s arrival at an appointment. The system further allows a patient to control what records are provided and provide a patient with the ability to send and store records associated with a particular profile. The system may also allow a person or patient to have access to information pertaining to dependents or those they may care for by allowing the person to register each dependent using their profile. The person or patient may receive notifications and updates associated with their dependents.

[0029] By obtaining medical health records in advance, service providers may be able to spend additional time with patients and may eliminate the concerns of duplicate records. As a result, the system can be used to allow service providers to provide exceptional care without the pressure of time constraints.

[0030] The system also solves problems related to security. It is known that there are challenges associated with data breaches in the health care industry. Data breaches may go undetected initially and may potentially cause irrefutable damage. Patients may end up losing trust in a service provider and this may lead to financial damage. The system discussed herein restricts unauthorized users from accessing records and adds audit trails. Even further, the system assists in eliminating the need to manually record, update, and store information as it may be stored electronically. As a result, the system can address issues associated with data loss, duplicaterecords, and security.

[0031] The system is based on confidentiality, integrity, and accessibility. The system further gives patients control of their records, while ensuring confidentiality of those same records being sent directly to the proper patient profile, thus eliminating third party vendors. Inaccuracy and record duplication will be reduced through use of the system to send and receive information directly from the source. The knowledge gained through patient control is enhanced and gives them the ability to access their records, updates, and future information via the internet at any time. The system works in conjunction with the objectives of Meaningful Use Stage 3 and the use of Certified EHR Technology to support coordination of care.

[0032] Stage 3 requirements include the protection of patient health information, electronic generation and transmission of prescriptions, support of clinical decisions, electronic order entries by providers to include, medication, lab, and diagnostic imaging orders, encouragement of patient interaction through electronic access, and compliance with the measures associated with care coordination. From patient engagement, physician education, and easy accessibility of their records through interaction with their EHR, patients receive reception of secure electronic communication from providers, and providers can gain access of their patient’s health data from wearable devices. Along with these objectives is health information exchange which requires fifty percent or more of referrals to exchange health care records, new patients to receive electronic documents more than forty percent of the time, and the use of electronic prescribing services eighty percent of the time. Lastly, public health and clinical data must be reported to three of the five available EHR registries. Through the incorporation of Stage 3, the system bridges the gaps between accessible health care data and information technology systems. The system is what healthcare needs to advance medical practice to a place of innovation, protection, and instant accessibility.

[0033] Figure 1 shows a block diagram of a computing system comprising a medical record system 100 according to an example embodiment. The medical record system 100 includes at least one client computing device 102 in communication with at least one server computing device 104 via a communication network 106. The at least one client computing device 102 and the at least one server computing device 104 may together provide and execute a medical record application 108. The client computing device 102 may execute a first client component of the medical record application 108 and the server computing device 104 may execute a second servercomponent of the medical record application 108. The server computing device 104 may be in communication with a relational database management system (RDBMS) or another type of database management system that stores and communicates data from at least one database 110.

[0034] The at least one database 110 may be a structured query language (SQL) database such as a MySQL database, a NoSQL database, or a MongoDB database, among others. The at least one database 110 may be integrated with the server computing device 104 or in communication with the server computing device 104.

[0035] The at least one database 110 may have one or more tables including a table that defines users including patients and providers, a table that stores information about an individual receiving / providing health care services, a table that defines a relationship between a user and a patient, a table that stores names associated with the patient / provider, a table that stores information for contact information for a person or organization, a table that stores information associated with an address for each individual patient or practitioner, a table that stores images associated with the patient / provider, a table that stores appointments for each patient / provider, a table associated with patient insurance plans, a table associated with storing information for practices, a table associated with storing information associated with facilities, a table that maps providers to particular facilities, a table that stores information associated with notifications, a table that stores information associated with audit notifications, a table that stores ratings and reviews information, a table that stores patient provider favorite information, a table that stores patient allergy intolerance information, a table that stores patient allergy category information, a table that defines relationships between a patient and EHR profiles, a table that stores patient medication information, and a table that stores patient medication code value information. Tn addition, the at least one database 110 may have one or more tables including a table that stores user type information, a table that stores contact type information, a table that stores contact point use information, a table that stores address information, a table that stores address type information, a table that stores language information such as a language spoken by each patient / provider, a table that stores marital status information associated with each patient, a table that stores appointment status for each appointment, a table that stores appointment type information for each appointment, a table that stores relationships between patients (e.g., spouse, child, father, mother), a table that stores profile information associated with each patient / provider (e.g., provider, staff, self, dependent), a table that stores notification types, a table that storesconsultation reason types, a table that stores patient EHR profile information, a table that stores patient allergy category information, a table that stores clinical status information, a table that stores patient allergy categories, a table that stores patient allergy reaction severities, a table that stores patient allergy reaction type information, and a table that stores EHR resource information, among others.

[0036] The at least one client computing device is configured to receive data from and / or transmit data to the at least one server computing device 104 through the communication network 106. Although the at least one server computing device 104 is shown as a single server computing device, it is contemplated that the at least one server computing device 104 may include multiple server computing devices, for example in a cloud computing configuration.

[0037] The communication network 106 can be the Internet, an intranet, or another wired or wireless communication network. For example, the communication network 106 may include a Mobile Communications (GSM) network, a code division multiple access (CDMA) network, 3rdGeneration Partnership Project (GPP) network, an Internet Protocol (IP) network, a wireless application protocol (WAP) network, a WiFi network, a Bluetooth network, a satellite communications network, or an IEEE 802.11 standards network, as well as various communications thereof. Other conventional and / or later developed wired and wireless networks may also be used.

[0038] The at least one client computing device 102 includes at least one processor to process data and memory to store data. The processor processes communications, builds communications, retrieves data from memory, and stores data to memory. The processor and the memory are hardware. The memory may include volatile and / or non-volatile memory, e.g., a computer- readable storage medium such as a cache, random access memory (RAM), read only memory (ROM), flash memory, or other memory to store data and / or computer-readable executable instructions such as a portion or a component of the medical record application 108. In addition, the at least one client computing device 102 further includes at least one communications interface to transmit and receive communications, messages, and / or signals.

[0039] The at least one client computing device 102 can be a laptop computer, a smartphone, a personal digital assistant, a tablet computer, a standard personal computer, or another processing device. The at least one client computing device 102 may include a display, such as a computer monitor, for displaying data and / or graphical user interfaces. The at least one client computingdevice 102 may also include a Global Positioning System (GPS) hardware device for determining a particular location of the client computing device 102, an input device, such as a camera, a keyboard or a pointing device (e.g., a mouse, trackball, pen, or touch screen) to enter data into or interact with graphical and / or other types of user interfaces. In an exemplary embodiment, the display and the input device may be incorporated together as a touch screen of the smartphone or tablet computer.

[0040] The at least one client computing device 102 may display on the display a graphical user interface (or GUI) to generate a graphical user interface on the display. The graphical user interface may be provided by the medical record application 108. The graphical user interface enables a user of the at least one client computing device 102 to interact with the medical record application 108.

[0041] The medical record application 108 may be a component of an application and / or service executable by the at least one client computing device 102 and / or the at least one server computing device 104. For example, the medical record application 108 may be a single unit of deployable executable code or a plurality of units of deployable executable code. According to one aspect, the medical record application 108 may include one component that may be a web application, a native application, and / or a mobile application (e.g., an app) downloaded from a digital distribution application platform that allows users to browse and download applications developed with mobile software development kits (SDKs) including the App Store and GOOGLE PLAY®, among others.

[0042] The at least one server computing device 104 includes at least one processor to process data and memory to store data. The processor processes communications, builds communications, retrieves data from memory, and stores data to memory. The processor and the memory are hardware. The memory may include volatile and / or non-volatile memory, e.g., a computer- readable storage medium such as a cache, random access memory (RAM), read only memory (ROM), flash memory, or other memory to store data and / or computer-readable executable instructions such as a portion or a component of the medical record application 108. In addition, the at least one server computing device 104 further includes at least one communications interface to transmit and receive communications, messages, and / or signals.

[0043] Figure 2 illustrates a block diagram of the server computing device 104 according to an example embodiment. The server computing device 104 includes at least one processor 202 andcomputer readable media (CRM) 204 in memory on which the medical record application 108 or other user interface or application is stored. The computer readable media may include volatile media, nonvolatile media, removable media, non-removable media, and / or another available medium that can be accessed by the processor. By way of example and not limitation, the computer readable media comprises computer storage media and communication media. Computer storage media includes non-transitory storage memory, volatile media, nonvolatile media, removable media, and / or non-removable media implemented in a method or technology for storage of information, such as computer / machine-readable / executable instructions, data structures, program modules, or other data. Communication media may embody computer / machine-readable / executable instructions, data structures, program modules, or other data and include an information delivery media or system, both of which are hardware.

[0044] The medical record application 108 may include a patient profile module 206 for creating an account to use the medical record application and an associated patient profile that may use the medical record application 108. As an example, a user or patient may use the client computing device 102 to create an account for use with the medical record application 108. The patient may provide username and password information and / or other alternative authentication information such as biometric information. The client computing device 102 may transmit the authentication information to the server computing device 104 and store the authentication information or a representation of the authentication information in the database 110. In addition, when setting up the patient profile or at another time, the patient may provide patient information including name information, birthdate information, address information, insurance information, and other unique identifying information. The patient information may be used to connect with and authenticate with at least one EHR system.

[0045] The medical record application 108 may include an EHR connection module 208 for connecting with at least one EHR system and obtaining medical record information from at the least one EHR system. As an example, the EHR connection module 208 may send patient information to the at least one EHR system using an application programming interface (API) call. Each EHR system may have a particular API format and the EHR connection module 208 may format each API call to the EHR system based on the particular API format. In one example, the API may be the Fast Healthcare Interoperability Resources (FHIR) API. The API may be a RESTful API and may provide Javascript Object Notation (JSON), Extensible Markup Language(XML), or Resource Description Framework (RDF) data representation, among others. The EHR connection module 208 may retrieve the medical record information from the at least one EHR system. The medical record information may be formatted in a particular format as provided by the at least one EHR system. The EHR connection module 208 may store the medical record information in the profile associated with the patient in the database 110.

[0046] The medical record application 108 may include a dependent module 210 for associating at least one dependent with the patient and connecting with the at least one EHR system and obtaining medical record information from the at least one EHR system for the at least one dependent. As an example, the patient may provide dependent information including dependent name information, dependent birthdate information, dependent address information, dependent insurance information, and other unique dependent identifying information. The dependent module 210 may use the dependent information to obtain the medical record information for the at least one dependent. The dependent module 210 may retrieve the medical record information from the at least one EHR system and store the medical record information associated with the at least one dependent in the database 110.

[0047] The medical record application 108 may include a sharing module 212 for allowing a patient to share medical record information with another person. As an example, the patient may desire to share their medical record information with a family member such as a spouse, partner, sibling, or child. The patient may grant the other person access to their medical record information using the sharing module 212.

[0048] In addition, the medical record application 108 includes a user interface module 214 for displaying a user interface on the display of the client computing device 102. As an example, the user interface module 21 generates a native and / or web-based graphical user interface (GUI) that accepts input and provides output viewed by users of the client computing device 102. The client computing device 102 may provide realtime automatically and dynamically refreshed medical record information. The user interface module 214 may send data to other modules of the medical record application 108 of the client computing device 102, and retrieve data from other modules of the medical record application 108 of the client computing device 102 asynchronously without interfering with the display and behavior of the user interface displayed by the client computing device 102.

[0049] Figure 3 illustrates a flowchart of a process 300 for accessing and sharing medical records,according to an example embodiment. In step 302, the server computing device 104 may receive a request from a patient using the client computing device 102. The patient may send a request to create a profile for the patient. The request may include patient authentication information. The server computing device 104 may create the profile and store profile information in the database 110. The patient authentication information may include username and / or password information. In addition, the patient authentication information may include patient information such as name information, birthdate information, address information, insurance information, and other unique identifying information. Next, in step 304, the server computing device 104 may transmit a request for healthcare data on behalf of the patient to at least one EHR system. The request may include patient information that may uniquely identify the patient.

[0050] Before sending the request for the healthcare data, the server computing device 104 may determine the at least one EHR system based on the patient information. The request that is sent to each EHR system may have a particular application programming interface (API) format. In step 306, the server computing device 104 may receive a response to the request that is sent to the at least one EHR system. The response may include the healthcare data associated with the patient. The healthcare data may be sent in the particular API format and in addition, the healthcare data from each EHR system may be different and formatted in a particular way for the EHR system.

[0051] In step 308, the server computing device 104 may store the healthcare data associated with the patient from the at least one EHR system with the profile for the patient in the database 110. In step 310, the server computing device 104 transmits a representation of the healthcare data associated with the patient from the at least one EHR system to the client computing device 102. The client computing device 102 may display the representation of the healthcare data associated with the patient from the at least one EHR system.

[0052] Additionally, the server computing device 104 may determine a healthcare provider for the patient based on the profile for the patient and the patient data. The server computing device 104 may transmit a request on behalf of the patient to determine the healthcare provider for the patient.

[0053] Additionally, the patient may add one or more dependents to the profile for the patient. The server computing device 104 may receive at least one dependent associated with the patient and store the at least one dependent with the profile for the patient in the database 110. The server computing device 104 may receive dependent information from the patient for the at least onedependent, the dependent information comprising dependent name information, dependent birthday information, dependent address information, dependent insurance information, and dependent unique identifier information and store the dependent information with the profile for the patient in the database 110.

[0054] Even further, the patient may share a representation of the healthcare data associated with the patient. The patient may share the representation of the healthcare data with a spouse, a partner, a family member, or a child, among other recipients. The spouse, partner, family member, or child may use the medical record application 108 on their client computing device and / or may view the representation of the healthcare data using a browser or another application.

[0055] Figure 4 illustrates a relationship diagram associated with the database 110 according to an example embodiment. As shown in Figure 4, each user may have a number of profiles that may be associated with patients, providers, and staff. Each patient may have a patient insurance plan. Each provider and staff may have associated facilities and practices. In addition, each profile may have profile related entities including appointments, attachments, addresses, contact points, and names. In addition, each profile may have patient allergy intolerance information, patient allergy categories, and patient allergy reactions.

[0056] A sign-in user interface may be provided by the medical record application 108 and the client computing device 102. A sign-up user interface may be provided by the medical record application 108 and the client computing device 102. A sign-in / sign-up selection initial user interface may be provided by the medical record application 108 and the client computing device 102. A one-time-use password user interface may be provided by the medical record application 108 and the client computing device 102. A patient and dependent user interface may be provided by the medical record application 108 and the client computing device 102.

[0057] A health provider or physician user interface may be provided by the medical record application 108 and the client computing device 102. A My Doctors user interface may be provided by the medical record application 108 and the client computing device 102. A doctor search user interface may be provided by the medical record application 108 and the client computing device 102. An advanced doctor search may be provided by the medical record application 108 and the client computing device 102. An account information user interface may be provided by the medical record application 108 and the client computing device 102. An account information user interface may be provided by the medical record application 108 and theclient computing device 102. An add provider user interface may be provided by the medical record application 108 and the client computing device 102.

[0058] A dependent user interface may be provided by the medical record application 108 and the client computing device 102. An insurance user interface may be provided by the medical record application 108 and the client computing device 102. A record search user interface may be provided by the medical record application 108 and the client computing device 102. An account information user interface may be provided by the medical record application 108 and the client computing device 102. A medical record detail user interface may be provided by the medical record application 108 and the client computing device 102. A sending patient information user interface may be provided by the medical record application 108 and the client computing device 102. A prescriptions screen user interface may be provided by the medical record application 108 and the client computing device 102.

[0059] An alerts and diagnoses user interface may be provided by the medical record application 108 and the client computing device 102. An alerts and diagnoses detail user interface may be provided by the medical record application 108 and the client computing device 102. A mailbox user interface may be provided by the medical record application 108 and the client computing device 102. A sign- in or register user interface may be provided by the medical record application 108 and the client computing device 102. A patient web / provider register portal user interface may be provided by the medical record application 108 and the client computing device 102. An encounters patient web portal / provider register user interface may be provided by the medical record application 108 and the client computing device 102. An add documents web portal / provider register user interface may be provided by the medical record application 108 and the client computing device 102. A messages patient web / provider register portal user interface may be provided by the medical record application 108 and the client computing device 102.

[0060] Figure 5 illustrates a flow diagram 3600 of the system 100 according to an example embodiment. As shown in Figure 5, a provider 1 and a provider 2 may store information in the database 110 associated with a combined record in a user profile that may be accessed by a user using the client computing device 102.

[0061] Figure 6 illustrates a flow diagram 3700 of populating a user profile by the system 100 according to an example embodiment. As shown in Figure 6, the database 110 may have billing information, medical information, and reporting and storage.

[0062] Figure 7 illustrates another flow diagram 3800 of the system 100 according to an example embodiment. As shown in Figure 7, a patient may send API credentials to the server computing device 102 and the server computing device 104 may verify the API request and retrieve the requested records from an EHR using the API request.

[0063] Figure 8 illustrates a flow diagram 3900 of the system 100 according to an example embodiment. As shown in Figure 8, a user may create a profile and may choose one or more EHRs. The user may provide API credentials and the credentials may be sent to the server computing device 104. The server computing device 104 may obtain information from EHR 1, EHR 2, and EHR 3 using API requests.

[0064] Figure 9 illustrates a block diagram 4000 of the system 100 according to an example embodiment. As shown in Figure 9, the system infrastructure may include direct trust information and clinical summaries information. The system may communicate with external endpoints such as accredited HISPs. In one or more embodiments, the system 100 employs a network of HISPs to facilitate the secure exchange of the healthcare data. Each HISP may act as a trusted intermediary, ensuring that data is transmitted securely between the system 100 and external endpoints, such as medical and / or healthcare researchers. The HISPs may operate within a framework of direct trust, leveraging a network of trust anchors to authenticate and authorize data exchanges. These trust anchors ensure that only verified HISP members can participate in data sharing, maintaining data integrity and confidentiality.

[0065] In one or more embodiments, the healthcare data (pulled from disparate EHRs) of multiple patients are aggregated in the database 110 (as depicted in FIG. 1) of the MatchRite Infrastructure. In one or more embodiments, the healthcare data is pseudonymized and / or anonymized and placed into a portion of the database designated as a research pool. In one or more embodiments, the healthcare data is accessible as read-only data so that the healthcare data stored in the database 110 cannot be altered by authorized third parties. The aggregated healthcare data may be stored in a cloud-based Database as a Service (DBaaS) environment, offering scalable and flexible storage solutions. This architecture supports the dynamic nature of healthcare data, accommodating varying data volumes and types. Alternatively or additionally, the system 100 provides access to the aggregated healthcare data using a Data as a Service (DaaS) model, allowing for the seamless integration of structured and unstructured data across various formats and standards. In one or more embodiments, the system 100 is configured to apply data normalization and standardizationprocesses to ensure consistency and usability of the data, including using standards such as HL7, FHIR, LOINC, or the like. The system 100 may also be configured to employ encryption protocols and access controls to safeguard patient data, including role-based access controls. This allows restricted data access to authorized personnel only, such as by researchers with granted access based on predefined roles and permissions, ensuring that data privacy is maintained.

[0066] The aggregated healthcare data forms a research pool, which is accessible to authorized researchers and healthcare professionals. The research pool enables a wide range of analytical and research activities, including clinical trials, population health studies, and personalized medicine initiatives. Researchers can access the data via a secure web-based portal or through API endpoints, which provide programmatic access to the data. The system 100 may be configured to include various data query and retrieval mechanisms, allowing researchers to extract relevant datasets using advanced search and filtering capabilities.

[0067] Figure 10 illustrates another block diagram 4100 of the system 100 according to an example embodiment. As shown in Figure 10, a user may create a profile and may choose one or more EHRs. The user may provide API credentials and the credentials may be sent to the server computing device 104. The server computing device 104 may obtain information from EHR 1, EHR 2, and EHR 3 using API requests. In addition, the server computing device 104 may update one or more records in the EHR 1, EHR 2, and EHR 3 using API requests.

[0068] Figure 11 illustrates a block diagram 4200 of the system 100 according to an example embodiment. As shown in Figure 11, the user may use the client computing device 102 to allow providers to retrieve patient records, sort patient records, and import combined patient records into their own EHR.

[0069] Figure 12 illustrates a block diagram 4300 of the system 100 according to an example embodiment. As shown in Figure 12, the user may use the client computing device 102 to allow providers to retrieve patient records, send patient records, and import patient records into their own EHR. In addition, the user may verify, authorize, and import patient provided information into their own EHR.

[0070] Figure 13 illustrates a patient / provider diagram 4400 of the system 100 according to an example embodiment. Figure 13 shows an example of telemedicine provided by the system according to an example embodiment.

[0071] Figure 14 illustrates a sequence diagram 4500 of the system 100 according to an example embodiment. Figure 14 illustrates a sequence of a patient creating a profile and tagging a provider. Next, a notification may be sent to the provider that indicates that the patient tagged the provider. Clinical staff may send one or more secure messages to the patient. The patient can reply or send a message for service or may send an appointment request. The provider may send a request confirmation or denial. The patient also may send a refill request for medication. The provider may respond with a confirmation or a denial. The provider may send a care plan to the patient and the patient may send a message to a care team associated with the provider.

[0072] In addition, as shown in Figure 14, the clinical staff may view information in an EHR associated with the patient and may make changes to the EHR on behalf of the patient.

[0073] Figure 15 illustrates an example computing system 4600 that may implement various systems, such as the client computing device 102 and the server computing device 104, and the methods discussed herein, such as process 300. A general purpose computer system 4600 is capable of executing a computer program product to execute a computer process. Data and program files may be input to the computer system 4600, which reads the files and executes the programs therein such as the medical record application 108. Some of the elements of a general purpose computer system 4600 are shown in Figure 15 wherein a processor 4602 is shown having an input / output (RO) section 4604, a central processing unit (CPU) 4606, and a memory section 4608. There may be one or more processors 4602, such that the processor 4602 of the computer system 4600 comprises a single central-processing unit 4606, or a plurality of processing units, commonly referred to as a parallel processing environment. The computer system 4600 may be a conventional computer, a server, a distributed computer, or any other type of computer, such as one or more external computers made available via a cloud computing architecture. The presently described technology is optionally implemented in software devices loaded in memory 4608, stored on a configured DVD / CD-ROM 4610 or storage unit 4612, and / or communicated via a wired or wireless network link 4614, thereby transforming the computer system 4600 in Figure 15 to a special purpose machine for implementing the described operations.

[0074] The memory section 4608 may be volatile media, nonvolatile media, removable media, non-removable media, and / or other media or mediums that can be accessed by a general purpose or special purpose computing device. For example, the memory section 4608 may include non- transitory computer storage media and communication media. Non-transitory computer storagemedia further may include volatile, nonvolatile, removable, and / or non-removable media implemented in a method or technology for the storage (and retrieval) of information, such as computer / machine-readable / executable instructions, data and data structures, engines, program modules, and / or other data. Communication media may, for example, embody computer / machine- rcadablc / cxccutablc, data structures, program modules, algorithms, and / or other data. The communication media may also include an information delivery technology. The communication media may include wired and / or wireless connections and technologies and be used to transmit and / or receive wired and / or wireless communications.

[0075] The I / O section 4604 is connected to one or more user-interface devices (e.g., a keyboard 4616 and a display unit 4618), a disc storage unit 4612, and a disc drive unit 4620. Generally, the disc drive unit 4620 is a DVD / CD-ROM drive unit capable of reading the DVD / CD-ROM medium 4610, which typically contains programs and data 4622. Computer program products containing mechanisms to effectuate the systems and methods in accordance with the presently described technology may reside in the memory section 4604, on a disc storage unit 4612, on the DVD / CD-ROM medium 4610 of the computer system 4600, or on external storage devices made available via a cloud computing architecture with such computer program products, including one or more database management products, web server products, application server products, and / or other additional software components. Alternatively, a disc drive unit 4620 may be replaced or supplemented by another storage medium drive unit. The network adapter 4624 is capable of connecting the computer system 4600 to a network via the network link 4614, through which the computer system can receive instructions and data. Examples of such systems include personal computers, Intel or PowerPC -based computing systems, AMD-based computing systems, ARM-based computing systems, and other systems running a Windows-based, a UNIX-based, or other operating system. It should be understood that computing systems may also embody devices such as Personal Digital Assistants (PDAs), mobile phones, tablets or slates, multimedia consoles, gaming consoles, set top boxes, etc.

[0076] When used in a LAN-networking environment, the computer system 4600 is connected (by wired connection and / or wirelessly) to a local network through the network interface or adapter 4624, which is one type of communications device. When used in a WAN-networking environment, the computer system 4600 typically includes a modem, a network adapter, or any other type of communications device for establishing communications over the wide area network.In a networked environment, program modules depicted relative to the computer system 4600 or portions thereof, may be stored in a remote memory storage device. It is appreciated that the network connections shown are examples of communications devices for and other means of establishing a communications link between the computers may be used.

[0077] In an example implementation, source code executed by the client computing device 102, the server computing device 104, a plurality of internal and external databases, source databases, and / or cached data on servers are stored in memory of the client computing device 102, memory of the server computing device 104, or other storage systems, such as the disk storage unit 4612 or the DVD / CD-ROM medium 4610, and / or other external storage devices made available and accessible via a network architecture. The source code executed by the client computing device 102 and the server computing device 104 may be embodied by instructions stored on such storage systems and executed by the processor 4602.

[0078] Some or all of the operations described herein may be performed by the processor 4602, which is hardware. Further, local computing systems, remote data sources and / or services, and other associated logic represent firmware, hardware, and / or software configured to control operations of the medical record system 100 and / or other components. Such services may be implemented using a general purpose computer and specialized software (such as a server executing service software), a special purpose computing system and specialized software (such as a mobile device or network appliance executing service software), or other computing configurations. In addition, one or more functionalities disclosed herein may be generated by the processor 4602 and a user may interact with a Graphical User Interface (GUI) using one or more user-interface devices (e.g., the keyboard 4616, the display unit 4618, and the user devices 4604) with some of the data in use directly coming from online sources and data stores. The system set forth in Figure 15 is but one possible example of a computer system that may employ or be configured in accordance with aspects of the present disclosure.

[0079] In the present disclosure, the methods disclosed may be implemented as sets of instructions or software readable by a device. Further, it is understood that the specific order or hierarchy of steps in the methods disclosed are instances of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the method can be rearranged while remaining within the disclosed subject matter. The accompanying method claims present elements of the various steps in a sample order, and are not necessarily meant to belimited to the specific order or hierarchy presented.

[0080] The described disclosure may be provided as a computer program product, or software, that may include a non-transitory machine-readable medium having stored thereon executable instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A non-transitory machine-readable medium includes any mechanism for storing information in a form (c.g., software, processing application) readable by a machine (e.g., a computer). The non-transitory machine -readable medium may include, but is not limited to, magnetic storage medium, optical storage medium (e.g., CD-ROM); magneto-optical storage medium, read only memory (ROM); random access memory (RAM); erasable programmable memory (e.g., EPROM and EEPROM); flash memory; or other types of medium suitable for storing electronic executable instructions.

[0081] The description above includes example systems, methods, techniques, instruction sequences, and / or computer program products that embody techniques of the present disclosure. However, it is understood that the described disclosure may be practiced without these specific details.

[0082] It is believed that the present disclosure and many of its attendant advantages will be understood by the foregoing description, and it will be apparent that various changes may be made in the form, construction and arrangement of the components without departing from the disclosed subject matter or without sacrificing all of its material advantages. The form described is merely explanatory, and it is the intention of the following claims to encompass and include such changes.

[0083] While the present disclosure has been described with reference to various embodiments, it will be understood that these embodiments arc illustrative and that the scope of the disclosure is not limited to them. Many variations, modifications, additions, and improvements are possible. More generally, embodiments in accordance with the present disclosure have been described in the context of particular implementations. Functionality may be separated or combined in blocks differently in various embodiments of the disclosure or described with different terminology. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure as defined in the claims that follow.

Claims

CLAIMS:

1. A system comprising: a memory; and at least one processor to: receive a request from a patient and create a profile for the patient in a database, the request comprising patient authentication information, the patient authentication information comprising patient name information, patient birthday information, patient address information, patient insurance information, and patient unique identifier information and store the patient authentication information with the profile for the patient in the database; transmit a first request for healthcare data on behalf of the patient to at least one first electronic health record (EHR) system, the request having a first particular application programming interface (API) format; receive a first response to the first request having the particular API format, the first response comprising the healthcare data associated with the patient from the at least one first electronic health record (EHR) system; store the healthcare data associated with the patient from the at least one first electronic health record (EHR) system in the profile for the patient in the database; transmit a second request for healthcare data on behalf of the patient to at least one second electronic health record (EHR) system, the second request having a second particular application programming interface (API) format that is different than the first particular application programming interface (API) format; receive a second response to the second request having the second particular API format, the second response comprising the healthcare data associated with the patient from the at least one second electronic health record (EHR) system; store the healthcare data associated with the patient from the at least one second electronic health record (EHR) system in the profile for the patient in the database; andtransmit a representation of the healthcare data associated with the patient from the at least one first electronic health record (EHR) system and from the at least one second electronic health record (EHR).

2. The system of claim 1, the at least one processor further to determine a healthcare provider for the patient based on the profile for the patient.

3. The system of claim 1, the at least one processor further to transmit the representation of the healthcare data associated with the patient from the at least one first electronic health record (EHR) system and the at least one second electronic health record (EHR) to a client computing device for display on a user interface.

4. The system of claim 1, the at least one processor further to determine the at least one first electronic health record (EHR) system based on the patient authentication information.

5. The system of claim 1, the at least one processor further to receive at least one dependent associated with the patient and store the at least one dependent with the profile for the patient in the database.

6. The system of claim 5, the at least one processor further to receive dependent information from the patient for the at least one dependent, the dependent information comprising dependent name information, dependent birthday information, dependent address information, dependent insurance information, and dependent unique identifier information and store the dependent information with the profile for the patient in the database.

7. The system of claim 1, the at least one processor further to share a representation of the healthcare data associated with the patient.

8. The system of claim 1, the at least one processor further to receive health data from the patient, wherein the health data is generated from a wearable device associated with the patient.

9. The system of claim 1, the at least one processor further to: store healthcare data on a portion of the memory in association with healthcare data of a plurality of other patients, the portion of the memory being a database storing a research pool of healthcare data, receive one or more requests from a device associated with an authorized endpoint for readonly access to at least a portion of the research pool of healthcare data, and transmit the portion of the research pool of healthcare data to the device associated with the authorized endpoint.

10. The system of claim 1, the at least one processor further to: receive an indication representative of a tagged provider from the patient; transmit an indication representative of the patient tagging the tagged provider to a provider computing device associated with the tagged provider; receive a confirmation from the provider computing device associated with the patient; store the tagged provider in association with the patient in the profile for the patient; and transmit to the provider computing device a representation of the healthcare data associated with the patient from the at least one first electronic health record (EHR) system and from the at least one second electronic health record (EHR).

11. A method comprising: receiving, by at least one processor, a request from a patient and creating a profile for the patient in a database, the request comprising patient authentication information, the patient authentication information from the patient, the patient authentication information comprising patient name information, patient birthday information, patient address information, patient insurance information, and patient unique identifier information and store the patient authentication information with the profile for the patient in the database; transmitting, by the at least one processor, a first request for healthcare data on behalf of the patient to at least one first electronic health record (EHR) system, the first request having a first particular application programming interface (API) format; receiving, by the at least one processor, a first response to the first request having the first particular API format, the first response comprising the healthcare data associated with the patient from the at least one first electronic health record (EHR) system; storing, by the at least one processor, the healthcare data associated with the patient from the at least one first electronic health record (EHR) system in the profile for the patient in the database; transmitting, by the at least one processor, a second request for healthcare data on behalf of the patient to at least one second electronic health record (EHR) system, the second request having a second particular application programming interface (API) format; receiving, by the at least one processor, a second response to the second request having the second particular API format, the second response comprising the healthcare data associated with the patient from the at least one second electronic health record (EHR) system; storing, by the at least one processor, the healthcare data associated with the patient from the at least one second electronic health record (EHR) system in the profile for the patient in the database; and transmitting, by the at least one processor, a representation of the healthcare data associated with the patient from the at least one first electronic health record (EHR) system and from the at least one second electronic health record (EHR).

12. The method of claim 11, further comprising determining a healthcare provider for the patient based on the profile for the patient.

13. The method of claim 11, further comprising transmitting the representation of the healthcare data associated with the patient from the at least one first electronic health record (EHR) system and the at least one second electronic health record (EHR) to a client computing device for display on a user interface.

14. The method of claim 11, further comprising determining the at least one first electronic health record (EHR) system and the at least one second electronic health record (EHR) based on the patient authentication information.

15. The method of claim 11, further comprising receiving at least one dependent associated with the patient and storing the at least one dependent with the profile for the patient in the database.

16. The method of claim 15, further comprising receiving dependent information from the patient for the at least one dependent, the dependent information comprising dependent name information, dependent birthday information, dependent address information, dependent insurance information, and dependent unique identifier information and storing the dependent information with the profile for the patient in the database.

17. The method of claim 11, further comprising sharing a representation of the healthcare data associated with the patient.

18. A non-transitory computer-readable storage medium, having instructions stored thereon that, when executed by a computing device cause the computing device to perform operations, the operations comprising: receiving a request from a patient and creating a profile for the patient in a database, the request comprising patient authentication information, the patient authentication information from the patient, the patient authentication information comprising patient name information, patient birthday information, patient address information, patient insurance information, and patient unique identifier information and store the patient authentication information with the profile for the patient in the database; transmitting a first request for healthcare data on behalf of the patient to at least one first electronic health record (EHR) system, the first request having a first particular application programming interface (API) format; receiving a first response to the first request having the first particular API format, the first response comprising the healthcare data associated with the patient from the at least one first electronic health record (EHR) system; storing the healthcare data associated with the patient from the at least one first electronic health record (EHR) system in the profile for the patient in the database; transmitting a second request for healthcare data on behalf of the patient to at least one second electronic health record (EHR) system, the second request having a second particular application programming interface (API) format; receiving a second response to the second request having the second particular API format, the second response comprising the healthcare data associated with the patient from the at least one second electronic health record (EHR) system; storing the healthcare data associated with the patient from the at least one second electronic health record (EHR) system in the profile for the patient in the database; and transmitting a representation of the healthcare data associated with the patient from the at least one first electronic health record (EHR) system and from the at least one second electronic health record (EHR).

19. The non-transitory computer-readable storage medium of claim 18, the operations further comprising determining a healthcare provider for the patient based on the profile for the patient.

20. The non-transitory computer-readable storage medium of claim 18, the operations further comprising transmitting the representation of the healthcare data associated with the patient from the at least one first electronic health record (EHR) system and the at least one second electronic health record (EHR) to a client computing device for display on a user interface.

Images