RU2748052C1 - Method and system for medical data exchange - Google Patents

Abstract

FIELD: computer engineering.

SUBSTANCE: invention relates to computer engineering. Computer-implemented method of exchanging medical data between the clinic, the patient and the insurance service, containing the stages at which: through the Electronic Health Records server (EHR server), the patient's medical data is requested from the medical information system of the clinic, wherein, when requesting the patient's medical data, patient identification codes (ID) and patient and clinic indexes are used; through the OneTimePassword server (OTP server), the requesting party is checked for authorized access to medical data; patient identification code (ID) from the original request with the corresponding identification data (ID) from the clinic medical information system are replaced; a request to the medical information system of the clinic containing only the patient ID used in the clinic is sent, wherein the transfer of the patient's personal data does not exchange; by means of the EHR server, the requested medical data is extracted from the medical information system of the clinic and sent to the requesting party via a secure communication channel.

EFFECT: increased security of the transfer of the patient's medical data.

4 cl, 2 dwg

Description

FIELD OF TECHNOLOGY

The present technical solution relates to the field of computing, in particular, to a method and system for the exchange of medical data between a clinic, a patient and an insurance service.

LEVEL OF TECHNOLOGY

From the prior art, a solution is known, selected as the closest analogue, RU 2299470 (C2), publ. 20.05.2007. In this solution, a database of medical data is created based on case histories and is constantly replenished in the process of information support for practitioners; identify informative indicators of the health status of patients based on the analysis by highly qualified specialists of case histories stored in medical databases; According to the revealed informative indicators, decisive rules are formed, which are models of causal relationships in time between the data of medical and biological research and an objective examination of patients and the biological age of patients, the state of health of patients, the prognosis of diseases or pathological processes expected in patients, the clinical diagnosis available in disease patients; equip the client nodes of practitioners with software tools that ensure the application of the formed decision rules for informational support of doctors, enter the patient's history data and the results of his medical and biological studies and objective examination on a specific client node, apply the appropriate decision rules in the client node so that, based on the entered data to establish the biological age of the patient, to assess the patient's state of health, taking into account his established biological age in three groups: healthy, belongs to the risk group and sick; to predict, when attributing a patient to a risk group, the course of a disease or a pathological process both in the early stages of the disease, and in case of already developed pathology, to make a clinical diagnosis when attributing a patient to a group of "sick", taking into account the nature and severity of changes in the main life support systems, individual characteristics of the organism and the constitutional factor of the patient.

The above solution known from the prior art is aimed at improving the accuracy of diagnostics by implementing the capabilities of a single information space, including the available information on case histories, data from medical and biological studies, data from an objective examination of patients, i.e. accumulated data of patient health indicators, on the basis of which a conclusion is made about the patient's health status and recommendations for his treatment

The proposed solution is aimed at eliminating the shortcomings of the current state of the art and differs from the previously known ones in that the proposed technical solution allows efficiently receiving and transmitting medical data of a patient in a safe mode.

SUMMARY OF THE INVENTION

The technical problem to be solved by the claimed solution is the creation of a computer-implemented method for the exchange of medical data between the clinic, the patient and the insurance service. Additional embodiments of the present invention are presented in the dependent claims.

The technical result is to improve the safety of the patient's medical data transmission.

The claimed result is achieved through the implementation of a computer-implemented method for the exchange of medical data between the clinic, the patient and the insurance service, containing the stages at which:

through the Electronic Health Records server (EHR-server) located in the information circuit of the clinic, they request the patient's medical data from the medical information system of the clinic, and when requesting the patient's medical data, patient identifiers (ID) and indexes of patients and clinics are used;

through the OneTimePassword server (OTP server), they check the validity of the transaction, namely, they check the requesting party for permitted access to medical data;

replacing patient identifiers (ID) from the initial request with the corresponding identifiers (ID) of data from the medical information system of the blade in order to match the patient in the medical information system of the clinic with the identifier (ID) of the patient in the insurance company;

send a request to the medical information system of the clinic, containing only the patient ID used in the clinic, and the transfer of the patient's personal data does not occur;

through the EHR server, the requested medical data is retrieved from the clinic's medical information system and sent to the requesting party via a secure communication channel.

The claimed technical result is also achieved through a system for the exchange of medical data between the clinic, the insurance service and the patient, made with the ability to implement the steps of the method according to claim 1 of the formula and containing the interrelated:

EHR-server located in the information circuit of the clinic and made with the ability to provide the patient's medical data from the medical information system of the clinic;

