Data sharing system and data sharing method

Abstract

To enable the sharing of various information about health acquired from a plurality of types of applications with medical institutions.SOLUTION: A data sharing system that shares data between a plurality of types of applications for acquiring data about health of a patient and a medical institution terminal for browsing the data, comprises: a storage section that manages, in association with at least one application, a linkage between a first account ID which allows the patient to access the data sharing system and a second account ID which allows a user of the medical institution terminal to access the data sharing system; and a control section that identifies, in response to a request from the medical institution terminal, the data acquired by the application associated with the first account ID linked with the second account ID corresponding to the medical institution terminal.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a data sharing system and the like. [Background technology]

[0002] In recent years, a system has been proposed in which a medical institution and a patient associated with the medical institution share information about the patient via a server or the like. For example, Patent Document 1 discloses a patient information sharing server and a patient information sharing method for sharing patient information between a medical institution and a patient. Specifically, it discloses that the patient information sharing server assigns a patient identifier to each patient, associates the patient identifier with a medical institution designated by the patient, receives information entered by the patient in response to a notification from the medical institution to the patient from a terminal held by the patient, and stores the input information as patient information in association with the patient identifier. However, Patent Document 1 does not disclose a method for holding multiple types of applications related to the patient's health and sharing various types of health-related information acquired from the multiple applications with medical institutions. [Prior art documents] [Non-patent literature]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2019-191765 Summary of the Invention [Problem to be solved by the invention]

[0004] The present invention was made based on the above-mentioned technical background, and one of its objectives is to provide a data sharing method that enables various health-related information obtained from multiple types of applications to be shared with medical institutions. [Means for solving the problem]

[0005] According to a first aspect of the present invention, a data sharing system that shares data between multiple types of applications for acquiring data related to a subject's health and a medical institution terminal for viewing the data includes a memory unit that manages the association between a first account ID for the subject to access the data sharing system and a second account ID for the user of the medical institution terminal to access the data sharing system, in association with at least one application, and a control unit that, in response to a request from the medical institution terminal, identifies data acquired by the application associated with the first account ID that is associated with the second account ID corresponding to the medical institution terminal. According to a second aspect of the present invention, a data sharing method for a data sharing system that shares data between multiple types of applications for acquiring data related to a subject's health and a medical institution terminal for viewing the data manages the association between a first account ID for the subject to access the data sharing system and a second account ID for the user of the medical institution terminal to access the data sharing system in association with at least one application, and identifies, in response to a request from the medical institution terminal, the data acquired by the application associated with the first account ID associated with the second account ID corresponding to the medical institution terminal. [Effects of the Invention]

[0006] According to the present invention, it is possible to share data related to the subject's health between multiple applications for acquiring the data and a medical institution terminal for viewing the data. Furthermore, a first account ID for the subject to access the data sharing system and a second account ID for the user of the medical institution terminal to access the data sharing system are associated with at least one application and managed. Therefore, in response to a request from a medical institution, data related to a specific application can be identified based on the association of the managed account IDs. Furthermore, by identifying the data, the data can be provided to the medical institution. [Brief explanation of the drawings]

[0007] [Figure 1] 10 is a flowchart showing an example of the flow of a data sharing method according to the present embodiment. [Figure 2] FIG. 1 is a diagram showing an example of a system configuration of an information system according to a first embodiment. [Figure 3] FIG. 2 is a diagram showing an example of functions realized by a control unit of the management server according to the first embodiment. [Figure 4] FIG. 3 is a diagram showing an example of information stored in a storage unit of a management server according to the first embodiment. [Figure 5] FIG. 2 is a diagram showing an example of PHR user account registration data according to the first embodiment. [Figure 6] FIG. 2 is a diagram showing an example of PHR medical institution account registration data according to the first embodiment. [Figure 7] FIG. 2 is a diagram showing an example of PHR application registration data according to the first embodiment. [Figure 8] FIG. 2 is a diagram showing an example of account ID / PHR application linkage management data according to the first embodiment. [Figure 9] FIG. 2 is a diagram showing an example of PHR application data management data according to the first embodiment. [Figure 10] FIG. 3 is a diagram showing an example of functions realized by a control unit of the subject terminal according to the first embodiment. [Figure 11] FIG. 3 is a diagram showing an example of information stored in a storage unit of a subject terminal according to the first embodiment. [Figure 12] FIG. 3 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the first embodiment. [Figure 13] FIG. 3 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the first embodiment. [Figure 14] FIG. 3 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the first embodiment. [Figure 15] FIG. 3 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the first embodiment. [Figure 16] FIG. 3 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the first embodiment. [Figure 17]FIG. 4 is a diagram showing an example of a screen displayed on a display unit of the medical institution terminal according to the first embodiment. [Figure 18] FIG. 10 is a diagram showing another example of a screen displayed on the display unit of the medical institution terminal according to the first embodiment. [Figure 19] 4 is a flowchart showing an example of the flow of processing executed by each device according to the first embodiment. [Figure 20] 4 is a flowchart showing an example of the flow of processing executed by each device according to the first embodiment. [Figure 21] FIG. 10 is an explanatory diagram of a data sharing method according to a first modified example. [Figure 22] FIG. 10 is an explanatory diagram of a data sharing method according to a first modified example. [Figure 23] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the first modified example. [Figure 24] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the first modified example. [Figure 25] 10 is a flowchart showing an example of the flow of processing executed by each device according to a first modified example. [Figure 26] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the first modified example. [Figure 27] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the first modified example. [Figure 28] 10 is a flowchart showing an example of the flow of processing executed by each device according to a first modified example. [Figure 29] FIG. 10 is a diagram showing an example of information stored in a storage unit of a medical institution terminal according to a first modified example. [Figure 30] FIG. 10 is a diagram showing an example of PHR application patient identification data according to the first modified example. [Figure 31] FIG. 10 is a diagram showing an example of the system configuration of an information system according to a second embodiment. [Figure 32] FIG. 10 is a diagram showing an example of functions realized by a control unit of a medical institution server according to a second embodiment. [Figure 33] FIG. 10 is a diagram showing an example of information stored in a storage unit of a medical institution server according to a second embodiment. [Figure 34]FIG. 10 is a diagram showing an example of EMR account registration data according to the second embodiment. [Figure 35] FIG. 10 is a diagram showing an example of EMR patient information management data according to the second embodiment. [Figure 36] FIG. 10 is a diagram showing an example of PHR / EMR association registration data according to the second embodiment. [Figure 37] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the second embodiment. [Figure 38] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the second embodiment. [Figure 39] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of a medical institution terminal according to the second embodiment. [Figure 40] 10 is a flowchart showing an example of the flow of processing executed by each device according to the second embodiment. [Figure 41] 10 is a flowchart showing an example of the flow of processing executed by each device according to the second embodiment. [Figure 42] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of each terminal according to a second modified example. [Figure 43] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of each terminal according to a second modified example. [Figure 44] 10 is a flowchart showing an example of the flow of processes executed by each device according to a second modified example. [Figure 45] FIG. 10 is a diagram showing an example of a screen displayed on a display unit of each terminal according to a second modified example. [Figure 46] 10 is a flowchart showing an example of the flow of processes executed by each device according to a second modified example. [Figure 47] FIG. 11 is a diagram showing another example of EMR patient information management data according to the second modified example. [Figure 48] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the third embodiment. [Figure 49] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the third embodiment. [Figure 50] 10 is a flowchart showing an example of the flow of processing executed by each device according to the third embodiment. [Figure 51]FIG. 13 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the fourth embodiment. [Figure 52] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of each terminal according to the fourth embodiment. [Figure 53] 10 is a flowchart showing an example of the flow of processing executed by each device according to the fourth embodiment. [Figure 54] FIG. 13 is a diagram showing an example of PHR / EMR association registration data according to the fifth embodiment. [Figure 55] 13 is a flowchart showing an example of the flow of processing executed by each device according to the fifth embodiment. [Figure 56] 13 is a flowchart showing an example of the flow of processing executed by each device according to the fifth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0008] An embodiment for carrying out a data sharing method and the like according to the present disclosure will be described with reference to the drawings. In the description of the drawings, the same elements are denoted by the same reference numerals, and duplicated descriptions may be omitted. Furthermore, the components described in this embodiment are merely examples and are not intended to limit the scope of the present invention.

[0009] The information system 1 according to this embodiment is an information system for sharing health-related data obtained from multiple applications used by multiple subjects between, for example, multiple subjects and multiple medical institutions (medical professionals). The information system 1 may also be called, for example, a data sharing system.

[0010] Hereinafter, an application for collecting, recording, reviewing, and sharing health-related data will be referred to as a PHR (Personal Health Record) application. Health-related data will be referred to as PHR data. PHR data may include, for example, various health-related information (e.g., medication records, activity records, etc.), life logs such as blood pressure, weight, number of steps, sleep, and diet, and data generated by medical institutions that have consented to its use by other businesses or for purposes other than medical care. PHR data may also include data in any data format, such as text data, numeric data, moving images, and still images.

[0011] Hereinafter, a subject who uses a PHR application may be referred to simply as a "user." A subject may also be referred to as a "patient." In addition, allowing users of medical institutions (e.g., medical professionals) to view (and potentially edit) their own PHR data using a PHR application, etc., is sometimes referred to as "PHR data integration," "PHR application integration," or "PHR data sharing."

[0012] A platform that manages accounts and PHR data in various PHR applications in an integrated manner is sometimes called a PHR platform.

[0013] Users who can use the PHR platform are not limited to subjects and medical institutions. For example, the platform may be available to subjects and businesses that handle the subjects' PHR data (e.g., care workers, teachers in special needs classes, and trainers at sports gyms).

[0014] In the following, for example, an electronic medical record application that a user of a medical institution intends to use mainly within the medical institution will be referred to as an EMR (Electronic Medical Record) application. In this specification, EMR applications may include not only diagnostic information contained in electronic medical records, but also test information (blood test results, test images, etc.), patient background and basic information (medical history, blood pressure, weight, etc.), and prescription information (medical procedures, medications, etc.), and may also include the concept of EHR (Electronic Health Record) applications that are intended to share information with external medical institutions.

[0015] In the following, an application for managing data mainly acquired by a medical institution may be called an EMR application, and an application for managing data mainly acquired by a subject may be called a PHR application.

[0016] In this specification, the information system 1 may be configured to include, for example, a plurality of devices. The information system 1 may be, for example, a system in which a plurality of devices cooperate to perform some kind of processing.

[0017] Furthermore, the information system 1 relating to clients (client devices) and servers may be, for example, a system including at least one terminal and at least one server, and one example of this may be a client-server system.

[0018] The server may be a single device or a combination of multiple devices (server system). The server functions may be provided in the form of PaaS, IaaS, or SaaS in cloud computing.

[0019] The information system 1 may be a system made up of multiple terminals. This system can be, for example, the following system. A system that gives server functions to terminals (distributed system). This can be realized, for example, using blockchain technology. A system in which terminals communicate wirelessly with each other. This can be achieved, for example, by using short-range wireless communication technology such as Bluetooth (registered trademark) to communicate in a P2P (peer-to-peer) format.

[0020] PHR data collected from multiple PHR applications allows medical institutions and patients to have a comprehensive view of their medical information, but managing PHR applications and PHR data can be complex for both medical institutions and patients. For example, in the diagnosis and treatment of ASD, subjects use their device to input PHR data such as activity records, medication records, weight, and height into applications specialized for each data type. Medical institutions can use PHR data such as the subject's activity records, medication records, and weight and height as reference material for ASD diagnosis and treatment plans, enabling more comprehensive diagnosis and selection of appropriate treatment methods. However, without a means to centrally manage and share these PHR applications and PHR data, data analysis and comparison becomes difficult, potentially reducing the efficiency and accuracy of diagnosis and treatment. Therefore, there is a need for an efficient method for sharing PHR data between multiple applications.

[0021] In addition, PHR data may be entered manually by the subject, or may be automatically recorded or provided by a third party and registered in the PHR application. For example, the subject's device may continuously measure the subject's number of steps and automatically record the data in the PHR application. The subject's device may also receive the subject's prescription information from a doctor or pharmacist and automatically record the data in the PHR application.

[0022] First, the data sharing method according to this embodiment will be described with reference to FIG. In this embodiment, data relating to the subject's health is shared between multiple types of applications for acquiring the data and a medical institution terminal for viewing the data. This data sharing method may be performed by a data sharing system (hereinafter sometimes referred to as the "sharing system").

[0023] Specifically, the system manages the association between a first account ID used by a subject to access the shared system and a second account ID used by a user of a medical institution terminal to access the shared system, in association with at least one application (S1).

[0024] Then, a request is accepted from the medical institution terminal (S3). Specifically, for example, a request for data associated with the first account ID linked with the second account ID corresponding to the user of the medical institution terminal (for example, a request for providing data) is accepted.

[0025] Then, in response to a request from the medical institution terminal, the data acquired by the application associated with the first account ID linked to the second account ID corresponding to the medical institution terminal is identified (S5). By identifying this data, it becomes possible to provide the data to the medical institution terminal. Although details will be described later, the data may be provided mainly by the shared system, or by a party other than the shared system.