An OTP server configured to verify the identity of the user requesting the patient's medical data;

a user authentication server located on the EHR server, and allowing to authenticate users requesting medical data of a patient, subject to their successful verification by means of an OTP server;

caching EHR-server, made with the possibility of intermediate storage, aggregation and indexing of medical data on the clinic side.

In a particular implementation of the described system, the EHR server located in the information circuit of the clinic can be implemented as a physical server.

In another particular embodiment of the described system, the EHR server located in the information loop of the clinic can be implemented as a virtual server.

DESCRIPTION OF DRAWINGS

The implementation of the invention will be described in the following in accordance with the accompanying drawings, which are presented to explain the essence of the invention and in no way limit the scope of the invention. The following drawings are attached to the application:

FIG. 1 illustrates an example of medical data exchange.

FIG. 2 illustrates an example of a general arrangement of a computing device.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of an implementation of the invention, numerous implementation details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art how the present invention can be used, with or without these implementation details. In other instances, well-known techniques, procedures, and components have not been described in detail so as not to obscure the details of the present invention.

In addition, from the above presentation it will be clear that the invention is not limited to the above implementation. Numerous possible modifications, changes, variations and substitutions, while retaining the spirit and form of the present invention, will be apparent to those skilled in the art.

The proposed technical solution provides a safe and efficient exchange of medical data between the clinic, the patient and the insurance service. Additionally, the present technical solution can provide the exchange of medical data between patients, any healthcare institution, pharmaceutical companies, lead generation sites and other market participants.

The features of this technical solution in the implementation of the exchange of medical data are:

1. No need for a centralized storage of data from the parties involved in the exchange, since medical data continues to be stored locally where it was originally (in general, in the medical information system (MIS) of the Clinic);

2. Implementation of data transfer in anonymized form, that is, in a way in which metadata and the main data flow are transferred separately, and due to which there is no possibility of comparing the data flow and information about which person (patient) they belong to.

The present technical solution, in this case, acts as an element that plays the role of an entry point into the authentication and authorization processes of a third-party system to medical data stored on the Clinic's side.

The initial phase of interaction includes matching the identifiers of the entities to be exchanged. The present technical solution, namely the system for the exchange of medical data, on its side carries out the construction of a comparison index by preserving the relationship of the entities of one system with the entities of another system. The previously mentioned collation index is stored in a replicated distributed database for system resiliency.

This technical solution also acts as a multiplexer, allowing each system to operate with its own data identifiers when interacting.

The data provider (for example, the Clinic) can grant or deny access to entities participating in the data exchange by setting restrictions. When the entities participating in the exchange change, the system stores the hash of each transaction, guaranteeing the validity and immutability of the data.

When a request is fulfilled by a third-party system, the proposed system makes sure that there is appropriate access, replaces the identifiers and redirects the request to the MIS to obtain data.

Electronic Health Records server (EHR-server / EHR-server) on the MIS side searches, extracts and normalizes data, leaving only medical information in them. Personal information is not transferred outside the scope of the IIA. In this case, the MIS contour is understood as an information contour (for example, a clinic information contour). The MIS loop is a network perimeter, directly controlled by the institution in which it is located, and is part of the institution's information systems.

After data normalization, the hash is verified and depersonalized medical data is sent over a secure channel to the end user.

The medical data exchange system contains the following technical elements:

EHR-server located in the information circuit of the clinic and made with the ability to provide the patient's medical data from the medical information system of the clinic;

An OTP server configured to verify the identity of the user requesting the patient's medical data;

a user authentication server located on the EHR server, and allowing to authenticate users requesting medical data of a patient, subject to their successful verification by means of an OTP server;

caching EHR-server, made with the possibility of intermediate storage, aggregation and indexing of medical data on the clinic side.

Implementation of authentication.

When performing authentication (step 1), requests are made to the OTP server on the authentication server to verify the client (a client means both the client of the clinic and a third-party system, for example, an insurance company, or any other entity participating in the data exchange process).

In case of successful authentication, access keys are issued to the client.

At the 2nd step, a request is made to the authentication server to obtain an exchange token. In this case, the authentication server gives this access key to the EHR server to request authentication on the side of the EHR server.

At the 3rd step, a request is made to the EHR server to authenticate to the institution's database. The access key for this request is the "exchange token" obtained in step 2. If successful, this request returns a "client signature". The client saves the signature to facilitate client authentication on the EHR side, to avoid re-entering data.

When re-authenticating, the client has a "client signature" that is automatically sent in a request to the authentication server (step 1).

On the authentication server:

a hash is formed from the "client's signature", the server side of the password and the "salt" (the hash function input modifier - a data string that is passed to the hash function together with the input data array (preimage) to calculate the hash (image));

a request is sent to save the access keys to the EHR server (the hash is sent there). Since the EHR server previously issued a "client signature", it has a server password similar to the one on the authentication server. Next, the EHR server checks the passed hash for the access rights of this request and saves the access keys.

The authentication server returns access keys in response, allowing the user to make requests to the EHR server side. When re-authenticating, steps 2 and 3 are omitted.

The obtained access keys are used to establish a secure communication between the EHR server and the client.

The caching EHR server, from the client's point of view, acts as an EHR server (has a similar API and behavior), however, to obtain data, it contacts other EHR servers and aggregates them (for example, it combines the received data arrays and sorts them by the date the records were created) ... The caching EHR server also indexes the data to speed up search queries.

As an additional example of the implementation of the present technical solution, the following describes the data exchange process without technical artifacts such as SQL queries, file names, data transfer format, and others.

There are 3 parties involved in the data exchange process:

1. EHR (EHR) server - a server that provides the user application with the medical data of the user, whose identity is associated with the patient of the clinic. This server does not perform write operations (add, change or delete) to the MIS database - read only.

2. User application - the patient's mobile application and / or the patient's personal account.

3. Server of authorization.

In the closed circuit of the clinic, a DMZ server is allocated (Demilitarized Zone - a demilitarized zone, a DMZ server). It can be either a virtual server or a physical one. An EHR server is installed on the above server (for example, MedMe server).

When setting up technical elements, you need to do the following: get a public IP address; forward the port from the router to the DMZ (by default, this is port 9443); raise an uplink between the DMZ and the server with a copy of the central database of the medical information system.

For flexibility, it is possible to use a domain. In this case, an SSL certificate signed by the certification center is required. The domain or IP address is "hardcoded" into the internal configuration of the application (not transferred from the outside).

Authorization and authentication scheme.

User authorization (provision of access parameters) is performed on a separate authorization server, which may be located outside the closed loop. By default, GBooking / MedMe servers can be used. Access parameters are sent to the EHR server. According to these parameters, the application has access to data.

The authorization server implements the protocol for exchanging access parameters with the EHR (EHR) server. Within the framework of this protocol, the following RPC requests are sent from the authorization server to the side of the EHR (EHR) server:

embedded_storage.save_exchange_token;

embedded_storage.save_auth_info.

At the same time, the authorization server, if necessary, can be located on another infrastructure, incl. and on the infrastructure of the clinic itself.

Authorization is performed by sending an OTP (one-time password) message to the user's phone number. Thus, it is determined that the user's phone number really exists and belongs to this particular user.

Authentication (matching the user and patient account) is performed on the side of the EHR (EHR) server, where 2 authentication scenarios can be distinguished, namely primary authentication and re-authentication.

To save the mapping - pairs PublicID (public user ID issued by the authorization server), InternalID (private patient ID obtained from the MIS database) - sqlite db is used, located on the same server as the EHR server itself.

In case of re-authentication, “end-to-end” authorization occurs - access parameters are transmitted from the authorization server to the side of the EHR (EHR) server at the moment of authorization itself. Several strategies for matching a user profile to a patient's account are supported: Search by phone number and match by patient data (full name, gender, date of birth); Search by medical card number and match by phone number.

A matching strategy based on user data is required only if the user of the application is a patient of the clinic, but does not remember his medical record number.

FIG. 1, we can consider an example of an exchange of medical data, where the data available in the medical information system of the Clinic is requested by the Insurance company.

1. The insurance company requests access to medical data from the Clinic, while using its own identifiers (ID) of patients and clinics, for example, [ClinicID] _IGS or [PatientID] _IGS (and others). Due to the use of the identifier when requesting medical data, the transfer of personal data does not occur.

2. The validity of the transaction is checked (whether the recipient has access to the requested data). For example, a patient can share part of their electronic health record (EHR) data covered by their insurance program, but at the same time deny access to personal data in the EHR.

3. The identifiers (ID) and indexes from the original query are replaced with the corresponding IDs and data indexes from Klinka. The MIS database contains a table listing the patients of the clinic. Patient ID is a unique attribute of a patient in the patient table in the MIS database of the clinic, by which it is possible to distinguish one patient from another (due to the strict unique correspondence between the patient and his ID).

4. The request to the Clinic is modified and contains only the indexes used in the Clinic, due to which the transfer of personal data also does not occur.