[0026] In addition, step S2 (e.g., a step of registering data regarding the subject's health in a shared system) may be provided between steps S1 and S3 as a step of registering data regarding the subject's health in association with the first account ID and the application that acquired the data. In this case, steps S1 and S2 may be performed in any order, or may be performed simultaneously.

[0027] The sharing system may be, for example, a system configured with one or more management devices (for example, one or more server devices). The sharing system may be considered as a system that manages the sharing of data related to the health of subjects.

[0028] An embodiment for realizing the above data sharing method will now be described in detail.

[0029] <First Example> The first embodiment is an embodiment in which PHR data recorded using multiple types of PHR applications on a subject terminal used by a subject can be viewed on a medical institution terminal used by a medical institution using a PHR platform. The contents described in the first embodiment can be similarly applied to any of the other embodiments and other modified examples.

[0030] <System configuration> 2 is a diagram showing an example of the system configuration of the information system 1 in this embodiment. In the information system 1, for example, a management server 10 of a PHR platform, one or more subject terminals 20 (20A, 20B, 20C, ...), and one or more medical institution terminals 30 (30A, 30B, 30C, ...) are connected via a network 40.

[0031] In the following description, the user of subject terminal 20A communicating with management server 10 is referred to as "user UA," the user of subject terminal 20B as "user UB," the user of subject terminal 20C as "user UC," and so on. In the following description, the user of the medical institution terminal 30A communicating with the management server 10 will be referred to as "medical institution HA," the user of the medical institution terminal 30B as "medical institution HB," the user of the medical institution terminal 30C as "medical institution HC," and so on.

[0032] The management server 10 is, for example, an information processing device owned by a business operator that operates a PHR platform, and has a function of providing, for example, collection and recording of PHR data and linkage of PHR data in multiple types of PHR applications to subject terminals 20 and the like via a network 40. The management server 10 may be an example of a shared system, and may be a single or multiple server devices as described above. The business that operates the PHR platform may be the business that develops and operates the PHR application, or may be a business that cooperates with the business that develops and operates the PHR application.

[0033] Subject terminal 20 may be, for example, a smartphone, a tablet terminal, a personal computer, a smartwatch, etc. Subject terminal 20A, subject terminal 20B, and subject terminal 20C may have the same configuration, for example. Hereinafter, the terminal used by user X may be referred to as subject terminal 20X, as necessary.

[0034] The same may be applied to the medical institution terminal 30.

[0035] The network 40 serves to connect the devices that make up the information system 1 and provide connection paths so that data can be sent and received. The network 40 may be, for example, a wide area network such as the Internet that is made up of wired and wireless networks.

[0036] [Hardware configuration of each device] (1) Hardware configuration of the device FIG. 2 shows an example of the hardware configuration of subject terminal 20. As shown in FIG. The subject terminal 20 includes, for example, a control unit 21 including a CPU and the like, a storage unit 28 including RAM, ROM and the like, a communication unit 22 with wired and wireless communication functions, an input / output unit 23 including a device for inputting various operations to the subject terminal 20 and a device for outputting processing results processed by the subject terminal 20, a clock unit 29A including a clock using a crystal oscillator or a clock conforming to the NITZ (Network Identity and Time Zone) standard and the like, and a position calculation information detection unit 29B including a sensor and a unit for calculating the position of the subject terminal 20 using a satellite positioning system such as the GNSS (Global Navigation Satellite System). The hardware components of the subject terminal 20 are interconnected via, for example, a bus B. Note that the subject terminal 20 may be configured so that individual components or multiple components can be removed.

[0037] For example, the input / output unit 23 includes a display unit 24 configured with a liquid crystal display, an OELD, or the like, a sound input unit 25 configured with a microphone, a sound output unit 26 configured with a speaker, or the like, and an imaging unit 27 configured with a camera, or the like.

[0038] The same may be applied to the medical institution terminal 30.

[0039] (2) Server hardware configuration FIG. 2 shows an example of the hardware configuration of the management server 10. As shown in FIG. The management server 10 includes, for example, a control unit 11 including a CPU or the like, a memory unit 15 including RAM, ROM, a magnetic disk, or a semiconductor drive, a communication unit 14 with wired or wireless communication functions, an input / output unit 12 including a keyboard or the like, a display unit 13 such as an LCD display, and a clock unit 19 including a clock using a crystal oscillator, an NITZ clock, or the like. The hardware components of the management server 10 are connected to each other, for example, via a bus B. Note that the hardware of the management server 10 may be configured so that individual components or multiple components can be removed.

[0040] (3) Other At least a part of the processing in management server 10 and / or subject terminal 20 and / or medical institution terminal 30 may be realized by cloud computing consisting of one or more computers. At least a part or all of the processing performed by subject terminal 20 and / or medical institution terminal 30 may be performed by management server 10. Conversely, at least a part or all of the processing in management server 10 may be performed by subject terminal 20 and / or medical institution terminal 30. Unless explicitly stated otherwise, the judgment configuration in the embodiments of the present disclosure is not required, and a predetermined process may be performed when the judgment condition is met, or when the judgment condition is not met.

[0041] [Functional configuration of each device] (1) Functional configuration of the management server FIG. 3 is a diagram showing an example of functions realized by the control unit 11 of the management server 10 in this embodiment. The control unit 11 includes, as a functional unit, a PHR application management processing unit 111 that executes PHR application management processing (which may also be called PHR platform management processing) in accordance with a PHR application management processing program 151 stored in the storage unit 15, for example.

[0042] FIG. 4 is a diagram showing an example of information stored in the storage unit 15 of the management server 10 in this embodiment. The memory unit 15 stores, for example, a PHR application management processing program 151, PHR user account registration data 153, PHR medical institution account registration data 155, PHR application registration data 157, and account ID / PHR application linkage management data 159.

[0043] The PHR user account registration data 153 is registration data related to the subject's account on the PHR platform, and an example of the data configuration is shown in FIG. The PHR user account registration data 153 stores, for example, a user name, a user account ID, and other registration information in association with each other.

[0044] The user name is the name of the account of the subject terminal 20 that uses the PHR platform, and for example, the name that the user of the subject terminal 20 registers when using the PHR platform is stored.

[0045] The user account ID is information used to identify the subject's account in the PHR platform. This user account ID is preferably a unique value for each account, and is set and stored by the management server 10 as a unique value for each account, for example. The user account ID is information associated with the subject terminal 20 or the user of the subject terminal 20, and may be an example of information related to the terminal or information related to the user of the terminal. The user account ID may also be a first account ID. This first account ID may be an example of an ID used by the subject (or the subject terminal 20) to access the shared system. In addition, when identification information for identifying the subject terminal 20 and the user account ID are uniquely linked, the user account ID may be said to be identification information of the subject terminal 20.

[0046] Other registration information may include various types of information such as user information (address, birthday, gender, etc.), identification information for identifying the subject terminal 20 (IMEI (International Mobile Equipment Identity), etc.), the telephone number (terminal telephone number) of the subject terminal 20, email address (terminal email address), and authentication information such as passwords (login password, authentication password, etc.) used for various authentications in the PHR platform and applications.

[0047] The PHR medical institution account registration data 155 is registration data related to the accounts of medical institutions participating in the PHR platform, and an example of the data configuration is shown in FIG. The PHR medical institution account registration data 155 stores, for example, the name of the medical institution, the medical institution account ID, and other registration information in association with each other.

[0048] The medical institution name is the name of the account of the medical institution terminal 30 that uses the PHR platform, and for example, the name that the medical institution that uses the medical institution terminal 30 registers when using the PHR platform is stored.

[0049] The medical institution account ID is information used to identify the medical institution's account in the PHR platform. This medical institution account ID is preferably a unique value for each account, and is set and stored as a unique value (proper value) for each account by the management server 10, for example. The medical institution account ID is information associated with the medical institution terminal 30 or the medical institution of the medical institution terminal 30, and may be an example of information related to the terminal or information related to the medical institution. The medical institution account ID may also be a second account ID. This second account ID may be an example of an ID used by a user of the medical institution terminal 30 (or the medical institution terminal 30) to access the shared system.

[0050] Other registered information may include various types of information such as medical institution information (address, main contact information, location information, medical specialty, etc.), identification information for identifying the medical institution terminal 30 (IMEI (International Mobile Equipment Identity), etc.), telephone number (terminal telephone number) of the medical institution terminal 30, email address (terminal email address), and authentication information such as passwords (login password, authentication password, etc.) used for various authentications in the PHR platform and applications.

[0051] It should be noted that multiple medical institution account IDs may be registered at the same medical institution, for example, for each medical department or medical worker.

[0052] In addition, the medical institution account ID may be obtainable by businesses that handle PHR data on the PHR platform, such as care workers, teachers in special needs classes, and trainers at sports gyms.

[0053] The PHR application registration data 157 is registration data relating to applications that cooperate with the PHR platform, and an example of the data configuration is shown in FIG. In the PHR application registration data 157, for example, a PHR application name, a PHR application ID, and other application information are stored in association with each other.

[0054] The PHR application name is the name of each PHR application, and for example, the name set by the PHR application developer when registering the application on the PHR platform is stored.

[0055] The PHR application ID is information used to identify each PHR application. This PHR application ID is preferably a unique value for each PHR application, and is set and stored by the management server 10 as a unique value for each PHR application, for example.

[0056] Other application information may include, for example, a uniform resource identifier (URI) for downloading the PHR application, a description of the PHR application, and the like.

[0057] Note that various PHR applications may be run on the PHR platform, such as an ASD (Autism Spectrum Disorder) diagnosis application that allows recording and viewing of photographs of the subject and / or related parties, a home care record application for managing patient care records by home care workers, a medication record application for recording prescribed medication intake, a peak flow record application for recording peak flow related to asthma, etc. Furthermore, PHR applications may include applications that handle monitoring records of specific health conditions such as hay fever, and applications that handle information acquired by communicating with devices that monitor health conditions on the subject terminal 20, such as blood glucose monitoring devices and smartwatches.

[0058] The account ID / PHR application linkage management data 159 is management data for linkage between user account IDs, medical institution account IDs, and PHR application IDs, and an example of the data configuration is shown in FIG. The account ID / PHR application linkage management data 159 stores, for example, the above-mentioned user account ID, the above-mentioned medical institution account ID, and the above-mentioned PHR account ID in association with each other.

[0059] The account ID / PHR application linkage management data 159 may be an example of data that manages the linkage between a first account ID used by a subject to access the shared system and a second account ID used by a user of a medical institution terminal to access the shared system, in association with at least one application.

[0060] There are various methods for providing PHR data requested by a medical institution (medical institution terminal 30).

[0061] In the main embodiment, an example is given in which PHR data is registered in the management server 10, and the management server 10 provides the PHR data stored in the memory unit 15 to the medical institution terminal 30 based on a request from the medical institution terminal 30. In this case, the PHR application data management data shown in Fig. 9 may be stored as management data for each user account ID in the storage unit 15 of the management server 10. Fig. 9 illustrates an example of PHR application data management data for user account ID "U0001."

[0062] Each PHR application data management data may store, for example, a user account ID and PHR data management data. The PHR application data management data may be an example of data that manages accounts corresponding to subjects based on a user account ID that is common to multiple types of PHR applications. The PHR data management data may be data that allows multiple PHR data corresponding to each PHR application to be registered, and may store, for example, a PHR application ID and PHR data in association with each other.

[0063] (2) Functional configuration of subject terminal FIG. 10 is a diagram showing an example of functions realized by the control unit 21 of the subject terminal 20 in this embodiment. The control unit 21 includes, as a functional unit, a PHR application processing unit 211 for executing PHR application processing in accordance with a PHR application processing program 281 stored in the storage unit 28, for example.

[0064] FIG. 11 is a diagram showing an example of data stored in storage unit 28 of subject terminal 20 in this embodiment. The memory unit 28 stores, for example, various PHR application processing programs 281A, PHR application processing programs 281B, PHR application processing programs 281C, etc. that are executed as PHR application processing, and device identification information 283 (e.g., telephone number, IMEI, etc.) for identifying the subject terminal 20 or the account of the user of the subject terminal 20. The PHR application ID assigned to each PHR application processing program 281 may be stored. The device identification information 283 may also store the user account ID of the subject terminal 20.

[0065] (3) Functional configuration of medical institution terminals The functional configuration of medical institution terminal 30 may be the same as that of subject terminal 20, for example. The PHR application ID assigned to each PHR application processing program 381 may be stored. The device identification information 383 may also store the medical institution account ID of the medical institution terminal 30.

[0066] <Display screen> Examples of display screens will be described below. The transitions of the display screens described below are merely examples of transitions of the display screens for realizing the technique of the present disclosure. In the transitions of the display screens exemplified below, the display of some of the display screens may be omitted, or other display screens may be added.

[0067] In the following, as an example, the subject terminal 20 and the medical institution terminal 30 are smartphones equipped with portrait-oriented display units 24 and 34. Some display screens may be exemplified as PCs equipped with landscape-oriented display units 34.

[0068] Note that the flow of screen transitions may be explained by showing specific screens displayed on different subject terminals 20 and / or medical institution terminals 30 within one drawing or across multiple drawings.

[0069] In the following, an example of the subject terminal 20 that records PHR data in the PHR platform is the subject terminal 20A of the user UA. The account of the subject terminal 20A or the account of the user UA may be an example of the first account.

[0070] In the following, an example of a medical institution terminal 30 that references PHR data based on collaboration from a user in a PHR platform is illustrated as a medical institution terminal 30A of a medical institution HA. The account of the medical institution terminal 30A or the account of the medical institution HA may be an example of a second account.

[0071] In this example, an ASD diagnosis application is used as an example of a PHR application, and the name of the PHR application used by the subject is exemplified as "PHR for ASD User App." Also, the name of the PHR application used by a medical institution is exemplified as "PHR for ASD Institute App."

[0072] 12 to 16 are diagrams showing examples of screens displayed on display unit 24 of subject terminal 20A and display unit 34 of medical institution terminal 30A in this embodiment.

[0073] An example of the main menu screen of the ASD diagnostic application displayed on the subject terminal 20A is shown on the left side of Figure 12. This main menu screen is configured to display, under the user name ("UA") of the user using the subject terminal 20A, a selection menu for the subject, including a function button UM1 for recording the subject's behavior, a function button UM2 for referencing the recorded behavior of the subject, and a function button UM3 for sharing the recorded behavior record (an example of PHR data) with a medical institution.

[0074] When the user taps function button UM1 on the screen on the left side of Fig. 12, the display on subject terminal 20A changes to the behavior record screen shown in the center of Fig. 12. The user can record the subject's behavior as video using the camera of subject terminal 20A. In this example, on the behavior recording screen, a message is displayed informing the user that the behavior of "UA" will be recorded (behavior recording will begin), and a "Take video of subject" button UM11 is displayed for recording video (moving image) of the subject using the imaging unit 27, and a "Add note to video" button UM12 is displayed for adding a note to the recorded video.

[0075] The right side of Figure 12 shows that the imaging unit 27 is activated (or the app's camera) when the "Take video of the subject" button is tapped, and the user "UA" is captured as a moving image by the in-camera (front camera).

[0076] When the "Attach a memo to video" button is tapped, for example, a list of captured videos may be displayed, and the user may select a video and then input a memo using a keyboard, etc. The input memo data may then be stored in association with the video data.

[0077] For example, after recording the subject's behavior on video, if the user returns to the main menu screen and taps function button UM2, the display on subject terminal 20A changes to the PHR data display screen, allowing the user to review the recorded video.

[0078] As mentioned above, PHR data may include data in any data format, such as text data, numerical data, moving images (video), still images, etc. For example, the screen in the center of Figure 12 may display a "Manually enter actions" button that allows the user to enter their own actions in text, etc., and the action information (e.g., text information) entered via a keyboard, etc. may be included in the PHR data and recorded.

[0079] The left side of FIG. 13 shows a main menu screen similar to the left side of FIG. 12, and when the user taps function button UM2, the display on subject terminal 20A changes to the behavioral review screen shown on the right side of FIG. This behavioral review screen is configured to display, for example, PHR data based on the above behavioral record (in this example, the date the video was recorded, the video, and any notes attached to the video) as a behavioral record of this user "UA."

[0080] The left side of FIG. 14 shows a main menu screen similar to that shown on the left side of FIG. 12, and when the user taps the function button UM3, the display on the subject terminal 20A changes to the PHR data sharing confirmation screen shown in the center of FIG. This screen is configured to display, for example, precautions regarding sharing (or providing or linking) PHR data with a medical institution. Also, below the precautions, a check box UC1 for consenting to the sharing of PHR data based on the precautions and a function button UC2 for displaying PHR application link code information to be read by the medical institution terminal 30 are displayed.

[0081] For example, when the user taps the check box UC1, the function button UC2 changes from a grayed-out display state to a normal display state, and the operation is enabled. Then, when the function button UC2 is tapped, the display on the subject terminal 20A changes to the PHR application linkage code information display screen shown on the right side of FIG. 14. This screen is configured to display, for example, PHR application linkage code information indicated by a two-dimensional code, the user name of the subject terminal 20A in the PHR application, and the date of birth, which is an example of user information. It is also possible to display information such as the user's gender and the name of the linked PHR application. This allows the user of the medical institution terminal 30 to prevent mistakes such as misidentifying the subject with whom PHR data is linked.

[0082] The left side of Figure 15 shows the main menu screen of the ASD diagnostic application displayed on the medical institution terminal 30A. This main menu screen is configured to display, below the name of the medical institution ("HA") that uses the medical institution terminal 30A, a selection menu for the medical institution, including a function button HM1 for viewing the behavior of a subject who has linked the PHR application, a function button HM2 for linking the PHR application with a subject who is already using the ASD diagnostic application (who has opened an account on the PHR platform), and a function button HM3 for instructing a subject who is not using the ASD diagnostic application to install the application and linking the PHR application (this may also be called "prescribing the app").

[0083] For example, when the user taps function button HM2, the display on medical institution terminal 30A changes to the PHR application linkage code information reading screen shown in the center of Fig. 15. The PHR application linkage code information reading screen is configured to display, for example, a preview screen of the image acquired by imaging unit 37 and guide information that prompts the user to fit the PHR application linkage code information displayed on subject terminal 20 within the preview screen.

[0084] For example, when the imaging unit 37 reads PHR application linkage code information and the management server 10 executes the PHR application account linkage process described below, the display on the medical institution terminal 30A changes to the PHR linkage notification information display screen shown on the right side of Figure 15. This screen is configured to display, for example, a pair of information about the medical institution with which the PHR data was shared (e.g., the name of the medical institution) and information about the subject (e.g., the user name and date of birth) as PHR linkage notification information. The PHR application with which the PHR data is being shared is also displayed between the information about the medical institution and the information about the subject. This screen also displays an icon indicating that an ASD diagnostic application has been newly linked.

[0085] When the PHR application account linking process is executed, PHR linking notification information may be displayed on the subject terminal 20A.

[0086] After the ASD diagnostic application is linked with the user UA, for example, when the function button HM1 is tapped on the main menu screen on the left side of Figure 16 on the medical institution terminal 30A, the display on the medical institution terminal 30A changes to the PHR data reference request screen in the center of Figure 16. This screen is configured to display a user information input area HR1 for narrowing down the users who will view the PHR data. Below this, a PHR data reference user selection area HR2 is displayed for displaying a list of users narrowed down based on the content entered in the user information input area HR1.

[0087] For example, when UA is selected from among the users displayed in the PHR data reference user selection area HR2 and the PHR data reference button HR3 is tapped, the display on the medical institution terminal 30A changes to the PHR data display screen shown on the right side of FIG. On this screen, for example, below the name of the subject who has selected to view the PHR data, the PHR data, such as video and memo data similar to that shown on the right side of FIG. 13, is displayed. However, the display does not necessarily have to be the same as the right side of FIG. 13, and the display may be different between the subject terminal 20 and the medical institution terminal 30.

[0088] In addition, when the function button UM2 is tapped on the main menu screen of the ASD diagnostic application on the left side of FIG. 14, a PHR data display screen similar to the one on the right side of FIG. 16 may be displayed.

[0089] 17 is another example of a PHR data display screen displayed on the display unit 34 of the medical institution terminal 30. This screen is an example of a screen displayed by a PHR integrated application ("PHR Institute App") that can link PHR data with any PHR application and centrally refer to PHR data shared on a PHR platform. On this screen, the display unit 34 is configured to display, for example, information about the user currently viewing the PHR data (e.g., user account ID, username, etc.) at the top. Below that, in the left pane, a list of linked applications is displayed. The right pane is configured to display PHR data (in this example, weight and body fat percentage by date) related to the application selected to view the PHR data (in this screen, a weight recording app) from the list of linked applications. When a medication recording app is selected from the left pane, PHR data such as the date and time of medication, type and amount of medication, etc. may be displayed. When an ASD diagnosis app is selected, PHR data such as the recording date and the content of the activity record may be displayed.

[0090] Note that the screen of the PHR integrated application may display a list of all PHR data from linked applications without selecting a PHR application, as shown in Figure 18. This allows users of the PHR integrated application to directly check the PHR data without selecting a PHR application.

[0091] The PHR integrated application may be provided as, for example, SaaS (Software as a Service). For example, the management server 10 may make the PHR integrated application available as a web application. Furthermore, the PHR integrated application may be available on, for example, the subject terminal 20.

[0092] In addition, in the PHR integration application, by entering information about the subject (e.g., user name, date of birth, etc.), it is possible to identify the user account ID as in Figure 16 and view the linked PHR data across the board.

[0093] <Processing> 19 and 20 are flowcharts showing an example of the flow of processing executed by each device in this embodiment. From the left, Fig. 19 shows an example of processing executed by the control unit 21 of the subject terminal 20A of the user UA, an example of processing executed by the control unit 31 of the medical institution terminal 30X of the medical institution HX, and an example of processing executed by the control unit 11 of the management server 10. Fig. 20 shows an example of processing executed by the control unit 31 of the medical institution terminal 30Y when further linking with the medical institution terminal 30Y of the medical institution HY.

[0094] Note that the processes described below are merely examples of processes for realizing the method of the present disclosure, and are not limited to these. Furthermore, other steps may be added to the processing described below, or some steps may be omitted (deleted) from the processing described below.

[0095] Before the processing in this flowchart begins, it is assumed that the user UA and the medical institution HX have already registered (created) accounts on the PHR platform, and that a PHR application (e.g., an ASD diagnosis application) identified by the same PHR application ID is installed on the subject terminal 20A and the medical institution terminal 30X.

[0096] An example of the flow of processing executed by the respective control units of subject terminal 20A, medical institution terminal 30X, and management server 10 will be described below with reference to FIG.

[0097] First, the control unit 21 of the subject terminal 20A executes a PHR application linkage code information generation process (A110) based on, for example, input to the input / output unit 23 (for example, user input (user operation input, sound input, etc.); the same applies below). In the PHR application linkage code information generation process, the control unit 21 of the subject terminal 20A generates PHR application linkage code information, which is a one-dimensional code or a two-dimensional code based on PHR application linkage information that includes, for example, the user account ID of the subject terminal 20A and the PHR application ID of the PHR application that links the PHR data. Code images such as one-dimensional codes and two-dimensional codes may be considered a type of code information. Information encoded in a code image may also be considered a type of code information. The PHR application linkage information and the PHR application linkage code information may include information for identifying the subject (for example, the subject's name, date of birth, gender, etc.).

[0098] Then, the control unit 21 of the subject terminal 20A, for example, displays the generated PHR application link code information on the display unit 24 (A120).

[0099] For example, based on a user input, the control unit 31 of the medical institution terminal 30X uses the imaging unit 37 to read the PHR application link code information displayed on the subject terminal 20A (X110). Then, the control unit 31 of the medical institution terminal 30X decodes the read PHR application linkage code information and acquires the PHR application linkage information.

[0100] The method of transferring the PHR application link information is not limited to using a code image. For example, the control unit 21 of the subject terminal 20A may transfer the PHR application link information to the medical institution terminal 30X by P2P communication using short-range wireless communication such as Bluetooth or NFC.

[0101] Furthermore, the control unit 31 of the medical institution terminal 30X may receive PHR application linkage information by receiving, for example, a user account ID or a PHR application ID displayed on the subject terminal 20A through user input.

[0102] In addition, if the control unit 21 of the subject terminal 20A determines, based on the user input, that the user has agreed to the linking of PHR data, it may display PHR application linkage code information or send PHR application linkage information.

[0103] Then, the control unit 31 of the medical institution terminal 30X sends PHR application account linkage request information to the management server 10, which includes the user account ID and PHR application ID based on the PHR application linkage information, and the medical institution account ID of the medical institution terminal 30X (X120).

[0104] When receiving the PHR application account linking request information from the medical institution terminal 30X, the control unit 11 of the management server 10 executes the PHR application account linking process (S110). In the PHR application account linking process, the control unit 11 of the management server 10 determines the user account ID of the linking source, for example, based on the received PHR application account linking request information, and stores the corresponding user account ID in the account ID / PHR application linking management data 159 in association with the linking destination medical institution account ID and the PHR application ID for which the subject authorized the linking.

[0105] If the subject links PHR data without limiting the PHR application, the PHR application ID in the PHR application linkage information may include, for example, all application permission flag information (e.g., "*") indicating that the application is arbitrary. The management server 10 may then store the all application permission flag information in the PHR application ID of the account ID / PHR application linkage management data 159, and store the all application permission flag information in association with the medical institution account ID.

[0106] In addition, the control unit 11 of the management server 10 may, for example, when executing the PHR application account linking process, send PHR linking notification information indicating that PHR data linking has been performed to the subject terminal 20A of the user account ID that performed the linking and / or the medical institution terminal 30X of the medical institution account ID. When receiving the PHR linkage notification information from management server 10, subject terminal 20A and / or medical institution terminal 30X may output (eg, display) the received PHR linkage notification information.

[0107] After A120, the control unit 21 of the subject terminal 20A executes a PHR data acquisition process based on, for example, a user input (A130). In the PHR data acquisition process, control unit 21 of subject terminal 20A acquires PHR data from input / output unit 23 of subject terminal 20A, for example, based on PHR application processing program 281.

[0108] The PHR data acquisition process may be performed automatically or may be provided by a third party, rather than based on user input. For example, the subject terminal 20A may constantly measure the subject's steps and acquire the measured step count data as PHR data. Alternatively, the subject terminal 20A may receive the subject's prescription information from a doctor or pharmacist and acquire the received prescription information as PHR data.

[0109] Then, the control unit 21 of the subject terminal 20A transmits PHR data recording request information including the acquired PHR data, the PHR application ID of the PHR application used, and the user account ID of the subject terminal 20A to the management server 10 (A140).

[0110] When receiving the PHR data recording request information from the subject terminal 20A, the control unit 11 of the management server 10 executes, for example, a PHR data recording process (S120). In the PHR data recording process, the control unit 11 of the management server 10, for example, refers to the account ID / PHR application linkage management data 159. Then, based on the PHR data recording request information, for example, the control unit 11 associates the PHR application ID with the PHR data and stores the PHR data in the PHR data management data for the corresponding user account ID (for example, the data shown in FIG. 9). In addition to acquiring and storing the PHR data itself, it is also possible to acquire and store information about the location of the PHR data (such as a URI), and these processes may be used as examples of processes for registering data related to the subject's health in a shared system.

[0111] In the PHR data recording process, the management server 10 may store the PHR data without separating them by PHR application ID. In other words, the PHR data management data may be stored in a form that makes it impossible to identify the applications from which the PHR data in various PHR applications was acquired.

[0112] After X120, the control unit 31 of the medical institution terminal 30X transmits PHR data reference request information to the management server 10 based on, for example, a user input (X130). Here, the PHR data reference request information may include the following information: (A1) The user account ID and medical institution account ID of the subject who will be referencing the PHR data, and the PHR application ID corresponding to the PHR data being referenced. (A2) User information of the subject who will be referencing the PHR data (e.g., name, date of birth, etc.), medical institution account ID, and PHR application ID corresponding to the PHR data being referenced. (A3). User account ID and medical institution account ID of the subject who is accessing PHR data. (A4). User information and medical institution account ID of the subject who is accessing PHR data.

[0113] When receiving PHR data reference request information from the medical institution terminal 30X, the control unit 11 of the management server 10, for example, executes a PHR data search process (which may also be called a PHR data identification process) and identifies PHR data based on the PHR data reference request information (S130). In the PHR data search process, the control unit 11 of the management server 10, for example, references the account ID / PHR application linkage management data 159 and determines whether the user account ID included in the PHR data reference request information, the medical institution account ID included in the PHR data reference request information, and the PHR application ID included in the PHR data reference request information are associated. If it is determined that they are associated, the control unit 11 of the management server 10, for example, references the PHR data management data and reads the PHR data linked to the PHR application ID.

[0114] In addition, in the PHR data search process, if the information (A2) or (A4) above is included in the PHR data reference request information, the control unit 11 of the management server 10 may refer to the PHR user account registration data 153 and search for a user account ID that matches the subject's user information.

[0115] Furthermore, in the PHR data search process, if the information (A3) or (A4) above is included in the PHR data reference request information, the control unit 11 of the management server 10 may, for example, refer to the account ID / PHR application linkage management data 159 and read, for the subject's user account ID, PHR data corresponding to each PHR application ID associated with the medical institution account ID included in the PHR data reference request information from the PHR data management data. In other words, it may be possible to transmit PHR data collectively for all or any PHR applications that are linked with a certain medical institution on the PHR platform.

[0116] For example, when the control unit 11 of the management server 10 reads the PHR data, it transmits the data to the medical institution terminal 30X (S140).

[0117] When the PHR data is received from the management server 10, the control unit 31 of the medical institution terminal 30X outputs the received PHR data (for example, displays it on the display unit 34) (X140).

[0118] An example of cooperation with the medical institution terminal 30Y will be described below with reference to FIG.

[0119] The control unit 21 of the subject terminal 20A generates PHR application linkage code information (A150) and displays it (A160), for example, in the same manner as in steps A110 and A120.

[0120] The control unit 31 of the medical institution terminal 30Y reads the PHR application linkage information (Y110), for example, similar to step X110. Then, for example, similar to step X120, it sends PHR application account linkage request information to the management server 10 (Y120).

[0121] Furthermore, the control unit 21 of the subject terminal 20A acquires PHR data (A170) in the same manner as in steps A130 and A140, and transmits PHR data recording request information to the management server 10 (A180). Then, the control unit 11 of the management server 10 executes the PHR data recording process (S160), for example, in the same manner as in step S120.

[0122] The control unit 31 of the medical institution terminal 30Y transmits PHR data reference request information to the management server 10 (Y130), for example, in the same manner as in step X130.

[0123] When receiving PHR data reference request information from the medical institution terminal 30Y, the control unit 11 of the management server 10 executes PHR data recording processing (S170), for example, similar to step S130, and transmits the PHR data to the medical institution terminal 30Y (S180), similar to step S140.

[0124] When the PHR data is received from the management server 10, the control unit 31 of the medical institution terminal 30Y outputs the PHR data, for example, in the same manner as in step X140 (Y140).

[0125] That is, the subject can provide PHR data acquired using any one or more PHR applications to any one or more medical institutions.

[0126] The control unit 21 of the subject terminal 20A may be configured to transmit PHR data reference request information to the management server 10 based on, for example, a user input. Then, the control unit 11 of the management server 10 may be configured to transmit the PHR data to the subject terminal 20A based on the received PHR data reference request information. Upon receiving the PHR data from the management server 10, the control unit 21 of the subject terminal 20A may be configured to output the received PHR data to the display unit 24.

[0127] In the first embodiment, PHR data is shared by a management server 10 that manages PHR data related to the subject's health, multiple types of PHR applications that acquire PHR data and register it in the management server 10, and a medical institution terminal 30 that allows viewing of the PHR data registered in the management server 10. Specifically, as shown in Figure 9, etc., the association between the user account ID used by an application corresponding to the subject to access the management server 10 and the medical institution account ID used by the medical institution terminal 30 to access the management server 10 is managed in association with at least one application, and the PHR data is registered in the management server 10 in association with the user account ID and the application that acquired the PHR data. Then, as shown in Figures 19 and 20, a request to reference PHR data associated with the medical institution account ID corresponding to the medical institution terminal 30 is accepted from the medical institution terminal 30, and the data acquired by the application associated with the user account ID and medical institution account ID is provided to the requesting medical institution terminal 30.

[0128] <Effects of the First Embodiment> In the first embodiment, a data sharing system (e.g., management server 10) enables sharing of health data of a subject between multiple types of applications (e.g., multiple types of PHR applications) for acquiring health data of the subject (e.g., PHR data) and a medical institution terminal for viewing the health data of the subject. Furthermore, association between a first account ID for the subject to access the data sharing system and a second account ID for the user of the medical institution terminal to access the data sharing system is managed in association with at least one application. Therefore, in response to a request from a medical institution, data related to a specific application can be identified based on the association of the managed account IDs.

[0129] In addition, in the first embodiment, as shown in Figures 7 and 9, multiple PHR data corresponding to multiple types of applications can be registered in the memory unit 15 of the management server 10 (an example of a memory unit of a data sharing system), so that a variety of PHR data can be provided to medical institutions.

[0130] In addition, in the first embodiment, as shown in Figure 11, etc., when multiple applications are running on the subject terminal, there is no need to set up an account on the management server 10 for each PHR application, as shown in Figure 9, etc., thereby improving usability for the subject.

[0131] In addition, in the first embodiment, as shown in Figure 9, etc., multiple types of PHR applications can be associated with the link between a user account ID and a medical institution account ID, so that data acquired by each of multiple types of PHR applications can be managed collectively.

[0132] In addition, in the first embodiment, as shown in Figure 9, etc., each of the multiple types of PHR applications corresponding to a user account ID can be associated with multiple medical institution account IDs, so that each of the multiple PHR applications can collaborate with multiple medical institutions (terminals) and share PHR data.

[0133] In addition, in the first embodiment, as shown in Figures 19 and 20, etc., an integration request including a user account ID, a medical institution account ID, and an application ID of at least one PHR application is accepted, and in response to the integration request, the integration between the user account ID and the medical institution account ID is managed in association with at least one PHR application, thereby making it possible to manage the integration and provide PHR data using a PHR application that can acquire PHR data.

[0134] In addition, in the first embodiment, as shown in Figures 19 and 20, etc., in response to a reference request including information that can identify a user account ID and a medical institution account ID (not limited to the user account ID and medical institution account ID themselves, but any information that can identify the user account ID and medical institution account ID) PHR data obtained by a PHR application associated with the user account ID and the medical institution account ID can be provided.

[0135] Furthermore, in the first embodiment, as shown in Figures 30, 16, and 19, etc., in response to a reference request in which the target PHR data is specified by the subject's identification information (e.g., name), PHR data corresponding to the type of PHR application associated with the user account ID and medical institution account ID is provided, thereby allowing the medical institution to request the provision of the necessary PHR data without obtaining or inputting account information, etc. (e.g., the subject's user account ID or medical institution account ID), thereby improving the usability of the medical institution.

[0136] Furthermore, in the first embodiment, as shown in Figures 30, 16, and 19, a reference request is received in which the target PHR data is specified by the subject's identification information (e.g., name), and the PHR data corresponding to the reference request is identified based on the user account ID corresponding to the subject's identification information, the medical institution account ID corresponding to the medical institution terminal 30, and the PHR application associated with the user account ID and medical institution account ID.This allows the medical institution to identify the PHR data to be provided and provide it to the medical institution without having to obtain and input the subject's user account ID.

[0137] In the first embodiment, as shown in Figure 16, and Figures 19 and 20, in response to a reference request including information capable of identifying a user account ID and a medical institution account ID (not limited to the user account ID and medical institution account ID themselves, but any information capable of identifying the user account ID and the medical institution account ID), a PHR application associated with the user account ID and the medical institution account ID can be identified, and PHR data obtained by the identified PHR application can be provided.

[0138] In addition, in the first embodiment, as shown in Figures 14 and 15, and Figures 19 and 20, etc., a linkage request including a user account ID, an application ID, and a medical institution account ID provided to a medical institution terminal 30 from a subject terminal 20 on which a PHR application is installed can be accepted, and the linkage between the user account ID and the medical institution account ID can be managed in association with the identification information of the PHR application.

[0139] Furthermore, in the first embodiment, as shown in Figures 14 and 15, and Figures 19 and 20, etc., a linkage request including a user account ID, an application ID, and a medical institution account ID is accepted, which is provided to a medical institution terminal 30 from a subject terminal 20 on which a PHR application is installed based on the consent of the subject or a person related to the subject, and the linkage between the user account ID and the medical institution account ID can be managed in association with the identification information of the PHR application.

[0140] In addition, in the first embodiment, as shown in Figure 17, etc., the medical institution application for viewing PHR data on the medical institution terminal 30 is common to multiple types of PHR applications, and medical institution staff do not need to use a different PHR application for each PHR application of the subject, thereby improving usability for medical institution staff.

[0141] <First Modification Example (1)> In the above embodiment, the PHR data is registered in the management server 10 and provided from the management server 10 to the medical institution terminal 30, but the present invention is not limited to this.

[0142] For example, management server 10 may inquire (query) subject terminal 20 about PHR data acquired by subject terminal 20, and present the PHR data acquired from subject terminal 20 to medical institution terminal 30. Specifically, as shown in FIG. 21 , (1) the medical institution server 50 requests the management server 10 to reference the PHR data of the subject, for example, by transmitting the PHR data reference request information transmission described above. (2) In response to this reference request, the management server 10 queries the subject terminal 20 of the subject for PHR data. (3) In response to this query, the subject terminal 20 transmits the PHR data to the management server 10. (4) The management server 10 transmits the received PHR data to the medical institution terminal 30. For example, (2) may be an example of the control unit of the data sharing system requesting data corresponding to multiple types of applications from the subject's terminal as identification of data related to the subject's health. The management server 10 may or may not register the PHR data received from the subject terminal 20 in (3). For example, the management server 10 may temporarily store the PHR data received from the subject terminal 20 in the storage unit 15, but may delete the PHR data after transmitting the PHR data to the medical institution terminal 30.

[0143] In addition, for example, PHR data may be registered from the subject terminal 20 to a PHR application management server 60, which is a management server corresponding to the PHR application, and the PHR data registered in the PHR application management server 60 may be queried from the management server 10, thereby presenting the PHR data to the medical institution terminal 30.

[0144] The PHR application management server 60 stores (this may be considered as registering) PHR data acquired by the corresponding PHR application. On the other hand, the management server 10 has a function of collecting and recording PHR data from multiple types of PHR applications and linking the PHR data (however, in this modified example, registration of PHR data does not have to be performed). The operators of the PHR application management server 60 and the management server 10 may be different or the same.

[0145] Specifically, as shown in FIG. 22 , (1) the subject terminal 20 transmits, for example, the aforementioned PHR data recording request information to the PHR application management server 60 corresponding to the PHR application that acquired the PHR data, thereby making a recording request (registration request) for the PHR data. (2) The PHR application management server 60 registers the received PHR data in accordance with this recording request. (3) The medical institution server 50 transmits, for example, the aforementioned PHR data reference request information to the management server 10, thereby making a reference request for the PHR data of the target subject. (4) In accordance with this reference request, the management server 10 queries the PHR application management server 60 for PHR data. (5) In accordance with this reference, the PHR application management server 60 transmits the PHR data to the management server 10. (6) The management server 10 transmits the received PHR data to the medical institution terminal 30. For example, (4) may be an example of the control unit of the data sharing system requesting data corresponding to each of multiple types of applications from the corresponding application management servers as data identification. The management server 10 may or may not register the PHR data received from the PHR application management server 60 in (5). For example, the management server 10 may temporarily store the PHR data received from the PHR application management server 60 in the storage unit 15, but may erase the PHR data after transmitting the PHR data to the medical institution terminal 30. Note that, as in (5) and (6), the PHR data does not have to be sent to the medical institution terminal 30 via the management server 10. In other words, the management server 10 may request the PHR application management server 60 to send the PHR data directly from the PHR application management server 60 to the medical institution terminal 30. This may be an example of the control unit of the data sharing system requesting the corresponding application management server to send data corresponding to each of multiple types of applications to the medical institution terminal as data identification.

[0146] According to this modification, the control unit of the data sharing system (e.g., control unit 11 of management server 10) can request data corresponding to each of multiple types of applications (e.g., multiple types of PHR applications) from the subject's terminal as data related to the subject's health (e.g., PHR data). In this case, multiple types of PHR data (one example of data corresponding to each of multiple types of applications) can be acquired by the subject's terminal 20 corresponding to the subject, and the PHR data corresponding to each of the multiple types of PHR applications (one example of multiple types of applications) can be requested from the subject's terminal 20 by the data sharing system. This makes it possible to provide data to the medical institution's terminal by querying the subject's terminal for data from the sharing system, without the need to register the subject's health-related data corresponding to each of the multiple types of applications in the sharing system.

[0147] Furthermore, according to this modification, the control unit of the data sharing system (e.g., the control unit 11 of the management server 10) can specify data related to the subject's health (e.g., PHR data) by requesting data corresponding to each of multiple types of applications (e.g., multiple types of PHR applications) from the corresponding application management server 60. In this case, multiple types of PHR data (one example of data corresponding to multiple types of applications) can be registered in multiple types of PHR application management servers 60 (one example of multiple types of application management servers corresponding to multiple types of applications), and the PHR data corresponding to each of the multiple types of PHR application management servers 60 can be requested from the PHR application management server 60 by the data sharing system. This makes it possible to provide data to the medical institution terminal by querying the multiple types of application management servers for data from the sharing system, without the need to register data related to the subject's health corresponding to each of the multiple types of applications in the sharing system.

[0148] <First Modification (2)> In the above embodiment, the PHR application linkage code information is transmitted from the subject terminal 20 to the medical institution terminal 30, but this is not limiting. For example, the PHR application linkage code information presented to the medical institution terminal 30 may be read by the subject terminal 20.

[0149] 23 and 24 are diagrams showing examples of screens displayed on display unit 24 of subject terminal 20A and display unit 34 of medical institution terminal 30A in this modification.

[0150] When the function button HM2 is tapped on the main menu screen of the medical institution side ASD diagnostic application of the medical institution terminal 30A on the left side of FIG. 23, the display on the medical institution terminal 30A changes to the PHR application link code information display screen in the center of FIG. This screen is configured to display, for example, PHR application link code information indicated by a two-dimensional code and the name of the medical institution in the PHR application. For example, the user of the subject terminal 20 can confirm the PHR data sharing destination by checking the name of the medical institution.

[0151] When function button UM3 is tapped on the subject-side ASD diagnostic application main menu screen of subject terminal 20A on the right side of Fig. 23, the display on subject terminal 20A changes to the PHR application linkage code information reading screen on the left side of Fig. 24. When the user moves subject terminal 20A in accordance with guide information urging the user to fit the PHR application linkage code information displayed on medical institution terminal 30 within the preview screen, and the PHR application linkage code information is read by subject terminal 20A, the display on subject terminal 20A changes to the PHR data sharing confirmation screen in the center of Fig. 24. For example, when the user taps the check box UC3 for consenting to the sharing of PHR data with the medical institution HA, the PHR data sharing function button UC4 changes from a grayed-out display state to a normal display state and becomes enabled. When the PHR data sharing function button UC4 is tapped, the PHR application account linking process is executed in the management server 10, and the display on the subject terminal 20A changes to the PHR linking notification information display screen shown on the right side of FIG. 24 .

[0152] When the PHR application account linking process is executed, PHR linking notification information may be displayed on the medical institution terminal 30A.

[0153] 25 is a flowchart showing an example of the flow of processing executed by each device in this modification. From the left, this figure shows an example of processing executed by the control unit 21 of the subject terminal 20A of the user UA, an example of processing executed by the control unit 31 of the medical institution terminal 30X of the medical institution HX, and an example of processing executed by the control unit 11 of the management server 10.

[0154] First, the control unit 31 of the medical institution terminal 30X executes a PHR application linkage code information generation process based on, for example, a user input (X210). In the PHR application linkage code information generation process, the control unit 31 of the medical institution terminal 30X generates PHR application linkage code information, which is a one-dimensional code or a two-dimensional code, based on PHR application linkage information including, for example, the medical institution account ID of the medical institution terminal 30X and the PHR application ID of the PHR application that links the PHR data. Note that the PHR application linkage information and the PHR application linkage code information may include information for identifying the medical institution (for example, the name of the medical institution, etc.).

[0155] Then, the control unit 31 of the medical institution terminal 30X, for example, displays the generated PHR application link code information on the display unit 34 (X220).

[0156] For example, based on a user input, the control unit 21 of the subject terminal 20A reads the PHR application link code information displayed on the medical institution terminal 30X using the imaging unit 27 (A210). Then, the control unit 21 of the subject terminal 20A decodes the read PHR application linkage code information and acquires the PHR application linkage information.

[0157] Note that the control unit 31 of the medical institution terminal 30X may transfer the PHR application link information to the subject terminal 20A by transmitting it through P2P communication using short-range wireless communication such as Bluetooth or NFC.

[0158] Furthermore, the control unit 21 of the subject terminal 20A may accept PHR application linkage information by accepting, for example, a medical institution account ID or a PHR application ID displayed on the medical institution terminal 30X through user input.

[0159] Then, the control unit 21 of the subject terminal 20A sends PHR application account linkage request information including the medical institution account ID and PHR application ID based on the PHR application linkage information, and the user account ID of the subject terminal 20A to the management server 10 (A220).

[0160] The control unit 21 of the subject terminal 20A may transmit PHR application account linking request information to the management server 10 when determining, based on the user input, that the user has agreed to linking the PHR data.

[0161] When the PHR application account linking request information is received from the subject terminal 20A, the control unit 11 of the management server 10 executes the PHR application account linking process (S210). The PHR application account linking process may be processed in the same manner as S110 in FIG. 19, for example.

[0162] In this modified example, as shown in Figures 23, 24, and 25, etc., a linkage request including a medical institution account ID provided from a medical institution terminal 30 to a subject terminal 20 on which a PHR application is installed, a user account ID, and an application ID is accepted, and the linkage between the user account ID and the medical institution account ID can be managed in association with the application ID of the PHR application.

[0163] In addition, in this modified example, as shown in Figures 23, 24, and 25, etc., a linkage request including a medical institution account ID provided with the consent of the subject or a person related to the subject, a user account ID, and an application ID is accepted from the medical institution terminal 30 to the subject terminal 20 on which the PHR application has been installed, and the linkage between the user account ID and the medical institution account ID can be managed in association with the application ID of the PHR application.

[0164] <First Modification (3)> In the above embodiment, the PHR application linking code information is transmitted from the subject terminal 20 to the medical institution terminal 30, but this is not limiting. For example, the PHR application account linking process may be executed by selecting a medical institution with which to share PHR data on the subject terminal 20.

[0165] 26 and 27 are diagrams showing examples of screens displayed on display unit 24 of subject terminal 20A and display unit 34 of medical institution terminal 30A in this modification.

[0166] When the function button UM3 is tapped on the subject-side ASD diagnostic application main menu screen on the left side of FIG. 26 on the subject terminal 20A, the display on the subject terminal 20A changes to the PHR application linked medical institution selection screen on the right side of FIG. This screen is configured to display a medical institution information input area UR1 for narrowing down the medical institutions that share PHR data. Below that, a narrowed-down medical institution selection area UR2 is displayed for displaying a list of medical institutions narrowed down based on the input content into the medical institution information input area UR1. Below that, a nearby medical institution selection area UR3 is displayed for displaying a list of medical institutions located within a predetermined distance (e.g., 1 km) from the subject terminal 20A based on, for example, the location information of the subject terminal 20A.

[0167] For example, if the subject terminal 20A is located inside a certain medical institution (e.g., HA), the medical institution HA may be selectable in the nearby medical institution selection area UR3. This medical institution HA may be equipped with the medical institution terminal 30A to be linked.

[0168] For example, when HA is selected from the medical institutions displayed in the narrowed-down medical institution selection area UR2 and the PHR data sharing destination medical institution selection UR4 is tapped, the display on the subject terminal 20A changes to the PHR data sharing confirmation screen shown on the left side of Figure 27. When the PHR data sharing function button UC4 is tapped, the management server 10 executes the PHR application account linking process, and the display on the subject terminal 20A changes to the PHR linking notification information display screen shown on the right side of FIG.

[0169] 28 is a flowchart showing an example of the flow of processing executed by each device in this modification. From the left, this figure shows an example of processing executed by the control unit 21 of the subject terminal 20A of the user UA, an example of processing executed by the control unit 31 of the medical institution terminal 30X of the medical institution HX, and an example of processing executed by the control unit 11 of the management server 10.

[0170] First, the control unit 21 of the subject terminal 20A sends PHR application linked medical institution request information to the management server 10 to request a list of medical institutions that will be linked (PHR data sharing partners), for example, based on user input (A310). The PHR application-linked medical institution request information may include, for example, the following information: (B1) User account ID of subject terminal 20A. (B2) Location information of subject terminal 20A. (B3) Part or all of the name of the medical institution accepted by user input. (B4) Part or all of the medical institution telephone numbers accepted by user input. (B5) Part or all of the medical institution address accepted by user input.

[0171] When the PHR application linked medical institution request information is received from the subject terminal 20A, the control unit 11 of the management server 10 executes a linked medical institution search process (S310). In the linked medical institution search process, the control unit 11 of the management server 10, for example, refers to the PHR medical institution account registration data 155 and searches for the corresponding medical institution account ID based on the received PHR application linked medical institution request information.

[0172] In the linked medical institution search process, for example, when the information (B2) above is included in the PHR application linked medical institution request information, the control unit 11 of the management server 10 may search for medical institution account IDs of medical institutions located within a predetermined range (for example, a 1 km radius) from the location of the subject terminal 20A. In this case, for example, the control unit 11 may request location information from the subject terminal 20A and obtain the location information from the subject terminal 20A, or the control unit 11 may periodically transmit location information to the management server 10, and perform a search using, for example, the latest location information of the subject terminal 20A. In addition, the control unit 11 may perform a search using location information from the subject terminal 20A over a predetermined period of time (for example, using location information obtained by averaging the locations over the past predetermined period of time).

[0173] Furthermore, in the affiliated medical institution search process, the control unit 11 of the management server 10 may search for the medical institution account ID of a medical institution that matches the name, telephone number, and address of the medical institution when, for example, any of the information (B3), (B4), or (B5) above is included in the PHR application affiliated medical institution request information.

[0174] Then, the control unit 11 of the management server 10 transmits the PHR application-linked medical institution information, which is a list of medical institution account IDs found in the linked medical institution search process, to the subject terminal 20A (S320). The PHR application-linked medical institution information may include information such as the name of the medical institution and its location in association with the medical institution account ID.

[0175] Upon receiving the PHR application-linked medical institution information from the management server 10, the control unit 31 of the medical institution terminal 30X, for example, displays the received PHR application-linked medical institution information (A320). The control unit 21 of the subject terminal 20A selects a desired medical institution from the PHR application-linked medical institution information based on, for example, user input. Then, the control unit 21 of the subject terminal 20A transmits PHR application account linking request information to the management server 10, which includes the selected medical institution ID, the PHR application ID, and the user account ID of the subject terminal 20A (A330).

[0176] This allows the subject to link PHR data with any medical institution even if the subject terminal and the medical institution terminal are not in close proximity to each other.

[0177] <First Modification (4)> In the above embodiment, when specifying a subject whose PHR data is to be referenced on the medical institution terminal 30, the management server 10 identifies the user account ID of the subject, but this is not limiting. For example, the medical institution terminal 30 may search for the user account ID based on the subject's name, date of birth, etc.

[0178] FIG. 29 is a diagram showing an example of data stored in the storage unit 38 of the medical institution terminal 30 in this modification. The memory unit 38 stores, for example, various PHR application processing programs 381A, PHR application processing programs 381B, PHR application processing programs 381C, etc. that are executed as PHR application processing, device identification information 383 (e.g., telephone number, IMEI, etc.), and PHR application patient identification data 385.

[0179] The PHR application patient identification data 385 is data that manages (caches) the link between information about the subject, such as the subject's name and date of birth, and the subject's user account ID on the PHR platform, and an example of this data configuration is shown in Figure 30. The PHR application patient identification data 385 stores, for example, the patient name, user account ID, and other registration information in association with each other.

[0180] The patient name may be, for example, the name of the subject. Note that the patient name and the name of the subject registered on the PHR platform may be different names. The patient name is an example of subject identification information.

[0181] The user account ID is, for example, the user account ID of the subject (patient) associated with the medical institution account ID of this medical institution terminal 30 (with which PHR data linkage has been performed) in the PHR application account linkage process.

[0182] Other registration information may include various information such as the PHR application ID of the PHR application with which the subject linked PHR data, and the patient's date of birth.

[0183] For example, when the PHR application account linking process is executed in the management server 10 and PHR linking notification information is received from the management server 10, the control unit 31 of the medical institution terminal 30 may update and store the PHR application patient identification data 385.

[0184] By storing the PHR application patient identification data 385 in the medical institution terminal 30, the user of the medical institution terminal can identify the subject's user account ID using information different from the subject's identification information registered in the PHR platform.

[0185] For example, when transmitting PHR data reference request information, the medical institution terminal 30 may refer to the PHR application patient identification data 385 and identify the user account ID from the patient name or the like.

[0186] <Second Example> The second embodiment relates to linking a PHR platform service deployed on a global network such as the Internet with an electronic medical record service deployed on a private network such as an intranet.

[0187] The contents described in the second embodiment are similarly applicable to any of the other embodiments and other modified examples.

[0188] <System configuration> FIG. 31 is a diagram showing an example of the system configuration of an information system 1B in this embodiment. In the information system 1B, the network 40 is separated into a wide area communication network 40A such as the Internet and a closed area communication network 40B such as an intranet. The wide area communication network 40A may be called an open network or a global network. The closed area communication network 40B may be called a closed network or a private network.

[0189] The closed communication network 40B is a network configured, for example, by a VPN or a dedicated line, and is a network that is separate from the Internet and can only be used by specific people or locations. By using the closed network, users (for example, medical institutions) can prevent attacks from third parties outside the closed network, and can securely use the systems within the closed communication network 40B.

[0190] In information system 1B, for example, management server 10, one or more subject terminals 20, and one or more medical institution terminals 30 are connected via wide area communication network 40A. Also, in information system 1B, for example, medical institution server 50 and one or more medical institution terminals 30 are connected via closed area communication network 40B.

[0191] The medical institution server 50 is, for example, an information processing device owned by a business operator that operates an EMR application, and has a function of providing, for example, an electronic medical record service to the medical institution terminal 30, etc. via the closed communication network 40B. The medical institution server 50 may be a single server device or multiple server devices. The hardware configuration of the medical institution server 50 may be the same as that of the management server 10, for example.

[0192] The medical institution terminal 30 includes, for example, a PHR application processing unit 311 and an EMR application processing unit 313 as the control unit 31. The medical institution terminal 30 also includes, for example, a wide area network communication unit 32A for communicating with the wide area network 40A and a closed area network communication unit 32B for communicating with the closed area network 40B as the communication unit 32.

[0193] For example, the PHR application processing unit 311 can use the wide area network communication unit 32A. Also, for example, the EMR application processing unit 313 can use the closed area network communication unit 32B. Note that the PHR application processing unit 311 may be configured to use the closed area network communication unit 32B.

[0194] FIG. 32 is a diagram showing an example of functions realized by the control unit 51 of the medical institution server 50 in this embodiment. The control unit 51 includes, as a functional unit, a PHR / EMR linkage processing unit 511 that executes PHR / EMR account linkage processing (which may also be called PHR application management auxiliary processing) in accordance with a PHR / EMR linkage processing program 551 stored in the storage unit 55. The control unit 51 also includes, for example, an EMR application management processing unit 513 that executes EMR application management processing in accordance with an EMR application management processing program 553 stored in the storage unit 55.

[0195] FIG. 33 is a diagram showing an example of information stored in the storage unit 55 of the medical institution server 50 in this embodiment. The storage unit 55 stores, for example, a PHR / EMR linkage processing program 551, an EMR application management processing program 553, EMR account registration data 555, an EMR patient information database 557, and PHR / EMR association registration data 559.

[0196] The EMR account registration data 555 is registration data related to the patient (subject) account of a medical institution that uses the EMR application, and an example of the data configuration is shown in FIG. The EMR account registration data 555 stores, for example, the patient name, EMR ID, and other registration information in association with each other.

[0197] The patient name is, for example, the name of a patient receiving medical treatment at a medical institution that uses the EMR application. Note that for the same subject, the patient name and the user name in the PHR application may be the same or different.

[0198] The EMRID is information used to identify a patient's account in the EMR application. This EMRID is preferably a unique value for each account, and is set and stored as a unique value for each account by the medical institution server 50, for example. The EMRID may be information associated with the medical institution terminal 30 or the medical institution of the medical institution terminal 30. The EMRID may also be a third account ID.

[0199] Other registered information may include various basic information such as the patient's address, date of birth, and gender.

[0200] The EMR patient information database 557 is, for example, a database for managing information relating to medical information of a certain patient at a medical institution, and FIG. 35 shows an example of the data configuration of the EMR patient information database 557A. In the EMR patient information database 557A, for example, EMR patient information management data is stored as management data for each EMRID. In each EMR patient information management data, for example, an EMR ID and EMR data are stored in association with each other. The EMR data may store various medical information about patients identified by EMRID.

[0201] The PHR / EMR association registration data 559 is data for managing the correspondence between the user account ID in the PHR platform and the EMR ID in the EMR service, and an example of this data configuration, PHR / EMR association registration data 559A, is shown in Figure 36. In the PHR / EMR association registration data 559A, for example, a user account ID, an EMR ID, and an associated application ID are stored in association with each other. The linked application ID may store the PHR application ID of the PHR application with which the subject has linked with the medical institution.

[0202] The linked application ID may be obtained, for example, by the medical institution terminal 30 or the medical institution server 50 making an inquiry to the management server 10 based on the user account ID and the medical institution account ID. When a subject collectively links applications on the PHR platform, permission flag information for all applications may be stored in the linked application ID, or a storage item for the linked application ID may not be provided.

[0203] <Display screen> In this example, the name of the EMR application used by a medical institution is shown as "EHR / EMR App."

[0204] 37 and 38 are diagrams showing examples of screens displayed on display unit 24 of subject terminal 20A and display unit 34 of medical institution terminal 30A in this embodiment.

[0205] The left side of Figure 37 shows a PHR application linkage code information display screen that is displayed on the subject terminal 20A when, for example, the subject agrees to share PHR data on the PHR data sharing confirmation screen. For example, when this PHR application linkage code information is read by the medical institution terminal 30A on the PHR application linkage code information reading screen in the center of Figure 37 and the PHR application account linkage process is executed on the management server 10, the display on the medical institution terminal 30A changes to the electronic medical record linkage confirmation screen on the right side of Figure 37.

[0206] This screen is configured to display, for example, information confirming whether to link the user account ID with the EMRID of a patient with the same first and last name and date of birth selected by the medical institution server 50 from the registered EMR account registration data 555 by the medical institution terminal 30X sending information about the subject who performed PHR application linkage to the medical institution server 50. Also, below that, for example, a function button MB1 for manually specifying the EMRID to link and a function button MB2 for linking an EMRID automatically selected from the EMR account registration data 555 are displayed.

[0207] For example, when the function button MB1 is tapped by the user, the display on the medical institution terminal 30A changes to the linked EMRID input screen of FIG. On this screen, the linked EMR ID input field ARR is automatically filled in with the user account ID and medical institution account ID linked in the PHR application account linking process, and is set to be grayed out and unchangeable. Also displayed below this are a text box for manually entering the EMRID and a function button MB3 for querying the medical institution server 50 for the EMRID based on patient information such as the patient name and entering it.

[0208] When an EMRID is entered in the text box and a function button MB4 for linking the entered EMRID with the user account ID displayed in the link destination EMRID input area ARR is tapped, the PHR / EMR account linking process (described later) is executed in the medical institution server 50. Then, for example, the display on the medical institution terminal 30A changes to the EMR linkage notification information display screen shown in the center of FIG.

[0209] This screen is configured to display, for example, EMR linkage notification information, such as information about the subject who has shared PHR data and linked with the electronic medical record, and patient information on the electronic medical record that has been linked.

[0210] Furthermore, when the medical institution server 50 executes the PHR / EMR account linking process described later, the display on the subject terminal 20A changes to the EMR linking notification information display screen shown on the right side of FIG. 38, for example. This screen is configured to display a medical record icon indicating that the medical institution HA has linked with the electronic medical record, but it is configured not to display the EMRID or the patient name on the medical record. This makes it possible to conceal the registered information in the electronic medical record from the subject, avoiding unnecessary confusion for the subject, even if the name, gender, etc. in the electronic medical record differs from the name, gender, etc. that the subject identifies and registers in the PHR application.

[0211] FIG. 39 shows an example of an EMR data display screen when referencing linked PHR data using an EMR application. This screen is configured to display, for example, patient information (e.g., patient name, EMR ID, etc.) for the patient whose EMR data is being viewed at the top of the display unit 34. Below that, for example, the left pane displays a chief complaint record area and a prescription record area, and the right pane displays a test result record area.

[0212] For example, since the user UA and the medical institution HA link an ASD diagnosis application and a medication record application, the prescription record area is configured to display a "Check medication record" function button for viewing PHR data in the medication record application. In addition, the PHR data from the ASD diagnostic application is synchronized and displayed in the test result recording area.

[0213] For example, the PHR data may not be displayed on the EMR data, but a URI for referencing the PHR data may be displayed. Then, for example, when the URI is tapped, the medical institution terminal 30X may be able to refer to the PHR data based on the URI from the management server 10.

[0214] <Processing> 40 and 41 are flowcharts showing an example of the flow of processing executed by each device in this embodiment. From the left, the diagram shows an example of processing executed by the control unit 21 of the subject terminal 20A of the user UA, an example of processing executed by the control unit 31 of the medical institution terminal 30X of the medical institution HX, an example of processing executed by the control unit 51 of the medical institution server 50, and an example of processing executed by the control unit 11 of the management server 10.

[0215] Before the process in this flowchart begins, it is assumed that the user UA and the medical institution HX have registered (created) accounts on the PHR platform, and that a PHR application (e.g., an ASD diagnosis application) identified by the same PHR application ID is installed on the subject terminal 20A and the medical institution terminal 30X. It is also assumed that the medical institution server 50 has assigned an EMRID for storing the patient information of the user UA.

[0216] The following description will be given with reference to FIG.

[0217] For example, when the control unit 31 of the medical institution terminal 30X sends PHR application account linkage request information to the management server 10 (X120), it sends PHR / EMR account linkage request information to the medical institution server 50 (X410), which includes a user account ID and PHR application ID based on the PHR application linkage information, and an EMR ID corresponding to the user of the subject terminal 20A. The PHR / EMR account linking request information may be transmitted by the PHR application processing unit 311. Alternatively, the PHR / EMR account linking request information may be transmitted by the EMR application processing unit 313 using a plug-in or the like in the EMR application.

[0218] When the control unit 31 of the medical institution terminal 30X receives PHR link notification information from the management server 10, the control unit 31 may transmit PHR / EMR account link request information. Furthermore, when the control unit 31 of the medical institution terminal 30X transmits the PHR / EMR account linkage request information, the control unit 31 may transmit EMR linkage notification information indicating that the PHR data has been linked with the EMR application to the management server 10. When the control unit 11 of the management server 10 receives the EMR linkage notification information, the control unit 11 may add and store, for example, EMR linkage flag information to the medical institution account ID in the account ID / PHR application linkage management data 159 based on the medical institution account ID, user account ID, and PHR application ID included in the EMR linkage notification information.

[0219] Furthermore, the PHR / EMR account linking request information may include information that can identify the EMRID (such as the patient's name or date of birth) instead of the EMRID itself. The PHR / EMR account linking request information may not include the PHR application ID.

[0220] When receiving the PHR / EMR account linking request information from the medical institution terminal 30X, the control unit 51 of the medical institution server 50 executes the PHR / EMR account linking process (M410). In the PHR / EMR account linking process, for example, the PHR / EMR linking processing unit 511 adds a record to the PHR / EMR association registration data 559 based on the PHR / EMR account linking request information, and associates and stores the user account ID and the EMR ID. Note that the PHR / EMR linking processing unit 511 may also associate and store the linked PHR application ID with the linked application ID.

[0221] When the PHR / EMR account linking request information is received, the PHR / EMR linking processing unit 511 may identify the EMRID based on information that can identify the EMRID, and then execute the PHR / EMR account linking process.

[0222] In addition, the control unit 51 of the medical institution server 50 may, for example, when executing the PHR / EMR account linking process, send EMR linking notification information to the medical institution terminal 30X indicating that linking between the PHR data and the EMR data has been performed. Upon receiving the EMR linkage notification information from the medical institution server 50, the medical institution terminal 30X may be configured to output (e.g., display) the received EMR linkage notification information (see the center of FIG. 38). Then, the control unit 31 of the medical institution terminal 30X may be configured to transmit the EMR linkage notification information to the subject terminal 20A via the management server 10. Upon receiving the EMR linkage notification information from the management server 10, the control unit 21 of the subject terminal 20A may be configured to output (e.g., display) the received EMR linkage notification information (see the right side of FIG. 38).

[0223] The following description will be given with reference to FIG.

[0224] When the control unit 11 of the management server 10 executes the PHR data recording process (S120), it refers to, for example, the account ID / PHR application linkage management data 159 and sends PHR data update notification information to the medical institution terminal 30 of each medical institution account ID associated with the PHR application ID corresponding to the updated PHR data for the user account ID that updated the PHR data (S410). In addition, the control unit 11 of the management server 10 may be configured to send PHR data update notification information to the medical institution terminal 30 of the medical institution account ID to which EMR linkage flag information has been added in the account ID / PHR application linkage management data 159. The PHR data update notification information may include the user account ID that updated the PHR data and the PHR application ID, and may also include the updated PHR data. The PHR data update notification information may also include a URI for referencing the updated PHR data. The URI may include an access token that enables reference to PHR data updated within a predetermined period on the PHR platform.

[0225] When receiving the PHR data update notification information from the management server 10, the control unit 31 of the medical institution terminal 30X transmits, for example, PHR data reference request information to the management server 10 (X130). Then, the control unit 31 of the medical institution terminal 30X receives the PHR data from the management server 10.

[0226] When the control unit 31 of the medical institution terminal 30X receives the PHR data update notification information, the control unit 31 may, for example, display the information on the display unit 34. Then, the control unit 31 of the medical institution terminal 30X may transmit PHR data reference request information to the management server 10 based on a user input. Furthermore, when the control unit 31 of the medical institution terminal 30X receives PHR data update notification information, it may automatically transmit PHR data reference request information to the management server 10 based on the received PHR data update notification information.

[0227] When receiving the PHR data from the management server 10, the control unit 31 of the medical institution terminal 30X transmits, for example, EMR data update request information to the medical institution server 50 (X420). The EMR data update request information may include the PHR data and the user account ID. The EMR data update request information may also include the PHR application ID.

[0228] The EMR data update request information may include a URI for referencing the updated PHR data.

[0229] When receiving the EMR data update request information from the medical institution terminal 30X, the control unit 51 of the medical institution server 50 executes, for example, an EMR data update process (M420). The EMR data update process may be said to be a process of registering PHR data in EMR data. In the EMR data update process, for example, the control unit 51 of the medical institution server 50 refers to the PHR / EMR association registration data 559 and searches for an EMRID corresponding to the user account ID included in the EMR data update request information. Then, for example, the control unit 51 of the medical institution server 50 adds and stores the PHR data to the EMR data in the EMR patient information database 557 for the searched EMRID. Note that the control unit 51 of the medical institution server 50 may also add and store a URI for referencing the updated PHR data to the EMR data.

[0230] For example, the control unit 31 of the medical institution terminal 30X transmits EMR data reference request information to the medical institution server 50 based on a user input (X430). The EMR data reference request information may include, for example, the EMR ID of the patient for which EMR data is to be referenced. Note that the EMR data reference request information may also include information that can identify the EMR ID of the patient for which EMR data is to be referenced (for example, the patient's name, date of birth, user account ID, etc.).

[0231] When receiving the EMR data reference request information from the medical institution terminal 30X, the control unit 51 of the medical institution server 50 executes EMR data search processing (M430). In the EMR data search process, the control unit 51 of the medical institution server 50, for example, refers to the EMR patient information database 557 based on the EMRID included in the EMR data reference request information, and reads the EMR data from the EMR patient information management data identified by the EMRID. In the EMR data search process, the control unit 51 of the medical institution server 50 may refer to the EMR account registration data 555 and the PHR / EMR association registration data 559, and identify the EMRID based on information that can identify the EMRID.

[0232] Then, the control unit 51 of the medical institution server 50 transmits the read EHR data to the medical institution terminal 30X (M440).

[0233] When the EMR data is received from the medical institution server 50, the control unit 31 of the medical institution terminal 30X, for example, causes the display unit 34 to display and output the received EMR data (X440).

[0234] In addition, if the received EMR data includes a URI for referencing the PHR data, the control unit 31 of the medical institution terminal 30X may receive the PHR data from the management server 10, for example, based on the URI, and display the received PHR data.

[0235] <Effects of the second embodiment> In the second embodiment, as shown in Figures 36, 40, 41, 37, 38, etc., in the medical institution terminal 30 and the medical institution server 50 that provides electronic medical record information, it becomes possible to associate and manage the EMRID, which is the subject's identification information in the medical institution server 50, with the user account ID.

[0236] In addition, in the second embodiment, as shown in Figures 36, 40, and 41, as well as Figures 37 and 38, it becomes possible for the medical institution terminal 30 and the medical institution server 50 that provides electronic medical record information to associate and manage the EMRID, which is the subject's identification information in the medical institution server 50, with the user account ID, making it possible to share PHR data related to the subject's health not only with the management server 10, the subject's PHR application, and the medical institution terminal 30, but also with the medical institution server 50.

[0237] In addition, in the second embodiment, as shown in Figures 36, 40, and 41, as well as Figures 37 to 39, etc., it becomes possible for the medical institution terminal 30 and the medical institution server 50 that provides electronic medical record information to associate and manage the EMRID, which is the subject's identification information in the medical institution server 50, with the user account ID, and the PHR data and / or information related to the PHR data corresponding to the user account ID is associated with the EMRID and registered in the medical institution server 50, and in response to a request for EMR data from the medical institution terminal 30 using the EMRID, it becomes possible to provide the EMR data and / or information related to the PHR data to the medical institution terminal 30.

[0238] In the above embodiment, the PHR data is registered in the management server 10, the PHR data is provided from the management server 10 to the medical institution terminal 30, and the EMR data is updated, but the present invention is not limited to this. For example, the subject terminal 20 may register PHR data in the PHR application management server 60, which is a management server corresponding to the PHR application, and the management server 10 may then query the PHR application management server 60, thereby allowing the management server 10 to acquire the PHR data registered in the PHR application management server 60 and transmit the acquired PHR data to the medical institution server 50 and the medical institution terminal 30. The medical institution terminal 30 may receive the PHR data via the medical institution server 50. The medical institution server 50 may update the EMR data based on the received PHR data.

[0239] Furthermore, the PHR data may be transmitted to the medical institution terminal 30 without passing through either the management server 10 or the medical institution server 50. In other words, the management server 10 may request the PHR application management server 60 to transmit the PHR data directly from the PHR application management server 60 to the medical institution terminal 30. Upon receiving the request, the PHR application management server 60 may transmit the PHR data directly to the medical institution terminal 30. Note that the PHR application management server 60 may transmit the PHR data to the medical institution server 50, and the medical institution server 50 may update the EMR data based on the received PHR data.

[0240] For example, the management server 10 may inquire about the PHR data acquired by the subject terminal 20 from the subject terminal 20, and transmit the PHR data acquired from the subject terminal 20 to the medical institution terminal 30. Alternatively, the management server 10 may transmit the PHR data to the medical institution server 50, and the medical institution server 50 may update the EMR data based on the received PHR data.

[0241] <Second Modification Example (1)> In the above embodiment, the PHR application linkage code information is transmitted from the subject terminal 20 to the medical institution terminal 30, but this is not limiting. For example, the PHR application linkage code information presented to the medical institution terminal 30 may be read by the subject terminal 20.

[0242] 42 and 43 are diagrams showing examples of screens displayed on display unit 24 of subject terminal 20A and display unit 34 of medical institution terminal 30A in this modification.

[0243] For example, when the function button HM2 is tapped on the medical institution side ASD diagnostic application main menu screen on the left side of FIG. 23 on the medical institution terminal 30A, the display on the medical institution terminal 30A changes to the PHR application link code information display screen on the left side of FIG. This screen is configured to display, for example, an EMRID token in addition to PHR application link code information indicated by a two-dimensional code and the name of the medical institution in the PHR application. The EMRID token is, for example, a token (for example, character string information) related to the EMRID on the electronic medical record corresponding to the subject of the subject terminal 20A, which is included in the PHR application linkage code information. By using the EMRID token, the user of the medical institution terminal 30A can reliably exchange the EMRID that matches the user of the subject terminal 20A.

[0244] If a validity period or expiration date is set for the EMRID token, the validity period or expiration date of the EMRID token may be displayed on the PHR application linkage code information display screen.

[0245] For example, when function button UM3 is tapped on the subject-side ASD diagnostic application main menu screen on the right side of Fig. 23 on the subject terminal 20A, the display on the subject terminal 20A changes to the PHR application linkage code information reading screen shown in the center of Fig. 42. When the PHR application linkage code information is read on the medical institution terminal 30A, the display on the subject terminal 20A changes to the PHR data sharing confirmation screen shown on the right side of Fig. 42.

[0246] On this screen, for example, based on the fact that an EMRID token is embedded in the PHR application linkage code information, the notes column displays that PHR data will be linked with EMR data.

[0247] For example, when the user taps the PHR data sharing function button UC4, the PHR application account linking process is executed in the management server 10. Then, the display on the medical institution terminal 30A changes to the PHR linking notification information display screen shown on the left side of FIG. This screen is configured to display a function button MB5 for linking with EMRID based on the EMRID token, and a function button MB6 for only linking with PHR data without linking with the electronic medical record.

[0248] For example, when the user taps the function button MB5, the PHR / EMR account linking process is executed in the medical institution server 50, and the display on the medical institution terminal 30A changes to the EMR linking notification information display screen shown in the center of FIG. This screen shows that the user account ID and EMRID account were automatically linked based on the EMRID token.

[0249] Furthermore, for example, when the PHR / EMR account linking process is executed by the medical institution server 50, the display on the subject terminal 20A changes to the EMR linking notification information display screen shown on the right side of FIG.

[0250] Unlike this example, the EMRID token may not be used, and the EMRID may be manually input into the medical institution terminal 30A to execute the PHR / EMR account linking process.

[0251] 44 is a flowchart showing an example of the flow of processing executed by each device in this modification. From the left, this figure shows an example of processing executed by the control unit 21 of the subject terminal 20A of the user UA, an example of processing executed by the control unit 31 of the medical institution terminal 30X of the medical institution HX, an example of processing executed by the control unit 51 of the medical institution server 50, and an example of processing executed by the control unit 11 of the management server 10.

[0252] First, the control unit 31 of the medical institution terminal 30X executes a PHR application linkage code information generation process based on, for example, a user input (X210). In the PHR application linkage code information generation process, the control unit 31 of the medical institution terminal 30X sends, for example, EMRID token request information to the medical institution server 50, which includes the EMRID of the patient corresponding to the user of the subject terminal 20 that presents the PHR application linkage code information.

[0253] When receiving the EMRID token request information from the medical institution terminal 30X, the control unit 51 of the medical institution server 50 executes, for example, a PHR application linkage token generation process (M510). In the PHR application linkage token generation process, the control unit 51 of the medical institution server 50 generates a token based on, for example, the received EMRID. Then, the control unit 51 of the medical institution server 50 associates the generated token with the EMRID and stores them in the storage unit 55. Note that an expiration date or validity period may be set for the token. Then, the control unit 51 of the medical institution server 50 transmits EMRID token information including the generated token to the medical institution terminal 30X.

[0254] When receiving the EMRID token information from the medical institution server 50, the control unit 31 of the medical institution terminal 30X generates PHR application linkage code information based on the PHR application linkage information including the token, for example, and displays it (X220).

[0255] The PHR application linkage information and the PHR application linkage code information may include the EMRID instead of a token. Also, the PHR application linkage information and the PHR application linkage code information may not include the EMRID or a token related to the EMRID.

[0256] The control unit 21 of the subject terminal 20A uses, for example, the imaging unit 27 to read the PHR application linkage code information displayed on the medical institution terminal 30X, and acquires the PHR application linkage information (A210). Then, the control unit 21 of the subject terminal 20A transmits PHR application account linking request information including the medical institution account ID, the PHR application ID, the user account ID of the subject terminal 20A, and the token or EMRID to the management server 10 (A510).

[0257] When receiving the PHR application account linking request information from the subject terminal 20A, the control unit 11 of the management server 10 executes the PHR application account linking process (S210). Then, the control unit 11 of the management server 10 transmits the PHR linkage notification information to the medical institution terminal 30X (S510). Here, if the PHR application account linkage request information includes a token or EMRID, the control unit 11 of the management server 10 transmits the PHR linkage notification information including the token and EMRID to the medical institution terminal 30X. Because the management server 10 cannot decode the token, using the token can prevent the subject's EMRID from being leaked to the outside.

[0258] Then, the control unit 31 of the medical institution terminal 30X sends PHR / EMR account linkage request information to the medical institution server 50 (X510), which includes, for example, a user account ID and PHR application ID based on the PHR linkage notification information, and an EMR ID or token corresponding to the user of the subject terminal 20A. In addition, if the PHR linkage notification information does not include an EMRID or a token, the control unit 31 of the medical institution terminal 30X may, for example, acquire an EMRID corresponding to the user of the subject terminal 20A or information that can identify the EMRID based on user input.

[0259] When receiving the PHR / EMR account link request information from the medical institution terminal 30X, the control unit 51 of the medical institution server 50 executes, for example, a PHR / EMR account search process (M520). In the PHR / EMR account search process, the control unit 51 of the medical institution server 50, for example, refers to the token and EMRID stored in the PHR application linking token generation process, and searches for the EMRID corresponding to the token included in the PHR / EMR account linking request information. Once the EMRID is found, the control unit 51 of the medical institution server 50 may delete the found EMRID and token from the storage unit 55.

[0260] If the PHR / EMR account link request information includes an EMRID, the control unit 51 of the medical institution server 50 may not execute the PHR / EMR account search process.

[0261] <Second Modification Example (2)> In the above embodiment, the PHR application linking code information is transmitted from the subject terminal 20 to the medical institution terminal 30, but this is not limiting. For example, the PHR application account linking process may be executed by selecting a medical institution with which to share PHR data on the subject terminal 20.

[0262] FIG. 45 is a diagram showing an example of a screen displayed on the display unit 34 of the medical institution terminal 30A in this modification. For example, as in Figures 26 to 27, when a medical institution with which to collaborate is selected on the subject terminal 20 and the PHR application account collaboration process is executed on the management server 10, the PHR collaboration notification information display screen shown on the left side of Figure 45 is displayed on the medical institution terminal 30A. When the user taps the function button MB5 on this screen, the display changes to the linked EMRID input screen shown in the center of FIG. 45 on the medical institution terminal 30A, for example. Then, when the function button MB9 for linking the entered EMRID with the user account ID displayed in the linked EMRID input area ARR is tapped, the PHR / EMR account linking process is executed in the medical institution server 50, and, for example, the display on the medical institution terminal 30A changes to the EMR linking notification information display screen shown on the right side of Figure 45.

[0263] 46 is a flowchart showing an example of the flow of processing executed by each device in this modification. From the left, this figure shows an example of processing executed by the control unit 21 of the subject terminal 20A of the user UA, an example of processing executed by the control unit 31 of the medical institution terminal 30X of the medical institution HX, an example of processing executed by the control unit 51 of the medical institution server 50, and an example of processing executed by the control unit 11 of the management server 10.

[0264] For example, when the control unit 11 of the management server 10 executes the PHR application account linking process (S210), it transmits PHR linking notification information to the medical institution terminal 30X (S510). The PHR linkage notification information may include, for example, the user account ID and PHR application ID of the subject terminal 20A that linked the PHR data.

[0265] When the PHR linkage notification information is received from the management server 10, for example, the control unit 31 of the medical institution terminal 30X displays the received PHR linkage notification information on the display unit 34. Then, the control unit 31 of the medical institution terminal 30X executes an EMRID acquisition process (X550). In the EMRID acquisition process, the control unit 31 of the medical institution terminal 30X receives, for example, an EMRID corresponding to the user of the subject terminal 20A or information capable of identifying the EMRID, based on a user input.

[0266] Then, the control unit 31 of the medical institution terminal 30X transmits PHR / EMR account linking request information including the acquired EMRID or information that can identify the EMRID to the management server 10 (X410).

[0267] <Second Modification Example (3)> In the above embodiment, the EMR service is linked to the PHR platform without expanding the data related to the EMR service, but this is not limiting. For example, the EMR patient information management database 557B may be expanded to link to the PHR platform.

[0268] FIG. 47 shows an EMR patient information management database 557B, which is another example of the data configuration of the EMR patient information database 557. In the EMR patient information management database 557B, for example, EMR patient information management data is stored as management data for each EMRID. In each EMR patient information management data, for example, an EMR ID, a user account ID, EMR data, and PHR data management data are stored in association with each other.

[0269] It should be noted that the PHR / EMR association registration data 559 may not be used. Also, for example, if the EMR application management processing program 553 is equipped with an API for a PHR application, the PHR / EMR linkage processing program 551 may not be used.

[0270] For example, in the PHR / EMR account linking process, the control unit 51 of the medical institution server 50 may store the EMR ID and the user account ID in association with the EMR patient information management data.

[0271] Furthermore, for example, in the EMR data update process, the control unit 51 of the medical institution server 50 may store the PHR data in the EMR data update request information in association with the PHR data management data of the EMR patient information management data.

[0272] <Third Example> The third example relates to a case where a subject is registered as a patient in an electronic medical record system of a medical institution but is not registered as a user of the PHR platform. This example may be said to be an example in which a medical professional at a medical institution prescribes a PHR application to a subject.

[0273] The contents described in the third embodiment can be similarly applied to any of the other embodiments and other modified examples.

[0274] <Display screen> 48 and 49 are diagrams showing examples of screens displayed on display unit 24 of subject terminal 20A and display unit 34 of medical institution terminal 30A in this embodiment.

[0275] For example, when a user taps function button HM3 on the main menu screen of the medical institution side ASD diagnostic application on the left side of Figure 48 on the medical institution terminal 30A, the display on the medical institution terminal 30A changes to the PHR application user account creation request information display screen in the center of Figure 48.

[0276] This screen is configured to display, for example, PHR application user account creation request information indicated by a two-dimensional code, the name of the PHR application that the user of the subject terminal 20A is prompted to install, which is included in the PHR application user account creation request information before encoding, and the name of the medical institution that uses the medical institution terminal 30A.

[0277] For example, when a camera application is launched based on user input on the subject terminal 20A, the display on the subject terminal 20A changes to the camera preview screen shown on the right side of Fig. 48. On this screen, for example, the two-dimensional code of the PHR application user account creation request information is projected onto the preview screen of the image acquired by the imaging unit 37, and the two-dimensional code is decoded, and an "Install Application" button, which is a link to the URI included in the decoded information, is displayed. When the user taps the "Install Application" button, for example, an application designated in the PHR application user account creation request information (in this example, an ASD diagnosis application) is installed in the subject terminal 20A.

[0278] The left side of Figure 49 is an example of a PHR platform user registration screen for the ASD diagnostic application, which is displayed on the subject terminal 20A after the application is installed. On this screen, for example, the PHR platform user registration information input area URR is configured to display text boxes for inputting a username and password. Below that, the medical institution account ID that will be linked to the user account ID created based on the information entered in the text boxes is automatically entered based on the PHR application user account creation request information, and is set to be grayed out and unchangeable. In addition, the PHR platform user registration information input area URR may be configured to allow various user information such as birthday and gender to be input.

[0279] When a username and password are entered in the text box and the account creation function button CB to create a PHR platform user account is tapped, a user account ID is assigned to the user of the subject terminal 20A in the management server 10, and the PHR medical institution account registration data 155 is updated.

[0280] Then, for example, the display on the subject terminal 20A changes to the PHR data sharing confirmation screen shown in the center of FIG. On this screen, for example, based on the fact that an EMRID token is embedded in the PHR application user account creation request information, the notes column displays that PHR data will be linked with EMR data.

[0281] For example, when a user taps the PHR data sharing function button UC4, the management server 10 executes the PHR application account linking process, and the medical institution server 50 executes the PHR / EMR account linking process. Then, the EMR linking notification information display screen shown on the right side of Figure 49 is displayed on the medical institution terminal 30A.

[0282] Unlike this example, user account registration to the PHR platform may be performed in a PHR integrated application or a web application of a PHR platform service provided as SaaS.

[0283] <Processing> 50 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. From the left, this figure shows an example of processing executed by the control unit 21 of the subject terminal 20A of the user UA, an example of processing executed by the control unit 31 of the medical institution terminal 30X of the medical institution HX, an example of processing executed by the control unit 51 of the medical institution server 50, and an example of processing executed by the control unit 11 of the management server 10.

[0284] Before the process in this flowchart begins, the medical institution HX has registered (created) an account on the PHR platform, and a PHR application (e.g., an ASD diagnosis application) identified by a predetermined PHR application ID has been installed on the medical institution terminal 30X. The medical institution server 50 is also assumed to have assigned an EMRID for storing patient information of the user UA.

[0285] First, the control unit 31 of the medical institution terminal 30X executes a PHR application user account creation request information generation process based on, for example, user input (X610). In the PHR application user account creation request information generation process, the control unit 31 of the medical institution terminal 30X generates PHR application user account creation request information that includes, for example, the medical institution account ID of the medical institution terminal 30X and the PHR application ID of the PHR application that the subject is requested to install. The PHR application user account creation request information may include, for example, installation guide information for installing a specific PHR application (e.g., the URI of an app store or download site), and account registration guide information for registering as a user on the PHR platform (e.g., the URI to an account creation page on the management server 10). The PHR application user account creation request information may be encoded into, for example, one-dimensional code or two-dimensional code information. The PHR application user account creation request information may include information for identifying the medical institution (for example, the name of the medical institution) and the EMRID corresponding to the user of the subject terminal 20A.

[0286] The PHR application that the subject is requested to install may be, for example, an arbitrary application registered in the PHR application registration data 157, based on a user input to the medical institution terminal 30X.

[0287] Furthermore, the medical institution terminal 30X and the medical institution server 50 may generate an EMRID token and include it in the PHR application user account creation request information, for example, as in FIG.

[0288] When the control unit 31 of the medical institution terminal 30X generates PHR application user account creation request information, which is, for example, two-dimensional code information, it causes the display unit 34 to display and output it (X620). Note that the control unit 31 of the medical institution terminal 30X may transfer the PHR application user account creation request information to the subject terminal 20A through P2P communication using, for example, short-range wireless communication such as Bluetooth or NFC.

[0289] For example, based on a user input, the control unit 21 of the subject terminal 20A reads the PHR application user account creation request information displayed on the medical institution terminal 30X using the imaging unit 27 (A610). Then, the control unit 21 of the subject terminal 20A may receive information (e.g., a user name, a password, etc.) required for registering a user account on the PHR platform based on, for example, the account registration guide information.

[0290] The control unit 21 of the subject terminal 20A may accept the PHR application user account creation request information by accepting, for example, a medical institution account ID or a PHR application ID displayed on the medical institution terminal 30X through user input.

[0291] Then, the control unit 21 of the subject terminal 20A transmits, for example, information required for user account registration, and PHR application user account creation request information including the medical institution account ID and PHR application ID of the medical institution terminal 30X to the management server 10 (A620). The PHR application user account creation request information may include an EMRID token or EMRID.

[0292] When receiving the PHR application user account creation request information from the subject terminal 20A, the control unit 11 of the management server 10 executes, for example, a PHR application account creation process (S610). In the PHR application account creation process, the control unit 11 of the management server 10 adds and stores a record relating to the new user to the PHR user account registration data 153, for example, based on the received PHR application user account creation request information.

[0293] Then, the control unit 11 of the management server 10 transmits, for example, PHR application account information including the user account ID assigned to the user of the subject terminal 20A to the subject terminal 20A (S620). Note that the PHR application account information may also include installation guide information.

[0294] Then, the control unit 11 of the management server 10 executes, for example, a PHR application account linking process (S630). In the PHR application account linking process, the control unit 11 of the management server 10 associates the user account ID assigned to the user of the subject terminal 20A with the medical institution account ID and PHR application ID based on the PHR application user account creation request information, for example, similar to step S210 in Figure 44.

[0295] When receiving the PHR application account information from the management server 10, the control unit 21 of the subject terminal 20A executes, for example, a PHR application installation process (A630). In the PHR application installation process, the control unit 21 of the subject terminal 20A installs a predetermined PHR application based on, for example, the installation guide information, and executes the PHR application using the user account ID received in the PHR application account information.

[0296] For example, when the control unit 21 of the subject terminal 20A receives the PHR application user account creation request information, the control unit 21 may execute a PHR application installation process and acquire information necessary for registering a user account on the PHR platform in the PHR application that was launched without user registration. Thereafter, the control unit 21 of the subject terminal 20A may transmit the PHR application user account creation request information to the management server 10.

[0297] <Effects of the third embodiment> In the third embodiment, as shown in Figures 48, 50, etc., when the subject terminal 20 acquires a medical institution account ID from the medical institution terminal 30, a user account ID is created and a PHR application associated with the medical institution account ID is installed on the subject terminal 20.Therefore, when the subject acquires a medical institution account ID from the medical institution terminal 30 using his or her own subject terminal 20 at the medical institution, the subject can easily use the PHR application that the medical institution wants the subject to use.

[0298] Furthermore, in the third embodiment, as shown in Figures 49, 50, etc., the user account ID and EMRID are associated and managed based on the consent of the subject on the subject terminal 20 on which the PHR application is installed, so that after the PHR application is installed on the subject terminal 20 at a medical institution, medical personnel at the medical institution can check the PHR data obtained by the PHR application through the electronic medical record system.

[0299] <Third Modification (1)> In the above embodiment, the medical institution terminal 30 specifies the PHR application to be installed on the subject terminal 20 (prescribed by the medical institution to the subject), but this is not limiting. For example, the PHR application user account creation request information may not include the PHR application ID.

[0300] In this case, for example, the control unit 11 of the management server 10 may include list information of PHR applications in the PHR application account information. Then, the control unit 21 of the subject terminal 20A may install one or more desired PHR applications from the list information of PHR applications into the subject terminal 20A all at once based on, for example, user input.

[0301] In addition, the control unit 21 of the subject terminal 20A may specify a PHR application ID from among the installed PHR applications that will link with the medical institution terminal 30, and send PHR application account linkage request information including the specified PHR application ID to the management server 10. When receiving the PHR application account linking request information from the subject terminal 20A, the control unit 11 of the management server 10 may execute the PHR application account linking process for the specified PHR application ID.

[0302] The PHR application user account creation request information may include multiple PHR application IDs that can be installed on the subject terminal 20. The PHR application user account creation request information may also include any PHR application ID selected by the user of the subject terminal 20. Then, the control unit 11 of the management server 10 may include, for example, installation guide information based on the selected arbitrary PHR application ID in the PHR application account information. The control unit 11 of the management server 10 may execute the PHR application account linking process for each PHR application ID selected by the user of the subject terminal 20, for example.

[0303] <Third Modification (2)> In the above embodiment, the case where the user of the subject terminal 20A has not registered an account on the PHR platform is illustrated, but the present invention is not limited to this. For example, the user of the subject terminal 20A may be registered on the PHR platform (having a user account ID), but may not have installed the PHR application that the user of the medical institution terminal 30 requests the subject to install.

[0304] In this case, for example, the control unit 21 of the subject terminal 20A may execute a PHR application installation process when it reads the PHR application user account creation request information. Then, the control unit 21 of the subject terminal 20A may transmit PHR application account linking request information to the management server 10, which includes, for example, a medical institution account ID, a PHR application ID, and a user account ID based on the PHR application user account creation request information.

[0305] <Fourth Example> The fourth embodiment is an embodiment in which, for example, the association between the user account ID corresponding to the subject and the medical institution account ID is cancelled.

[0306] The contents described in the fourth embodiment can be similarly applied to any of the other embodiments and other modified examples.

[0307] <Display screen> 51 and 52 are diagrams showing examples of screens displayed on display unit 24 of subject terminal 20A and display unit 34 of medical institution terminal 30A in this embodiment.

[0308] On the main menu screen of the subject-side ASD diagnostic application on the left side of Figure 51 of the subject terminal 20A, for example, when the user taps the setting function button MNB, the PHR application setting menu area MNR is displayed. In the PHR application setting menu area MNR, for example, when the user taps the item to cancel PHR data linkage with medical institution, the display on the subject terminal 20A changes to the PHR application linked medical institution list information display screen shown in the center of Figure 51.

[0309] This screen is configured to display, for example, a list of medical institutions that share PHR data in the ASD diagnostic application with the user UA. For example, when a medical institution HA is tapped, it is highlighted, indicating that it has been selected. For example, when a medical institution HA is selected and the user taps the function button DC for canceling the linkage of the PHR application, a PHR application linkage cancellation process, which will be described later, is executed in the management server 10. Then, for example, the display on the subject terminal 20A changes to the PHR application account linkage cancellation notification information display screen shown on the right side of Fig. 51.

[0310] On this screen, of the PHR applications that were linked between the medical institution HA and the subject HA, the icon to the left of the application name indicates that the ASD diagnosis application has been disconnected. It also indicates that the medication record application remains connected.

[0311] Furthermore, for example, when the PHR application linkage cancellation process is executed in the management server 10, the PHR application account linkage cancellation notification information display screen shown on the left side of Figure 52 is displayed on the medical institution terminal 30A. This screen shows that the ASD diagnostic application has been disconnected from user UA, but the EMR data on the medical institution server 50 still contains PHR data for the ASD diagnostic application and medication management application.

[0312] The bottom of the screen is configured to display, for example, a function button BT1 for deleting the PHR data of the ASD diagnostic application that has already been recorded in the EMR data from the EMR data, and a function button BT2 for canceling the link without deleting the PHR data of the ASD diagnostic application that has been recorded in the EMR data.

[0313] For example, when the user taps the function button BT1, the PHR / EMR account linkage cancellation process described below is executed in the medical institution server 50. Then, for example, the PHR / EMR account linkage cancellation notification information display screen shown on the right side of Figure 52 is displayed on the medical institution terminal 30A. This screen shows that the PHR data for the ASD diagnosis application has been deleted from the EMR data. It also shows that the medical institution HA and user UA maintain cooperation with the medication record application, and that the PHR data for the medication record application has been recorded in the EMR data.

[0314] <Processing> 53 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. From the left, this figure shows an example of processing executed by the control unit 21 of the subject terminal 20A of the user UA, an example of processing executed by the control unit 31 of the medical institution terminal 30X of the medical institution HX, an example of processing executed by the control unit 51 of the medical institution server 50, and an example of processing executed by the control unit 11 of the management server 10.

[0315] It should be noted that before the processing in this flowchart begins, collaboration on the PHR platform is established between the user UA and the medical institution HX, for example, according to the processing in Figures 40 to 41, and data sharing is taking place between the PHR data and the electronic medical record service.

[0316] For example, based on user input, the control unit 21 of the subject terminal 20A sends PHR application-linked medical institution list request information to the management server 10 to request a list of medical institutions that are linked with the user account ID of the subject terminal 20A (A710). The request information for a list of medical institutions linked with PHR applications may include, for example, a PHR application ID designated by the user of the subject terminal 20A.

[0317] When receiving the request information for a list of medical institutions linked with PHR applications from the subject terminal 20A, the control unit 11 of the management server 10 executes, for example, a process for searching for medical institutions linked with PHR applications (S710). In the process of searching for medical institutions that have PHR application integration, the control unit 11 of the management server 10, for example, refers to the account ID / PHR application integration management data 159 and searches for integrated medical institution account IDs for each PHR application ID associated with the user account ID of the subject terminal 20A.

[0318] Then, the control unit 11 of the management server 10 transmits a list of medical institutions linked with PHR applications, including a list of the searched medical institution account IDs, to the subject terminal 20A. The list of medical institutions linked with PHR applications may include the PHR application ID and the linked medical institution account ID specified in the request information for a list of medical institutions linked with PHR applications.

[0319] When receiving the list of medical institutions with linked PHR applications from the management server 10, the control unit 21 of the subject terminal 20A, for example, displays the received list of medical institutions with linked PHR applications on the display unit 24 (A720).

[0320] For example, when a medical institution to be unlinked is selected based on user input to the displayed list of medical institutions linked with PHR applications, the control unit 21 of the subject terminal 20A sends PHR application unlink request information to the management server 10, which includes the user account ID of the subject terminal 20A and the account ID of the selected medical institution (A730). The PHR application linkage cancellation request information may include, for example, the PHR application ID of the PHR application for which the linkage has been designated to be cancelled by the user of the subject terminal 20. Alternatively, the linkage with a certain medical institution account ID may be cancelled all at once without designating a PHR application ID.

[0321] When receiving the PHR application linkage cancellation request information from the subject terminal 20A, for example, the control unit 11 of the management server 10 executes a PHR application linkage cancellation process (S730). In the PHR application linkage cancellation process, the control unit 11 of the management server 10 deletes the medical institution account ID from the account ID / PHR application linkage management data 159, for example, based on the received PHR application linkage cancellation request information.

[0322] Then, for example, the control unit 11 of the management server 10 sends PHR application account linkage cancellation notification information indicating that the linkage of the PHR application has been cancelled to the medical institution terminal 30X of the deleted medical institution account ID (S740). The PHR application account linkage cancellation notification information may include the PHR application ID of the PHR application whose linkage has been cancelled. Furthermore, the control unit 11 of the management server 10 may be configured to transmit PHR application account linkage cancellation notification information to the subject terminal 20A.

[0323] Upon receiving PHR application account linkage cancellation notification information from the management server 10, the control unit 31 of the medical institution terminal 30X sends PHR / EMR account linkage cancellation request information to the medical institution server 50, for example, including the user account ID and PHR application ID contained in the PHR application account linkage cancellation notification information (X710). The PHR / EMR account linkage cancellation request information may include, for example, PHR data in EMR data deletion request information for deleting PHR data stored in the EMR data. The control unit 31 of the medical institution terminal 30X may be configured to automatically send PHR / EMR account linkage cancellation request information when receiving PHR application account linkage cancellation notification information from the management server 10. The control unit 31 of the medical institution terminal 30X may also be configured to output the PHR application account linkage cancellation notification information and send the PHR / EMR account linkage cancellation request information based on, for example, user input.

[0324] When receiving the PHR / EMR account linkage cancellation request information from the medical institution terminal 30X, the control unit 51 of the medical institution server 50 executes, for example, a PHR / EMR account linkage cancellation process (M710). In the PHR / EMR account linkage cancellation process, the control unit 51 of the medical institution server 50, for example, refers to the PHR / EMR association registration data 559 and deletes the PHR application ID whose linkage has been cancelled from the linked application ID for the user account ID specified in the PHR / EMR account linkage cancellation request information. In addition, if the control unit 51 of the medical institution server 50 determines, for example, that all linked application IDs for a certain user account ID have been deleted, or that all linkages for a certain user account ID have been canceled at once, it may delete the record in which the user account ID is linked to the EMRID.

[0325] In addition, if it is determined that the PHR / EMR account linkage cancellation request information includes PHR data deletion request information within the EMR data, the control unit 51 of the medical institution server 50 may, for example, refer to the EMR patient information database 557 and delete the PHR data from the EMR data of the EMR ID linked to the user account ID specified in the PHR / EMR account linkage cancellation request information.

[0326] Furthermore, when the control unit 51 of the medical institution server 50 executes the PHR / EMR account linkage cancellation process, it may transmit PHR / EMR account linkage cancellation notification information to the medical institution terminal 30X.

[0327] In this flowchart, it is assumed that the electronic medical record service is provided by the medical institution server 50, but this is not limited to this. Referring to the first embodiment, the PHR account linkage cancellation process can be executed in the same way even if the medical institution server 50 does not exist.

[0328] <Effects of the Fourth Embodiment> In the fourth embodiment, as shown in Figures 51, 53, etc., the link between the user account ID corresponding to the subject and the medical institution account ID is released in response to the subject's operation on the subject terminal 20, so that if the subject wants to stop sharing PHR data with a medical institution or wants to change the medical institution with which the subject is willing to share PHR data, the subject can stop sharing by operating their own terminal.

[0329] Furthermore, in the fourth embodiment, as shown in Figures 52, 53, etc., in response to operations by medical personnel on the medical institution terminal 30, the PHR data acquired by the PHR application and managed by the medical institution server 50 in association with the EMRID, which is the subject's identification information on the medical institution terminal 30 and the medical institution server 50 that provides electronic medical record information, is erased, thereby enabling the medical institution to manage data in a way that respects the subject's wishes not to share PHR data.

[0330] <Fourth Modification (1)> In the above embodiment, the PHR application linkage is cancelled by the subject terminal 20. However, this is not limiting. For example, the PHR application linkage may be cancelled by the medical institution terminal 30.

[0331] For example, when PHR application integration is terminated based on user input to the medical institution terminal 30, the control unit 31 of the medical institution terminal 30X may send PHR application integration termination request information to the management server 10, which includes the user account ID for which the integration is to be terminated and the PHR application ID.

[0332] If the set conditions are met, the control unit 31 of the medical institution terminal 30X may automatically send PHR application linkage cancellation request information to the management server 10. Here, the setting conditions may be as follows: (C1) The subject has not received medical treatment at the medical institution of the medical institution terminal 30X for a predetermined period (for example, one year) or more, or the electronic medical record of a certain MERID has not been edited or viewed for a predetermined period or more. (C2) In a PHR application that is linked to PHR data, if the PHR data has not been updated for a specified period (e.g., six months).

[0333] For example, in the case of (C1) above, the PHR application linkage cancellation request information may include request information for canceling linkage in all PHR applications.

[0334] Furthermore, for example, in the case of (C2) above, the PHR application linkage cancellation request information may include the PHR application ID related to the PHR data that has not been updated.

[0335] In this way, the link between the user account ID corresponding to the subject and the medical institution account ID is automatically released according to the set conditions, thereby making data management more efficient.

[0336] <Fifth Example> The fifth embodiment relates to storing PHR data, which is information that requires careful handling and is privacy-related, in the management server 10 in an encrypted state.

[0337] The contents described in the fifth embodiment can be similarly applied to any of the other embodiments and other modified examples.

[0338] <System configuration> FIG. 54 shows PHR / EMR association registration data 559B, which is another example of the PHR / EMR association registration data 559 in this embodiment. In the PHR / EMR association registration data 559B, for example, a PHR data decryption key is stored in association with the user account ID, EMR ID, and linked application ID.

[0339] The PHR data decryption key is a decryption key for decrypting encrypted PHR data (referred to as "encrypted PHR data"). The encryption method for PHR data may be, for example, a common key encryption method or a public key encryption method. In the case of a symmetric key cryptosystem, the PHR data decryption key may be referred to as a private key linked to the user account ID. In the case of a public key cryptosystem, the PHR data decryption key may be referred to as a public key linked to the user account ID. The decryption key may be different for each PHR application ID.

[0340] <Processing> 55 and 56 are flowcharts showing an example of the flow of processing executed by each device in this embodiment. From the left, these figures show an example of processing executed by the control unit 21 of the subject terminal 20A of the user UA, an example of processing executed by the control unit 31 of the medical institution terminal 30X of the medical institution HX, an example of processing executed by the control unit 51 of the medical institution server 50, and an example of processing executed by the control unit 11 of the management server 10.

[0341] In this flowchart, a case of a common key cryptosystem is illustrated, and it is assumed that a private key is generated in subject terminal 20A and stored in storage unit 28 prior to the processing.

[0342] The following explanation will be given with reference to FIG.

[0343] The control unit 21 of the subject terminal 20A executes a process for generating linked code information with a PHR application decryption key based on, for example, a user input (A810). In the process of generating linked code information with a PHR application decryption key, the control unit 21 of the subject terminal 20A generates linked code information with a PHR application decryption key, which is a two-dimensional code, based on, for example, PHR application linkage information and linked information with a PHR application decryption key that includes a private key stored in the memory unit 28.

[0344] Then, the control unit 21 of the subject terminal 20A, for example, displays the generated link code information with the PHR application decryption key on the display unit 24 (A820).

[0345] For example, based on a user input, the control unit 31 of the medical institution terminal 30X uses the imaging unit 37 to read the link code information with the PHR application decryption key displayed on the subject terminal 20A (X810). Then, the control unit 31 of the medical institution terminal 30X decodes the read link code information with PHR application decryption key, and acquires link information with PHR application decryption key.

[0346] The method of transferring the link information with the PHR application decryption key is not limited to using a code image. For example, the control unit 21 of the subject terminal 20A may transfer the link information with the PHR application decryption key to the medical institution terminal 30X by P2P communication using short-range wireless communication such as Bluetooth or NFC.

[0347] For example, the PHR application account linking request information may not include the decryption key. In other words, the decryption key may not be stored in the management server 10.

[0348] For example, when the control unit 31 of the medical institution terminal 30X sends PHR application account linkage request information to the management server 10, it sends PHR / EMR account linkage request information with a decryption key, which includes the user account ID, PHR application ID, EMR ID, and decryption key, to the medical institution server 50 (X820).

[0349] When receiving the PHR / EMR account linking request information with decryption key from the medical institution terminal 30X, the control unit 51 of the medical institution server 50 executes the PHR / EMR account linking process with decryption key (M810). In the PHR / EMR account linking process with decryption key, for example, the PHR / EMR linking processing unit 511 adds a record to the PHR / EMR association registration data 559 based on the PHR / EMR account linking request information with decryption key, and associates and stores the user account ID, EMR ID, and decryption key.

[0350] For example, when the control unit 21 of the subject terminal 20A executes the PHR data acquisition process (A130), it executes the PHR data encryption process (A830). In the PHR data encryption process, the control unit 21 of the subject terminal 20A encrypts the acquired PHR data using the private key stored in the storage unit 28, for example, to generate encrypted PHR data.

[0351] Then, the control unit 21 of the subject terminal 20A transmits encrypted PHR data recording request information including the encrypted PHR data to the management server 10 (A840).

[0352] When the encrypted PHR data recording request information is received from the subject terminal 20A, the control unit 11 of the management server 10 executes an encrypted PHR data recording process (S820). In the encrypted PHR data recording process, the control unit 11 of the management server 10 stores the encrypted PHR data in association with the PHR application ID in the PHR data management data, for example.

[0353] Since the management server 10 does not have the decryption key, it is not possible to extract the PHR data from the encrypted PHR data.

[0354] For example, when the control unit 11 of the management server 10 executes the PHR data search process (S130), it transmits the encrypted PHR data to the medical institution terminal 30X (S830).

[0355] In the medical institution terminal 30X, for example, since the decryption key is not stored, it is not possible to extract the PHR data from the encrypted PHR data.

[0356] The following explanation will be given with reference to FIG.

[0357] For example, when EMR data reference request information is received from the medical institution terminal 30X and an EMR data search process is executed (M430), the control unit 51 of the medical institution server 50 executes a PHR data decryption process (M820). In the PHR data decryption process, the control unit 51 of the medical institution server 50, for example, refers to the PHR / EMR association registration data 559, decrypts the encrypted PHR data stored in the EMR data of the EMR patient information management data using the PHR data decryption key, and acquires the PHR data. Then, the control unit 51 of the medical institution server 50, for example, transmits the EMR data including the decrypted PHR data to the medical institution terminal 30X (M440).

[0358] In addition, the control unit 51 of the medical institution server 50 may, for example, execute a PHR data decryption process when executing an EMR data update process, and store the decrypted PHR data in the EMR data of the EMR patient information management data.

[0359] Furthermore, the control unit 31 of the medical institution terminal 30X may associate a decryption key based on the link information with the PHR application decryption key with the user account ID and store them in the storage unit 38. Then, when the control unit 31 of the medical institution terminal 30X receives encrypted PHR data from the management server 10, it may execute a PHR data decryption process to acquire the PHR data. The EMR data update request information may include the decrypted PHR data.

[0360] <Effects of the Fifth Embodiment> 54, 55, 56, etc., in the fifth embodiment, PHR data encrypted with an encryption key corresponding to a PHR application is registered in the management server 10, and the encrypted PHR data is provided to a medical institution terminal 30 that has a decryption key corresponding to the encryption key. By encrypting the PHR data registered in the management server 10, security risks such as data leakage are reduced.

[0361] 54, 55, 56, etc., in the fifth embodiment, PHR data encrypted with an encryption key corresponding to a PHR application is registered in the management server 10, and the encrypted PHR data is provided to a medical institution terminal 30 that has a decryption key corresponding to the encryption key, and the decryption key is provided only to ID-federated medical institution terminals 30. Because the decryption key is provided only to ID-federated medical institution terminals 30, it is possible to prevent the PHR data from being provided to unintended medical institutions.

[0362] <Fifth Modification (1)> In the above embodiment, the decryption key is a private key in a common key cryptosystem, but the decryption key is not limited to this. For example, the decryption key may be a private key of the medical institution server 50 in a public key cryptosystem.

[0363] In this case, prior to processing, a private key and a public key are generated in subject terminal 20A and medical institution server 50 and stored in memory unit 28 and memory unit 55. Hereinafter, the private key and public key of subject terminal 20A will be referred to as "private key A" and "public key A," respectively, and the private key and public key of medical institution server 50 will be referred to as "private key H" and "public key H," respectively.

[0364] For example, the control unit 21 of the subject terminal 20A transmits link information with a PHR application decryption key, including a public key A based on a private key A, to the medical institution terminal 30X using code information, P2P communication, etc. Then, the control unit 31 of the medical institution terminal 30X transmits PHR application account link request information, including the public key A as a decryption key, to the management server 10.

[0365] Furthermore, the control unit 31 of the medical institution terminal 30X receives a public key H based on the private key H from the medical institution server 50, and transmits link information with a PHR application decryption key including the public key H to the subject terminal 20A by code information, P2P communication, etc. Then, the control unit 21 of the subject terminal 20A stores the received public key H in the storage unit 28, for example, in association with the medical institution account ID.

[0366] In the PHR data encryption process, for example, control unit 21 of subject terminal 20A encrypts the PHR data based on public key A to generate first encrypted PHR data. Also, for example, control unit 21 of subject terminal 20A encrypts the PHR data based on public key H to generate second encrypted PHR data. The first encrypted PHR data may be referred to as encrypted PHR data that can be decrypted by a user of the subject terminal 20A, and the second encrypted PHR data may be referred to as encrypted PHR data that can be decrypted by a user of the medical institution server 50. If there are multiple linking destinations for PHR data, the control unit 21 of the subject terminal 20A may further generate multiple encrypted PHR data based on the public keys H corresponding to the respective medical institution accounts, for example.

[0367] In the PHR data decryption process, for example, when the control unit 51 of the medical institution server 50 acquires the second encrypted PHR data, it decrypts the second encrypted PHR data based on the private key H to acquire the PHR data.

[0368] The private key and public key of the medical institution server 50 may be the private key and public key generated by the medical institution terminal 30. That is, key exchange with the subject terminal 20 may be performed for each medical institution terminal 30. Then, upon receiving the second encrypted PHR data from the management server 10, the control unit 31 of the medical institution terminal 30 may execute a PHR data decryption process to acquire the PHR data. The EMR data update request information may include the decrypted PHR data.

[0369] In addition, the control unit 21 of the subject terminal 20A may be configured to, for example, when a PHR application account linking process is executed in the management server 10 and PHR linking notification information is received, send PHR data reference request information requesting the first encrypted PHR data already recorded in the application linked to the management server 10. Then, the control unit 21 of the subject terminal 20A decrypts the first encrypted PHR data using the private key A, and when it obtains the PHR data, it may encrypt the PHR data using the public key H of the newly linked medical institution terminal 30 or medical institution server 50, and add it to and store it in the management server 10. [Explanation of symbols]

[0370] 1. Information Systems 10 Management Server 20 Subject terminal 30 Medical institution terminals 40 Network 50 Medical institution server 60 PHR application management server

Claims

1. A data sharing system for sharing data between a plurality of types of applications for acquiring data related to the health of a subject and a medical institution terminal for viewing the data, comprising: a storage unit that manages association between a first account ID for the subject to access the data sharing system and a second account ID for the user of the medical institution terminal to access the data sharing system, in association with at least one of the applications; a control unit that, in response to a request from the medical institution terminal, identifies the data acquired by the application associated with the first account ID linked with the second account ID corresponding to the medical institution terminal; A data sharing system comprising:

2. the control unit registers the data corresponding to each of the plurality of types of applications in the storage unit; The data sharing system according to claim 1 .

3. the control unit requests the subject's terminal to provide the data corresponding to each of the plurality of types of applications as the identification of the data; The data sharing system according to claim 1 .

4. the control unit requests the data corresponding to each of the plurality of types of applications from a corresponding application management server as the identification of the data; The data sharing system according to claim 1 .

5. the storage unit manages the account corresponding to the subject based on the first account ID common to the plurality of types of applications running on the terminal of the subject. The data sharing system according to claim 1 .

6. the storage unit manages a plurality of types of the applications in association with the association between the first account ID and the second account ID; The data sharing system according to claim 1 .

7. the storage unit manages the plurality of types of applications corresponding to the first account ID in association with the plurality of second account IDs; The data sharing system according to claim 1 .

8. the control unit further receives an ID federation request including the first account ID, the second account ID, and identification information of at least one of the applications; the storage unit manages, in response to the ID federation request, the federation between the first account ID and the second account ID in association with at least one of the applications; The data sharing system according to claim 1 .

9. the request from the medical institution terminal includes information capable of identifying the first account ID and the second account ID, the control unit identifies the data acquired by the application associated with the first account ID and the second account ID; The data sharing system according to claim 1 .

10. the request from the medical institution terminal includes specifying the target data by the subject's identification information; the control unit identifies the data corresponding to the request from the medical institution terminal based on the first account ID corresponding to the identification information, the second account ID corresponding to the medical institution terminal, and the application associated with the first account ID and the second account ID. The data sharing system according to claim 1 .

11. the request from the medical institution terminal includes information capable of identifying the first account ID and the second account ID, the control unit identifies the application associated with the first account ID and the second account ID, and identifies the data acquired by the identified application; The data sharing system according to claim 1 .

12. the control unit further receives an ID federation request including the first account ID, identification information of the application, and the second account ID, which is provided from a terminal on which the application is installed to the medical institution terminal; The storage unit manages the association between the first account ID and the second account ID in association with identification information of the application. The data sharing system according to claim 1 .

13. the control unit further receives an ID federation request including the first account ID, identification information of the application, and the second account ID, which is provided to the medical institution terminal from a terminal on which the application is installed with the consent of the subject or a person related to the subject; The storage unit manages the association between the first account ID and the second account ID in association with identification information of the application. The data sharing system according to claim 1 .

14. the control unit further receives an ID federation request including the second account ID provided from the medical institution terminal to a terminal on which the application is installed, the first account ID, and identification information of the application; The storage unit manages the association between the first account ID and the second account ID in association with identification information of the application. The data sharing system according to claim 1 .

15. the control unit further receives, in accordance with consent of the subject or a person related to the subject, an ID federation request including the second account ID provided from the medical institution terminal to a terminal on which the application is installed, the first account ID, and identification information of the application; The storage unit manages the association between the first account ID and the second account ID in association with identification information of the application. The data sharing system according to claim 1 .

16. the medical institution application for viewing the data on the medical institution terminal is common to a plurality of types of the applications; The data sharing system according to claim 1 .

17. The storage unit manages a third account ID, which is identification information of the subject in the electronic medical record system that provides electronic medical record information to the medical institution terminal, in association with the first account ID. The data sharing system according to claim 1 .

18. the storage unit manages, in an electronic medical record system that provides electronic medical record information to the medical institution terminal, a third account ID that is identification information of the subject in the electronic medical record system, in association with the first account ID; The control unit associates the data corresponding to the first account ID and / or information related to the data with the third account ID and registers the data in the electronic medical record system. The data sharing system according to claim 1 .

19. the storage unit manages, in an electronic medical record system that provides electronic medical record information to the medical institution terminal, a third account ID that is identification information of the subject in the electronic medical record system, in association with the first account ID; The control unit registers the data and / or information related to the data corresponding to the first account ID in the electronic medical record system in association with the third account ID, and provides the electronic medical record information and the data and / or information related to the data to the medical institution terminal in response to a request for provision of the electronic medical record information from the medical institution terminal using the third account ID. The data sharing system according to claim 1 .

20. the control unit, in response to the subject's terminal acquiring the second account ID from the medical institution terminal, creates the first account ID and requests the subject's terminal to install the application associated with the second account ID. The data sharing system according to claim 1 .

21. The storage unit manages the first account ID corresponding to the subject in association with a third account ID that is identification information of the subject in an electronic medical record system that provides electronic medical record information to the medical institution terminal, based on the consent of the subject or a person related to the subject in the terminal on which the application is installed.

21. The data sharing system according to claim 20.

22. The storage unit cancels the association between the first account ID and the second account ID corresponding to the subject in response to an operation on the subject's terminal. The data sharing system according to claim 1 .

23. The storage unit cancels the association between the first account ID and the second account ID corresponding to the subject according to a set condition. The data sharing system according to claim 1 .

24. The storage unit, in response to an operation by a user of the medical institution terminal, erases the data acquired by the application and managed in the electronic medical record system in association with a third account ID, which is identification information of the subject in the electronic medical record system that provides the medical institution terminal and electronic medical record information.

24. A data sharing system according to claim 22 or claim 23.

25. the data is encrypted with an encryption key corresponding to the application; the control unit provides the encrypted data to the medical institution terminal having a decryption key corresponding to the encryption key. The data sharing system according to claim 1 .

26. The decryption key is provided only to the medical institution terminal with which ID is linked.

26. The data sharing system of claim 25.

27. 1. A data sharing method for a data sharing system that shares data between a plurality of types of applications for acquiring data related to the health of a subject and a medical institution terminal for viewing the data, comprising: managing an association between a first account ID for the subject to access the data sharing system and a second account ID for the user of the medical institution terminal to access the data sharing system in association with at least one of the applications; In response to a request from the medical institution terminal, the data acquired by the application associated with the first account ID linked with the second account ID corresponding to the medical institution terminal is identified. How to share data.

Images