5. At the final step, the requested medical data is retrieved from the MIS Clinic and sent to the insurance company via a secure channel (in the diagram, the IPSec protocol is used as an example of a specific implementation of this process). At this stage, there is also no transfer of personal data, since the data sent is not tied to a specific patient.

FIG. 2, a general diagram of a computing device (200) that provides data processing necessary for the implementation of the claimed solution will be presented.

In general, the device (200) contains components such as: one or more processors (201), at least one random access memory (202), data storage (203), input / output interfaces (204), input / output (205), networking (206).

The processor (201) of the device performs the basic computational operations necessary for the operation of the device (200) or the functionality of one or more of its components. The processor (201) executes the necessary computer readable instructions contained in the main memory (202).

The RAM module (202), as a rule, is made in the form of RAM and contains the necessary program logic that provides the required functionality.

The data storage medium (203) can be performed in the form of HDD-, SSD-disks, raid-array, network storage, flash memory, optical information storage devices (CD, DVD, MD, Blue-Ray disks), etc. The means (203) allows performing long-term storage of various types of information, for example, the aforementioned files with user data sets, a database containing records of time intervals measured for each user, user identifiers, etc.

Interfaces (204) are standard means for connecting and working with the server side, for example, USB, RS232, RJ45, LPT, COM, HDMI, PS / 2, Lightning, FireWire, etc.

The choice of interfaces (204) depends on the specific implementation of the device (200), which can be a personal computer, mainframe, server cluster, thin client, smartphone, laptop, etc.

A keyboard should be used as a means of data input / output (205) in any embodiment of a system that implements the described method. The hardware design of the keyboard can be any known: it can be either an integrated keyboard used on a laptop or netbook, or a stand-alone device connected to a desktop computer, server, or other computer device. In this case, the connection can be either wired, in which the connecting cable of the keyboard is connected to the PS / 2 or USB port located on the system unit of the desktop computer, or wireless, in which the keyboard exchanges data via a wireless communication channel, for example, a radio channel, with base station, which, in turn, is directly connected to the system unit, for example, to one of the USB ports. In addition to the keyboard, data input / output means can also be used: joystick, display (touch screen), projector, touchpad, mouse, trackball, light pen, speakers, microphone, etc.

Networking tools (206) are selected from a device that provides network reception and transmission of data, for example, an Ethernet card, WLAN / Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc. The means (205) provide the organization of data exchange via a wired or wireless data transmission channel, for example, WAN, PAN, LAN, Intranet, Internet, WLAN, WMAN or GSM.

The components of the device (200) are interfaced through a common data bus (210).

In the present application materials, the preferred disclosure of the implementation of the claimed technical solution has been presented, which should not be used as limiting other, particular embodiments of its implementation, which do not go beyond the scope of the claimed scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims (13)

1. A computer-implemented method of exchanging medical data between a clinic, a patient and an insurance service, containing the stages at which: through the Electronic Health Records server (EHR-server) located in the information circuit of the clinic, they request the patient's medical data from the medical information system of the clinic, and when requesting the patient's medical data, patient identifiers (ID) and indexes of patients and clinics are used; through the OneTimePassword server (OTP server), they check the validity of the transaction, namely, they check the requesting party for permitted access to medical data; replacing patient identifiers (ID) from the initial request with the corresponding identifiers (ID) of data from the medical information system of the clinic in order to match the patient in the medical information system of the clinic with the identifier (ID) of the patient in the insurance company; send a request to the medical information system of the clinic, containing only the patient ID used in the clinic, and the transfer of the patient's personal data does not occur; through the EHR server, the requested medical data is retrieved from the clinic's medical information system and sent to the requesting party via a secure communication channel. 2. System for the exchange of medical data between the clinic, the insurance service and the patient, made with the ability to implement the steps of the method according to claim 1, containing the interrelated: EHR-server located in the information circuit of the clinic and made with the ability to provide the patient's medical data from the medical information system of the clinic; An OTP server configured to verify the identity of the user requesting the patient's medical data; a user authentication server located on the EHR server and allowing to authenticate users requesting medical data of a patient, subject to their successful verification by means of an OTP server; caching EHR-server, made with the possibility of intermediate storage, aggregation and indexing of medical data on the clinic side. 3. The system according to claim 2, in which the EHR server located in the information loop of the clinic can be implemented as a physical server. 4. The system according to claim 2, in which the EHR server located in the information circuit of the clinic can be implemented as a virtual server.

Images