WO2018225428A1 - 診療記録管理システム、装置、方法およびプログラム - Google Patents

診療記録管理システム、装置、方法およびプログラム Download PDF

Info

Publication number
WO2018225428A1
WO2018225428A1 PCT/JP2018/017434 JP2018017434W WO2018225428A1 WO 2018225428 A1 WO2018225428 A1 WO 2018225428A1 JP 2018017434 W JP2018017434 W JP 2018017434W WO 2018225428 A1 WO2018225428 A1 WO 2018225428A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
medical
medical record
patient
image data
Prior art date
Application number
PCT/JP2018/017434
Other languages
English (en)
French (fr)
Inventor
佑紀 國府田
Original Assignee
Necソリューションイノベータ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Necソリューションイノベータ株式会社 filed Critical Necソリューションイノベータ株式会社
Priority to JP2019523401A priority Critical patent/JP6801922B2/ja
Publication of WO2018225428A1 publication Critical patent/WO2018225428A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data

Definitions

  • the present invention relates to a medical record management system, a medical record management device, a medical record management method, and a medical record management program for managing medical records.
  • Medical information such as the patient's physical condition, medical condition, treatment, etc., which the medical staff knows about the patient's medical care, is stored as medical records in medical institutions for a certain period.
  • the medical record is not limited to a medical record (medical record) in which a doctor records items related to a predetermined medical care, but is created, recorded or stored about the patient's physical condition, medical condition, treatment, etc. obtained in the course of medical treatment. This refers to the recording of documents, images, etc. Medical records were created in the medical care process and other processes such as prescriptions, surgical records, nursing records, laboratory findings records, X-ray photographs, referral letters, records of medical treatment during hospitalization for discharged patients, etc. Any medium on which information about the patient is recorded is included. When medical information is recorded on an electronic medium, a set of encoded data recorded as medical information on the electronic medium corresponds to the medical record.
  • doctors are obliged to store medical records for five years in the hospital or clinic manager according to the Doctor Law.
  • the hospital or clinic administrator is responsible for 2 years for records related to other medical practices (surgical records, test results, radiographs, etc.), and benefits other than medical records in insurance practice.
  • a medical institution must keep medical records and other medical records that are obligated to be retained at least for the period during which the obligation is imposed (hereinafter referred to as the retention period).
  • the Doctoral Law has a provision for preservation, but there is no provision for disposal. Therefore, the medical institution can keep the medical record exceeding the retention obligation period, but can also discard it.
  • the period (hereinafter referred to as the tracking period) for which the insurance company investigates the authenticity of the notification contents and claims from applicants and subscribers (hereinafter referred to as the tracking period) It may be a period that includes more than a year.
  • the insurance company investigates the visit history and medical history of applicants and subscribers who have been targeted in order to refer to the content of notifications and claims.
  • there are other industries such as insurance companies that require medical records from more than five years ago.
  • the tracking period at an insurance company is often from the start of the designated notification period specified at the time of enrollment to the expiration date for the cancellation of the insurance contract due to violation of the notification obligation.
  • the notice designation period is generally 5 to 7 years.
  • the deadline for cancellation due to violation of the notification obligation is 2 years or 5 years from the date of commencement of liability according to the insurance law, or indefinite (no expiration) if the content of the notification obligation violation is significant. Therefore, the start of the follow-up period is often 5 to 7 years before the subscription. Note that the start of the tracking period is a further past time point based on the inquiry time.
  • FIG. 15 is an explanatory diagram showing the relationship between the follow-up period by such an insurance company and the retention period for medical records at medical institutions. As shown in FIG. 15, when an insurance company makes an inquiry to a medical institution for investigation (at the time of inquiry in the figure), there is a case where a required medical record has already been discarded.
  • Japanese Patent Application Laid-Open No. 2004-133867 discloses an apparatus including a first storage unit that collectively stores copies of electronic medical records of a plurality of medical institutions, a second storage unit that stores information for provision, and a processing unit.
  • a method for providing an electronic medical record is described.
  • the processing means obtains the electronic medical record of the referred patient from the first storage means in response to a request from the referral source medical institution, and adds the referral destination medical institution information to the second storage means.
  • the processing means searches the second storage device in response to an inquiry request from the referral medical institution, and transmits corresponding medical information.
  • Patent Document 2 describes a medical information distribution method that is considered to have versatility and maintainability.
  • the medical information distribution server captures medical information data in a format other than the general-purpose image format created by the electronic medical record system and stores it in the storage. Then, in response to a distribution request from the reference terminal, the medical information distribution server converts the medical information data stored in the storage into image data and attaches modification prevention information to the image data to prevent modification. And deliver.
  • the medical record there is a period in which a period in which demand is present and a period in which it can be reliably provided do not overlap, that is, a period in which there is a possibility that it cannot be provided even if demand exists. For this reason, for example, even if an insurance company obtains consent to disclose information about medical records from a survey subject, there is a problem that necessary medical records do not remain. In addition, for example, even if the necessary medical records remain knowingly, if the medical records are related to a medical history that has not been announced by the survey subject, it is difficult for the insurance company to reach the medical records. There is.
  • Patent Document 1 discloses the concept of a backup center that collectively manages copies of electronic medical records stored in a plurality of medical institutions, and uses such a backup center to It describes how to transfer medical records from a medical institution to a referral medical institution.
  • this method has a problem that only an electronic medical record stored in a medical institution is a target, and medical records of a medical institution in which the electronic medical record is not introduced cannot be obtained.
  • the method attaches the referral destination medical institution information to the electronic medical record of the referral patient and stores it in the second storage means.
  • provided information is not created unless the referral institution knows the referral institution, and therefore cannot be used for a survey to know whether or not there is a medical record of a specific individual such as an insurance company.
  • the above mechanism including users other than medical institutions is considered to be effective, but in order to realize such a mechanism, medical records in storage and other individuals It is important to achieve both confidentiality of information and accessibility that allows an organization other than a medical institution to freely refer to a desired medical record based on the authority given to the institution. Furthermore, it is preferable that the confidentiality of the personal information, the accessibility of the data being stored, and the integrity (prevention of falsification) of the data are compatible.
  • accessibility for example, assuming that an insurance company refers to the medical record, a plurality of institutions can be within the scope of their authority without knowing the fact of the medical examination and the medical institution of the medical examination destination. It is possible to reach a desired medical record from the stored.
  • the accessibility may include, for example, that the registering medical institution can easily register regardless of the recording format of the medical record.
  • Patent Document 2 describes an example of a method for delivering medical information while achieving both versatility and maintainability of data.
  • this method adds access information and alteration prevention information to medical information data in a format other than the general-purpose image format in response to a distribution request from the reference terminal, the maintenance of the medical information data stored in the storage is not sufficient.
  • the method described in Patent Document 2 does not consider at all the compatibility between the confidentiality of personal information as described above and the accessibility of data, and the compatibility between these and data integrity.
  • an object of the present invention is to store medical records of a plurality of medical institutions and to an organization other than the medical institutions while at least achieving confidentiality of personal information, data accessibility, and data integrity. It is to realize the service provided. More specifically, the object of the present invention is to store the medical records of a plurality of medical institutions including medical records that are not obligated to be stored for a relatively long period of time, and the authority given to a plurality of institutions including different industries.
  • the present invention provides a medical record management system, a medical record management device, a medical record management method, and a medical record management program that can refer to a desired medical record based on the above.
  • the medical record management system stores at least first storage means for storing medical record image data provided from a medical institution, and information for associating a medical record target patient with medical record image data.
  • the first storage means corresponds to the record identification information for identifying the medical record and the image data.
  • Medical record including record identification information and summary of image data in a predetermined block chain in which a new block is added through a process according to a predetermined consensus algorithm in which two or more nodes participate.
  • a block is added, and patient identification information for identifying a patient is associated with block identification information that is information that can identify a medical record block in the second storage unit.
  • a patient designated from the medical record image data stored in the first storage means in response to a request from a user including a registration means to be stored and a third party other than a medical institution. And providing means for searching and providing image data of medical records.
  • the medical record management system is constructed in a secure environment, and is constructed in a secure environment and first storage means for storing at least image data of the medical record provided from a medical institution. From the medical institution, a second storage means for storing information associating the target patient with the image data of the medical record, a third storage means possessed by a node operated by a third party other than the medical institution, and Each time image data of a medical record of a patient of the medical institution is provided, the first storage means stores record identification information for identifying the medical record and image data in association with each other, and third storage
  • the medical record block including the record identification information and the summary of the image data is stored in the means, and the patient identification information for identifying the patient and the medical record block can be specified in the second storage means Image data of medical records stored in the first storage unit in response to a request from a user including a registration unit that stores the lock specific information in association with each other and a third party organization that is an organization other than the medical institution Providing means for retrieving and providing image data
  • the medical record management apparatus includes a record identification information for identifying a medical record and an image stored in a predetermined first storage unit each time image data of a medical record of a patient of the medical institution is provided from the medical institution. Record identification information and a summary of image data in a predetermined block chain in which new blocks are added through a process in accordance with a predetermined consensus algorithm in which two or more nodes participate and store data in association with each other.
  • Registering means for adding a medical record block including the information and storing the patient identification information for identifying the patient in association with the block specifying information, which is information capable of specifying the medical record block, in the predetermined second storage means And designated from the medical record image data stored in the first storage means in response to a request from a user including a third party that is an organization other than a medical institution.
  • a providing means for providing was searching for image data of the medical records of the patient, characterized in that a providing means for providing.
  • the identification information and the image data are stored in association with each other, and the record identification information is added to a predetermined block chain in which a new block is added through processing according to a predetermined consensus algorithm in which two or more nodes participate.
  • a medical record block including a summary of image data is added, and patient identification information for identifying a patient is associated with block specifying information, which is information that can identify the medical record block, in a predetermined second storage unit
  • block specifying information which is information that can identify the medical record block
  • an indication is made from the medical record image data stored in the first storage means. And providing searching the image data of the medical records of patients.
  • the medical record management program provides a record identification information for identifying a medical record in a predetermined first storage means each time image data of a medical record of a patient of the medical institution is provided from a medical institution to a computer. Record identification information and image data in a predetermined block chain in which a new block is added through a process according to a predetermined consensus algorithm in which two or more nodes participate.
  • the patient identification information for identifying the patient and the block specifying information which is information that can identify the medical record block, are stored in the predetermined second storage means in association with each other.
  • a medical record image stored in the first storage unit in response to a request from a user including a third party that is an organization other than the medical institution The image data of the medical records of the specified patient from the data search and is characterized in that to execute a process of providing.
  • FIG. 3 is a block diagram illustrating a configuration example of a management node 21.
  • FIG. It is explanatory drawing which shows the outline of the flow of the data of embodiment of this invention. It is explanatory drawing which shows the example of the data structure of the information memorize
  • 4 is an explanatory diagram illustrating an example of a flow of each stage of the medical record management system 10.
  • FIG. 4 is a sequence diagram illustrating an example of an operation of a medical record management system 10.
  • FIG. 4 is a sequence diagram illustrating an example of an operation of a medical record management system 10.
  • FIG. 4 is a sequence diagram illustrating an example of an operation of a medical record management system 10.
  • FIG. 4 is a sequence diagram illustrating an example of an operation of a medical record management system 10.
  • FIG. 4 is a sequence diagram illustrating an example of an operation of a medical record management system 10.
  • FIG. It is explanatory drawing which shows the example of an authority check. It is a block diagram which shows the other example of the medical record management apparatus 1.
  • FIG. It is a block diagram which shows the other example of the medical record management apparatus 1.
  • FIG. It is a schematic block diagram which shows the structural example of the computer concerning embodiment of this invention. It is a block diagram which shows the outline
  • the medical record management system stores medical records from medical institutions and has been requested by medical institutions that have stored medical records and other institutions that are members of the medical record providing service provided by the system.
  • the medical records kept are provided based on the authority given to those institutions.
  • an organization other than a medical institution such as an insurance company or a research company and an organization that desires a medical record of a specific individual (hereinafter referred to as a third-party institution) is assumed as one of the organizations using the system.
  • the medical institution providing medical records by adding such a third-party organization to the user and having the system configuration that allows the third-party organization to distribute and bear the resources or expenses for system operation.
  • This system can be used with a relatively low burden even in a small clinic.
  • the usage fee for the medical record reference service provided by this system is free, while for third parties, the annual membership fee as the usage fee It is good also as service access conditions.
  • the usage fee may be set to a pay-per-use system.
  • the usage fee may be determined according to the usage amount of the system, such as the amount of information provided by the system in the reference service, the number of times of provision, the number of inquiries, and the like.
  • a device operated by a third party organization for some information on medical records that may be made public It may be stored in the (node) or held by the third party organization.
  • the third-party institutions can be connected to medical institutions, and the utility value of medical records To increase.
  • small clinics often provide primary medical care as family doctors and are likely to have medical records that cover the patient's medical history in the field in charge.
  • the utility value of medical records at other institutions can be further increased. It is also possible to include the patient himself / herself as the service provider.
  • the present invention since it is assumed to be used by different organizations such as a plurality of medical institutions and a plurality of third-party institutions, it is possible to perform distributed management by a plurality of nodes, high maintainability, and easy connection between data.
  • the attribute information of the medical record is managed using the block chain having.
  • the medical record itself is managed by storing it in a predetermined storage device constructed in a secure environment because it has high confidentiality.
  • all medical records are handled as image data so that a medical institution that has not yet introduced an electronic medical record can be used, and a specific format is not required.
  • medical records on paper media and other forms of electronic medical records are registered after being imaged by reading them with a scanner or converting the format to a print data format. This makes it possible to use this system even in a relatively small clinic where no electronic medical record is introduced.
  • the block chain is a time series of data groups having a predetermined data structure called a block, and has a role as a record ledger that keeps information recorded in each block.
  • each block contains information about one or more previous blocks (hereinafter referred to as the previous block), and information for detecting the presence or absence of tampering (verification information called nonce, signature, etc. ).
  • consensus processing a predetermined consensus algorithm in which two or more management nodes participate.
  • Each of the management nodes holds a copy of the block chain through execution of the consensus process.
  • PoW Proof Work
  • the hash value of the block is equal to or less than the threshold (target value).
  • Rules are determined in advance, and when adding a block, a plurality of management nodes search for a nonce that satisfies such rules simultaneously in parallel. By performing such a consensus process, a plurality of management nodes can hold a copy of information while ensuring tampering difficulty.
  • the consensus algorithm in the blockchain management system is not limited to PoW.
  • a consensus algorithm such as BFT (Byzantine fault tolerance) can also be used.
  • the blockchain has a feature that the replica is held in a plurality of nodes in exchange for the above feature, the confidentiality of the data is low. For this reason, as described above, highly confidential information is stored in another peripheral system constructed in a secure environment. After that, the peripheral system and the block chain are linked.
  • the system classifies the information into public information and non-public information.
  • a block including public information and a summary of non-public information may be added to the block chain while being stored in the peripheral system.
  • the medical record image data is classified as non-public information.
  • information identifying private information or information identifying a patient may be included in a block added to the block chain.
  • the peripheral system is, for example, a system that can cooperate with a block chain in which public information is registered, and a system with a closed internal specification is preferable.
  • “cooperation” includes at least addition of a block to the block chain and data reference in the block chain.
  • an authority check is performed on the access from the user, and only the reference of the information within the permitted range for each user is permitted. In this way, confidentiality of non-public information is ensured.
  • a third party that has joined the service may freely refer to the block chain held by any of the management nodes.
  • the block chain it is easy to adapt to a dynamic environment such as addition or deletion of a node that holds a copy.
  • the above node is mounted on a server provided by a third party organization. If such operations are performed, not only can the resources involved in the operation be distributed and borne by third-party organizations, but also dynamically when new third-party organizations join.
  • FIG. 1 is a block diagram showing an example of a medical record management system of this embodiment.
  • the medical record management system 10 includes a medical record management device 1, a block chain management system 2, a registration information DB (database) 3, and a medical record DB 4. Each of these is connected via the network 5.
  • the block chain management system 2 is a system in which a plurality of nodes share and manage a block chain as described above.
  • the block chain management system 2 is exemplified as a block chain management system.
  • the block chain management system 2 can execute a predetermined consensus process and share a block chain that is difficult to tamper with as a recording ledger among terminals in the system.
  • the detailed configuration and specifications are not particularly limited.
  • the management node 21 is a node that executes consensus processing in the blockchain management system 2. Each of the management nodes 21 holds a copy of the block chain 22 through execution of the consensus process.
  • a recording block including at least a part of attribute information of the medical record and a summary of the medical record image data is registered in the block chain 22 of this embodiment ( Added). Details of the process of adding a recording block to the block chain 22 will be described later.
  • the registration information DB 3 stores patient management information for associating a patient who has consented to the provision of medical records to the system with a block including the patient information registered in the block chain 22. For example, the registration information DB 3 searches and verifies a block in which the patient's public information and medical record image data and other non-public information summaries are recorded in association with the patient's key information in the medical record management apparatus 1. Block management information is stored.
  • the medical record management apparatus 1 in order for the medical record management apparatus 1 to easily search for a patient to be managed in the registration information DB 3, search information such as medical institution information or a patient identifier in a provider medical institution May be stored.
  • the patient key information may be information specifying a patient (individual) included in the above-described patient information, a Hash value generated from such information, or the like. There may be a plurality of patient key information.
  • the hash value of a block is used as block management information.
  • the registration information DB 3 may store block management information of all blocks in which the storage target information of the patient is recorded in association with the patient key information.
  • the registration information DB 3 may store block management information of at least two blocks, a consent information block and a medical record recording block, which will be described later.
  • the registration information DB 3 may store block management information of two or more medical record blocks when image data of medical records is registered from a plurality of medical institutions for the same patient.
  • the registration information DB 3 may further store private information regarding the patient in association with the patient's key information.
  • the medical record DB 4 stores at least image data of a medical record provided from a medical institution.
  • the medical record DB 4 may store, for example, predetermined non-public information among storage target information including attribute information of a patient's medical record provided from a medical institution. Note that the medical record image data belongs to non-public information.
  • the attribute information of the medical record that is the storage target information includes, for example, patient information that is information about the patient that is the target of the medical record, medical institution information that is information about the medical institution that created the information, creation date and time, and information about the medical condition Etc.
  • the storage target information may include information other than the medical record image data and attribute information thereof, for example, image data of a consent form regarding provision of the medical record.
  • the medical record DB 4 may store non-public information excluding information specifying a patient (individual) from non-public information. In that case, for example, instead of information specifying a patient (individual), the medical storage DB 3 may store information that can determine the identity of information at the time of collation, such as a hash value of the information.
  • Private information other than the medical record image data may be stored in a registration information DB 3 described later. That is, the non-public information may be stored in any storage device of the peripheral system together with information that can identify the patient or information corresponding to the information.
  • Examples of public information include medical institution information and information (gender, date of birth, diagnosis name, diagnosis start date, diagnosis end date, system use license date, license object) that does not specify an individual among patient information. Can be mentioned.
  • examples of non-public information include medical record image data, consent form image data regarding provision of medical records, and information that identifies an individual (individual) by an organization other than the original medical institution among patient information (name) And date of birth, insurance card number).
  • the target patient may be able to set whether the information is public information or non-public information for each item included in the storage target information.
  • the medical record DB 4 includes, for example, a management number assigned every time medical record image data is registered (hereinafter referred to as a record management number), the medical record image data, and other non-public information if present. Store it in association.
  • the record management number may be an identifier indicating a unique value for an arbitrary unit in which medical record image data is registered in the system.
  • the record management number is preferably a value that is randomly assigned to a certain unit, for example.
  • Hash of information obtained by combining information for identifying a medical institution, information for identifying a patient at the medical institution, and the date and time when target information (image data of medical records) is received A value may be used.
  • the record management number may be recorded in a block together with a summary of image data corresponding to the record management number, for example.
  • the “summary” is information based on the original information (in this example, non-public information), and is not particularly limited as long as the information can be detected when the information is falsified.
  • the summary may be information obtained by a one-way function such as a Hash value of the original information (in this case, image data).
  • the medical record DB 4 may encrypt and store image data and other non-public information of the medical record in order to further improve the confidentiality of the medical record.
  • the medical record management apparatus 1 provides the user with an interface for registering, searching and referring to the storage target information, and executes various controls for registering, searching and referring to the storage target information according to a request from the user.
  • the medical record management apparatus 1 may include a patient registration unit 101, a medical record registration unit 102, a registration information inquiry unit 103, and a medical record provision unit 104.
  • the patient registration unit 101 performs a specified patient registration process in response to a request from a medical institution.
  • the patient registration unit 101 receives at least the requesting medical institution information (medical institution information) and the registration target patient information as the storage target information for the registration, and the received information Are registered in the block chain 22 and the medical record DB 4 as appropriate, and the key information of the patient generated based on the patient information and the block management information are associated with each other and stored in the registration information DB 3.
  • the information registration to the block chain may be performed by passing the information to be registered in the block chain 22 to any management node 21 provided in the block chain management system 2 and requesting the creation of the block.
  • the patient registration unit 101 assigns a record management number to the received non-public information and stores it in the medical record DB 4 and then stores the record.
  • the management node 21 may be requested to create a consent information block including a management number, public information, and a summary of non-public information. If the received information does not include non-public information, the patient registration unit 101 may request the management node 21 to create a consent information block including public information.
  • the patient registration unit 101 may return, for example, to the requesting user (a medical institution terminal or the like) that registration has been completed. At this time, the patient registration unit 101 may return the patient key information together.
  • the medical record registration unit 102 performs image data registration processing for a designated patient in response to a request from a medical institution.
  • the medical record registration unit 102 receives, for example, at least requesting medical institution information, patient information, and medical record image data as the storage target information for the registration, and the received information Is registered in the block chain 22 and the medical record DB 4 as appropriate, and the patient management information stored in the registration information DB 3 is added to the current block chain 22 based on the key information of the patient generated based on the patient information. Add the block management information of the block registered in.
  • the medical record registration unit 102 allocates a record management number to the received medical record image data and other non-public information and stores it in the medical record DB 4, and also stores the record management number, the public information, and the non-public information.
  • the management node 21 may be requested to create a medical record block including a summary of public information. If the received information does not include public information, the medical record registration unit 102 may request the management node 21 to create a medical record block including a record management number and a summary of non-public information. Good.
  • the medical record registration unit 102 may return, for example, that the registration is completed to a request source (a medical institution terminal or the like). At this time, the medical record registration unit 102 may return the record management number together.
  • the registration information inquiry unit 103 inquires registration information regarding a designated patient or contractor (individual) in response to a request from a medical institution or a third party institution. In this inquiry process, the registration information inquiry unit 103 provides information such as whether or not storage target information relating to the designated patient or contractor is registered and a list of storage target information based on the access authority of the request source.
  • the medical record providing unit 104 provides storage target information (particularly, medical record image data) regarding a designated patient or contractor (individual) in response to a request from a medical institution or a third party. In this providing process, the medical record providing unit 104 provides storage target information related to the designated patient or contractor based on the access authority of the request source.
  • FIG. 2 is a block diagram showing a configuration example of the management node 21.
  • the management node 21 illustrated in FIG. 2 includes a data reception unit 211, a block generation unit 212, a block sharing unit 213, an information storage unit 214, a block verification unit 215, and a data output unit 216.
  • the data reception unit 211 receives information to be added to the block chain 22 from an external node.
  • the data reception unit 211 receives a record management number, public information, or non-public information summary as information to be added to the block chain 22.
  • the block generation unit 212 generates a block to be added to the block chain using the information received by the data reception unit 211.
  • the block generation unit 212 generates a block including information based on the previous block and the information received by the data reception unit 211.
  • the block generation unit 212 performs, for example, a process of searching for a nonce as a predetermined consensus process for a block generated by itself or a block generated by another management node 21 via a block sharing unit 213 described later. After performing a process of assigning a signature, a block is added to a block chain managed by itself (corresponding to a copy of the block chain 22). A block obtained by performing a predetermined consensus process by the plurality of management nodes 21 on the block generated by the block generation unit 212 is finally added to the block chain 22.
  • the block sharing unit 213 exchanges information between the management nodes 21 belonging to the block chain management system 2. More specifically, the block sharing unit 213 appropriately stores information received by the data receiving unit 211, blocks generated by the block generating unit 212, blocks received from other management nodes 21, and the like as appropriate. Send to. As a result, all the management nodes 21 share this information and the latest block chain 22 as much as possible.
  • the information storage unit 214 stores a copy of the block chain 22.
  • the information storage unit 214 may store, for example, information necessary for verification processing in the block verification unit 215 described later.
  • the block verification unit 215 performs verification in the block when adding the block to the block chain held by the block verification unit 215. For example, the block verification unit 215 generates information based on the previous block included in the added block from the actual previous block, whether the added block actually satisfies the rule, the signature of the node that created the block matches It may be verified whether or not the information matches.
  • the data output unit 216 searches for and outputs a block including desired information from the block chain 22 held by itself in response to a request from an external node.
  • the configuration in FIG. 2 is merely an example, and the management node 21 can execute a predetermined consensus process for sharing and managing the block chain 22 that is difficult to tamper with. As long as the node can add information to the ledger and refer to the ledger in response to the request, the specific configuration is not limited.
  • the medical record management apparatus 1 and the management node 21 are shown as separate ones, but the medical record management apparatus 1 may have the function of the management node 21.
  • FIG. 3 is an explanatory diagram showing an outline of the data flow according to the embodiment of the present invention.
  • the consent information includes image data of a consent form, patient information, medical institution information, and the like, but the consent information is not limited to these.
  • the medical institution or the like first registers the consent information including the patient information and the medical period information obtained from the system registration consent in this system.
  • the system associates the non-public information of the consent information with the key information of the patient and stores it in the registration information DB 3, and also stores the public information of the consent information and the hash value of the non-public information (Hash X in the figure). ) And an approval information block (block i in the figure) are created and added to the block chain 22. Further, the system stores the hash value (Hash i in the figure) of the added consent information block in the registration information DB 3 as block management information in association with the key information of the patient.
  • the medical institution registers the image data of the patient's medical record for which the storage obligation has ceased in this system.
  • the system stores the medical record image data and the record management number in association with each other in the medical record DB 4 and also includes the record management number and the hash value of the medical record image data (Hash Y in the figure).
  • a block (block n in the figure) is created and added to the block chain 22.
  • the system stores the hash value (Hash n in the figure) of the added medical record block in the registration information DB 3 in association with the patient key information as block management information. At this time, if there is already stored block management information, new block management information may be added to hold two or more block management information. In addition, when overwriting already stored block management information, the system includes already stored block management information (block management information before overwriting) in the medical record block.
  • the system may include the public information in the medical record block and register it in the block chain 22.
  • the system stores the private information in the medical record DB 4 in the same manner as the medical record image data.
  • the hash value may be included in the medical record block and registered in the block chain 22.
  • the medical record image data provided by the medical institution may include medical record image data during the storage obligation period. That is, the medical record image data to be stored by the present system is not limited to the data that is no longer required to be stored.
  • each block is connected in time series and holds a value based on the previous block.
  • the block n holds the block Hash n ⁇ 1 that is the Hash value of the block n ⁇ 1.
  • the block n + 1 holds a block Hash n that is the Hash value of the block n. Therefore, in order to tamper with the contents of the block, it is necessary to recreate all subsequent blocks, and due to the nature of the block chain, it is difficult to tamper with the data in the block chain.
  • FIG. 4 is an explanatory diagram showing an example of the data structure of information stored in the block chain 22, the registration information DB 3 and the medical record DB 4.
  • the block used by the medical record management system 10 may include, for example, a header part D21 and a data part D22.
  • the header part D21 includes previous block management information D211.
  • the data part D22 may include a management number D221, public information D222, and private information management information D223.
  • the previous block management information D211 is information based on the previous block and may be information that can be detected when the data of the previous block is falsified. Examples of the previous block management information D211 include the hash value of the previous block.
  • Management number D221 is information for identifying data stored in the block. Examples of the management number D221 include a record management number for the medical record block, and key information or second key information generated from the key information for the consent information block. The management number D221 of the consent information block may be omitted.
  • the public information D222 is public information among the storage target information provided from the medical institution. Note that the public information D222 may be omitted if the public information is not included in the storage target information in the provision of the storage target information for generating the block.
  • the non-public information management information D223 is information based on non-public information in the storage target information provided from the medical institution, and can be detected if the non-public information is falsified. Good.
  • a Hash value or the like of the target non-public information can be cited. Note that the non-public information management information D223 may be omitted when providing the storage target information for which the block is generated and the non-public information is not included in the storage target information.
  • the data part D22 may further include block management information of a block in which information related to the patient is registered in the block chain 22 before the block.
  • the registration information DB 3 includes, for example, key information D31, non-public information D32, block management information D33, as patient management information for each patient for whom medical records are provided from a medical institution. May be stored.
  • the key information D31 is the above-described patient key information.
  • the non-public information D32 is non-public information of the patient other than the image data of the medical record.
  • the non-public information D32 may be omitted.
  • the medical record image data is stored in the medical record DB 4 as described later.
  • Block management information D33 is block management information of a block including a summary of patient public information and / or non-public information.
  • the medical record DB 4 stores, for example, record management number D41 and medical record image data D42 as medical record information every time medical record image data is provided from a medical institution. May be.
  • the record management number D41 is the above-described record management number.
  • the medical record image data D42 is image data of the provided medical record.
  • the medical record DB 4 may further store the patient's non-public information as the medical record information together with the medical record image data D42 or instead of the medical record image data D42. .
  • FIG. 5A is a flow example of a phase for registering a patient in the medical record management system 10.
  • the medical institution registers the consent information including the patient information of the patient who has accepted the system registration of the medical record, the medical institution information, and the image data of the consent form in the medical record management system 10. .
  • the consent information block including the public information of the consent information and the summary of the non-public information is registered in the block chain 22, and the patient key information generated from the patient information and the consent information And the hash value (block management information) of the consent information block are associated with each other and stored in the registration information DB 3.
  • FIG. 5B is a flow example of a phase for registering image data of a medical record of a patient who has obtained consent from the medical record management system 10.
  • the medical institution registers the image data of the medical record of the patient who has accepted the system registration of the medical record in the medical record management system 10.
  • the medical institution inputs information specifying the patient and its own medical institution information together with the image data of the medical record to the medical record management system 10 and inquires for information registered regarding the patient, Register the recorded image data.
  • the image data of the medical record of the patient who obtained the consent is registered in the medical record DB 4 together with the record management number assigned to the image data.
  • a medical record block including the summary of the image data and a record management number is registered in the block chain 22, and the key information of the patient is associated with the hash value (block management information) of the medical record block. And stored (added) in the registration information DB 3.
  • FIG. 5C is a flow example of a registration information inquiry phase for inquiring information registered in the medical record management system 10.
  • a third-party organization such as an insurance company that obtains consent from a medical institution or contractor or the like stores information registered on the permitted patient or contractor in the medical record management system 10.
  • the medical institution or the third-party institution designates information that can identify the patient (individual) and makes an inquiry request to the medical record management system 10.
  • the medical record management system 10 identifies the patient based on the specified information and inquires with the patient management information in the registration information DB 3, and then includes information included in the patient management information and information that can be acquired based on the information Within the scope allowed for the requesting institution.
  • the medical institution or the third party institution can know whether or not the designated person's medical record is registered in the system within a range permitted by the medical institution or the third party institution.
  • Examples of information that can identify a patient (individual) include a group of the patient's date of birth and name, a set of identification information of the medical institution and identification information of the patient at the medical institution, and a patient assigned by the medical record management system 10 Key information, information (insurance card number) that can identify an individual assigned by another system (administration, etc.), and the like.
  • FIG. 5D is a flow example of a phase for referring to the medical record registered in the medical record management system 10.
  • a third-party organization such as an insurance company that has obtained consent from a medical institution or a contractor or the like is selected from the medical record image data registered in the medical record management system 10.
  • the medical institution or the third-party institution designates information that can identify the patient (individual) and information that can identify the medical record to be referred to, and requests the medical record management system 10 to refer to it.
  • the medical record management system 10 identifies the patient and the medical record based on the designated information, and provides the information within the permitted range to the requesting institution.
  • the medical institution or third-party institution can refer to the image data of the medical record of the designated individual within the range permitted by the medical institution or third party institution.
  • the information that can identify the medical record there is a record management number obtained in the registration information inquiry phase.
  • narrowing conditions such as a medical date and time and a period.
  • FIGS. 6 to 9 are sequence diagrams showing an example of the operation of the medical record management system 10.
  • the patient registration function, the medical record registration function, the inquiry function, and the provision function are the patient registration unit 101, the medical record registration unit 102, the registration information inquiry unit 103, and the medical record provision unit 104 of the medical record management device 1, respectively.
  • the user in a figure represents the user terminal which each user operates.
  • a patient registration operation in the medical record management system 10 will be described with reference to FIG.
  • the user in this operation is assumed to be a medical institution that creates a medical record of a patient to be registered, that is, a medical record of the patient.
  • a consent registration request including patient information and medical institution information as consent information is transmitted to the patient registration unit 101 of the medical record management apparatus 1 (step S101).
  • the user first transmits a consent registration record request for requesting patient registration to the medical record management apparatus 1 via a Web page provided by the medical record management apparatus 1, and follows the information input request received as the reply.
  • Patient information, medical institution information, and image data of consent form, consent contents, and the like may be input if present.
  • the patient registration unit 101 that has received the consent information generates key information of the patient based on the received information (step S102). Further, the patient registration unit 101 calculates the Hash value of the non-public information that is to be stored included in the received information (step S103). And the patient registration part 101 produces the content (data part D22 of an acceptance information block) registered into the block chain 22 (step S104). In step S104, the patient registration unit 101 creates a data part D22 including at least the management number D221, the public information D222, or the private information management information D223. Then, a block addition request including the created data part D22 is transmitted to any management node 21 of the block chain management system 2 (step S105).
  • the management node 21 receiving the block addition request generates a block including at least the received data part D22 and the header part D21 created based on the information of the block chain 22 managed by the management node 21 (step S106). . Then, each of the management nodes 21 of the block chain management system 2 executes a predetermined consensus process, and adds the generated block to the ledger (step S107). In addition, the management node 21 that has received the block addition request receives the fact that the block in which the requested data part D22 is recorded has been successfully added, and obtains the block Hash that is the hash value of the added block as the request source. To the patient registration unit 101 (step S108).
  • the patient registration unit 101 Upon receiving the block hash, the patient registration unit 101 uses the block hash as block management information, and associates the patient key information generated in step S102 with the block management information and the non-public information included in the consent information. Is recorded in the registration information DB 3 (step S109). Note that if the non-public information to be held is not included in the consent information, the above-mentioned non-public information is omitted.
  • the patient registration unit 101 registers a DB registration request including patient key information, a block hash as block management information, and, if there is non-public information to be held in the consent information, the non-public information. It transmits to information DB3.
  • the registration information DB 3 creates and stores a new record in which information included in the received DB registration request is recorded (step S110).
  • the patient registration unit 101 When the patient registration unit 101 receives the registration completion from the registration information DB 3 (step S111), the patient registration unit 101 notifies the requesting user of the completion of registration and ends the process (step S112).
  • the user in this operation is assumed to be a medical institution that creates a medical record of a patient to be referred to, a medical institution other than the medical record creation source, or a third party.
  • the user transmits a registration information inquiry request including institution information indicating its own institution as user information and information for specifying a patient to the registration information inquiry unit 103 of the medical record management apparatus 1.
  • Step S201 the user transmits a registration information inquiry request for requesting a patient inquiry to the medical record management apparatus 1 via a Web page or the like provided by the medical record management apparatus 1, and the user according to the information input request received as the reply.
  • Information (institution information) and information for identifying a patient may be input.
  • Examples of information for identifying a patient include information included in consent information such as a patient's name, date of birth, and patient identifier at a medical institution, and key information generated from the information.
  • consent information such as a patient's name, date of birth, and patient identifier at a medical institution
  • key information generated from the information For example, when a medical institution that is a user specifies his / her patient, a set of medical institution information and patient identification information in the medical institution may be input as information for specifying the patient.
  • a medical institution that is a user specifies a patient of a medical institution other than herself, as information for specifying the patient, a set of medical institution information of the patient and a patient identification information in the medical institution, Information (a combination of name and date of birth, insurance card number, etc.) that can identify a patient as an individual may be input.
  • a third-party organization that is a user specifies a patient (contractor), information that can specify the patient as an individual (name and date of birth, insurance card
  • the registration information inquiry unit 103 that has received the user information and the information specifying the patient performs an authority check to determine whether or not the user can access the registration information of the patient based on the received information (step S202). . Details of the authority check will be described later.
  • the registration information inquiry unit 103 replies to the request source user and ends the processing (step S203).
  • the registration information inquiry unit 103 acquires the key information of the patient, and based on the acquired patient key information, The registered information DB 3 is referred (searched) (steps S204 to S207). More specifically, the registration information inquiry unit 103 acquires the patient key information based on the received information, and then transmits a DB search request including the patient key information to the registration information DB 3 (step S204, step S204). S205). The registration information DB 3 searches the data recorded on the recording medium based on the information included in the DB search request (step S206).
  • patient management information including the specified key information is registered in the registration information DB 3, and the record is returned from the registration information DB 3 to the registration information inquiry unit 103 (step S207). If the record corresponding to the registration information DB 3 is not registered, the registration information inquiry unit 103 replies to that effect to the requesting user (step S208).
  • the registration information inquiry unit 103 When the registration information inquiry unit 103 receives the corresponding record from the registration information DB 3, the registration information inquiry unit 103 acquires the block management information included in the record (step S209). And the registration information inquiry part 103 searches the consent information block and medical record block of the said patient based on the acquired block management information. More specifically, the registration information inquiry unit 103 transmits a block data request including the block management information acquired in step S209 to any management node 21 of the block chain management system 2 (step S210).
  • the management node 21 that has received the block data request searches for the corresponding block from the block chain 22 managed by itself, and returns the data portion of the block (steps S211 and S212).
  • the registration information inquiry part 103 Upon receiving the data part of the corresponding block, the registration information inquiry part 103 performs a user access authority check on the data recorded in the received data part (step S213), and obtains it within the range permitted by the requesting user. The provided information is provided (step S214).
  • the registration information inquiry unit 103 is configured such that when there are a plurality of patient management information records, such as when the designated patient has visited a plurality of medical institutions, or the block management information of a plurality of blocks is included in one record. If registered, information may be provided after performing the operations of steps S209 to S213 for the number of block management information.
  • Examples of information provided in step S214 include the presence / absence of system registration, and a list of management numbers D221 and public information D222 included in the data part of the medical record block if they exist. Further, depending on the user, patient information used to generate the non-public information D32, the key information D31, and the key information D31 stored in the registration information DB 3 may be used.
  • the user in the operation is assumed to be a medical institution that creates a medical record to be registered.
  • the user first transmits a registration information inquiry request including institution information indicating his / her institution as user information and information for specifying a patient to the registration information inquiry unit 103 of the medical record management apparatus 1. (Step S301).
  • the registration information inquiry unit 103 that has received the user information and the information for specifying the patient performs registration information inquiry processing (step S302).
  • the registration information inquiry process may be the same as the operation in steps S202 to S213 shown in FIG.
  • the registration information inquiry unit 103 generates or acquires key information of the designated patient based on the received information, and the designated patient is registered in the registration information DB 3. Patient management information and the data part of the consent information block registered in the block chain 22 are acquired.
  • the registration information inquiry unit 103 designates user information as medical institution information instead of the patient key information and makes a DB search request to the registration information DB 3 to obtain medical institution information. What is necessary is just to acquire the record which matches. Then, the data part of the consent information block may be acquired for each acquired record based on the block management information included in the record.
  • the registration information inquiry unit 103 provides the acquired information within a range permitted by the requesting user (step S303).
  • a legitimate user a medical institution to receive medical care
  • the registration status of the designated patient's medical record the key information D31, and the key information D31
  • Patient information used for generation, registered medical record attribute information (medical institution, medical date, record management number), and the like are provided.
  • Step S304 the user makes a medical record registration request including the key information and patient information acquired in step S303 as information for specifying a patient, and the medical record image data, and the medical record registration unit 102 of the medical record management apparatus 1.
  • Step S304 For example, after acquiring the result of a registration information inquiry request on a Web page accessed when inquiring registration information, the user designates a patient from the information acquired on the Web page and registers a medical record.
  • the medical record image data may be input in accordance with an information input request that is transmitted as a reply.
  • an inquiry data reference list which is a list for referring to data inquired by the registration information inquiry unit 103, is provided from the registration information inquiry unit 103 to the medical record registration unit 102 via the Web page or the like.
  • the inquiry data reference list includes, for example, user information (institutional information) that is information at the time of inquiry request and information that identifies a patient, and key information and / or patient information that is information provided to the user information. It may be information including a record management number of a patient's medical record and a block Hash of a block including the record management number.
  • the reference data reference list includes information (patient information and record management number) for the user to specify a patient and medical record, and information (key information and block) for accessing the specified patient and medical record information. Hash and the like) are preferably included. In addition to these pieces of information, information provided to the user (public information in a block or the like) may be included.
  • the medical record registration unit 102 that has received the information specifying the patient from the user and the image data of the medical record performs a consent check based on the received information and the user information (step S305).
  • a consent check for example, whether or not the consent information block of the designated patient associated with the requesting user's medical institution is registered in the block chain 22, or the hash value is set in the consent information block and the consent information block.
  • the medical record registration unit 102 adopts a record management number assigned to the image data of the received medical record (step S306). Further, the medical record registration unit 102 calculates the Hash value of the received medical record image data (private information) (step S307). If the medical record registration unit 102 receives non-public information in addition to the medical record image data, the medical record registration unit 102 may calculate a hash value for the non-public information.
  • the medical record registration unit 102 creates the contents (data part D22 of the medical record block) to be registered in the block chain 22 (step S308).
  • the medical record registration unit 102 creates a data part D22 including at least a record management number as the management number D221 and a hash value of the medical record image data as the non-public information management information D223. If the information received in step S304 includes non-public information other than the image data of the medical record, the medical record registration unit 102 stores the private information Hash in the private information management information D223. Include value.
  • the medical record registration unit 102 performs block addition processing for adding the medical record block including the created data part D22 to the block chain 22 (step S309).
  • the block addition process may be the same as the operation in steps S105 to S108 shown in FIG.
  • the medical record registration unit 102 when receiving the block hash from the management node 21, registers the received block hash as block management information in the registration information DB 3 in association with the patient key information. More specifically, the medical record registration unit 102 transmits a DB update request including the key information and the acquired block hash to the registration information DB 3, and the key information of the patient management information in the registration information DB 3 matches.
  • the block management information D33 in the record is updated (added) (steps S310 and S311).
  • the medical record registration unit 102 When receiving the fact that the update is completed from the registration information DB 3 (step S312), the medical record registration unit 102 stores the record management number acquired in step S306 and the medical record image data received from the user in the medical record DB 4. Register in association. At this time, if the received information includes other non-public information, the non-public information is also registered.
  • the medical record registration unit 102 transmits a DB registration request including at least the record management number and the image data of the medical record to the medical record DB 4, and registers a new record (medical record information) in the medical record DB 4 (Step S1). S313, step S314).
  • the medical record registration unit 102 when receiving the registration completion from the medical record DB 4 (step S315), notifies the requesting user of the completion of registration and ends the processing (step S315).
  • the medical record registration unit 102 registers the medical record image data in the medical record DB 4 after adding the medical record block to the block chain 22.
  • a medical record block may be added to the block chain 22 after registering the record image data.
  • the medical record registration unit 102 returns to the requesting user that the registration of the medical record is not accepted and ends the process.
  • the user in this operation is assumed to be a medical institution that creates a medical record to be referred to, a medical institution other than the medical record creator, or a third party.
  • the user transmits a registration information inquiry request including user information and information for specifying a patient to the registration information inquiry unit 103 of the medical record management apparatus 1 (step S401).
  • the registration information inquiry unit 103 that has received the user information and the information for identifying the patient performs a registration information inquiry process for inquiring registration information of the designated patient (step S402).
  • the registration information inquiry process may be the same as the operation in step S302 in FIG. 8, that is, the operation in steps S202 to S213 in FIG. The same applies when information for identifying a patient is omitted.
  • the registration information inquiry unit 103 provides the acquired information within the range permitted by the requesting user. (Step S403).
  • a legitimate user who obtains consent from the patient or contractor and refers to the medical record (medical institution receiving medical care, other medical institution with reference authority, third-party institution with consent for disclosure, etc.)
  • the user transmits a medical record reference request including the record management number acquired in step S403 as information for specifying image data of the medical record to be referred to the medical record providing unit 104 of the medical record management apparatus 1 (Ste S404).
  • the user obtains the result of the registration information inquiry request on the Web page accessed when the registration information is inquired, and then designates the medical record to be referred to from the information acquired on the Web page.
  • a record reference request may be transmitted.
  • an inquiry data reference list which is a list for referring to data inquired by the registration information inquiry unit 103, is provided from the registration information inquiry unit 103 to the medical record provision unit 104 via the Web page or the like. Shall be.
  • the medical record providing unit 104 that has received the information specifying the medical record such as the record management number or the block Hash of the medical record block from the user performs an authority check based on the received information and the user information (step S405).
  • the medical record providing unit 104 transmits a DB search request including the record management number to the medical record DB 4 (step S406).
  • the medical record providing unit 104 refers to the request or inquiry data list to the block chain management system 2 and stores the corresponding block of the corresponding medical record. What is necessary is just to acquire the recording management number contained in a data part.
  • the record management DB 4 searches the data recorded on the recording medium based on the information included in the DB search request (step S407).
  • medical record information including the designated record management number is registered in the medical record DB 4, and the record is returned from the medical record DB 4 to the medical record providing unit 104 (step S408).
  • the medical record providing unit 104 acquires the data part of the medical record block (step S409).
  • the block data acquisition process may be the same as the operation from step S210 to step S212 shown in FIG.
  • the medical record providing unit 104 includes the hash value indicated by the private information management information D223 included in the data part including the record management number of the medical record designated by the user, and the private information included in the record received in step S408.
  • the hash value generated from the information (image data of medical records) is collated (step S410). If the Hash values match, it is determined that the non-public information has not been tampered with, and the non-public information is transmitted to the requesting user (step S411).
  • the medical record providing unit 104 may perform the operations from step S405 to step S411 for the number of designated medical records.
  • FIG. 8 and FIG. 9 show an example in which a user makes a registration information inquiry request and then makes a medical record registration request or a medical record reference request based on the information obtained as a result, It is also possible to register medical records and refer to medical records with a single request.
  • the user may transmit a medical record registration request including user information, information specifying a patient, and medical record image data to the medical record registration unit 102.
  • the medical record registration unit 102 requests the registration information inquiry unit 103 to inquire registration information based on the received information, obtains registration information of the designated patient, and then performs the above medical record registration process. Can be done.
  • the user may transmit a medical record reference request including user information, information for specifying a patient, and an acquisition range (date and time, conditions, etc.) to the medical record providing unit 104.
  • the medical record providing unit 104 requests the registration information inquiry unit 103 to inquire registration information, obtains registration information of the designated patient, and provides it based on the acquisition range.
  • the medical record may be specified and the medical record providing process described above may be performed.
  • FIG. 10 is an explanatory diagram showing an example of authority check in the medical record management system 10.
  • the medical record management system 10 may confirm the access authority of the requesting user according to the conditions shown in FIG. That is, the medical record management system 10 first determines whether or not the requesting user is a service subscriber. If it is not a service subscriber, it is assumed that the user does not have access rights to the information of the inquiry destination. On the other hand, if it is a service subscriber, it is further determined whether the user's institution is a medical institution or other (third party institution).
  • the user's institution is a medical institution
  • the reference authority is, for example, the medical institution of the patient designated as the reference destination or the medical institution that created the medical record specified as the reference destination, the user (medical institution) who wants to refer to the patient, or the patient himself as the disclosure destination. It can be set by registering an introductory letter or a letter of consent designating (institution) in this system (registration information DB 3).
  • registration information DB 3 Registration information DB 3
  • the user's institution is a third-party institution other than a medical institution
  • it is further determined whether or not the inquired information is contractor information and there is a disclosure agreement. If the information of the inquiry destination is the information of the contractor of the user (third party organization) and there is a disclosure agreement, it is assumed that the user has an access right to the information of the inquiry destination.
  • the information of the inquiry destination is the contractor's information or whether there is a disclosure agreement, for example, the setting of the contractor who designates the individual and the reference authority can be set for this system. It can be determined by associating these settings with the patient management information.
  • the user shall not have access to the information of the inquiry destination.
  • the third-party organization can refer to the medical record registered by the medical institution within the range permitted to be disclosed by the patient. Medical records can also be obtained. It is also possible to make inquiries to medical institutions using the obtained information. For this reason, if the third-party organization is an insurance company, it is possible to obtain benefits such as a reduction in survey costs, an improvement in accuracy, and a suppression of unauthorized payment of benefits.
  • medical institutions can reduce the burden of storing medical records. For this reason, for example, it is not necessary to discard medical records that had to be discarded due to cost.
  • medical records are stored for a long period of time, it is possible to deal with a case where an inquiry request for old medical records is received from a patient. For example, it is possible to prepare for medical lawsuits after closing.
  • FIG. 11 is a block diagram showing another example of the medical record management apparatus 1 of the present embodiment.
  • the medical record management apparatus 1 may further include a charging unit 105.
  • the charging unit 105 charges the user according to the user and the usage content.
  • the charging unit 105 may charge only for registration of medical records and reference of medical records registered by other medical institutions. In this case, reference to the medical record registered by the user is free. Further, if the user is a third-party organization, the billing unit 105 may perform pay-as-you-go for the registration information inquiry and the medical record reference as a usage fee in addition to a certain annual fee. For example, charging according to the usage amount of the system, such as the amount of information provided by the system, the number of times of provision, the number of inquiries, etc., may be performed. In addition, the billing unit 105 can perform billing according to a period during which information is stored.
  • FIG. 12 is a block diagram showing another example of the medical record management apparatus 1 of the present embodiment.
  • the medical record management apparatus 1 may further include an authority determination unit 106.
  • the authority determining unit 106 determines whether or not there is an access right to information related to the patient or medical record designated for the requesting user.
  • the medical record management apparatus 1 includes a registration unit 11, a providing unit 12, and a charging unit 105, and the registration unit 11 includes a patient registration unit 101 and a medical record registration unit 102.
  • the providing unit 12 may include a registration information inquiry unit 103, a medical record providing unit 104, and an authority determining unit 106.
  • FIG. 13 is a schematic block diagram illustrating a configuration example of a computer according to the embodiment of the present invention.
  • the computer 1000 includes a CPU 1001, a main storage device 1002, an auxiliary storage device 1003, an interface 1004, a display device 1005, and an input device 1006.
  • Each device (including nodes) of the above-described medical record management system may be implemented in the computer 1000, for example.
  • the operation of each device may be stored in the auxiliary storage device 1003 in the form of a program.
  • the CPU 1001 reads out the program from the auxiliary storage device 1003 and develops it in the main storage device 1002, and executes the predetermined processing in the above embodiment according to the program.
  • the auxiliary storage device 1003 is an example of a tangible medium that is not temporary.
  • Other examples of the non-temporary tangible medium include a magnetic disk, a magneto-optical disk, a CD-ROM, a DVD-ROM, and a semiconductor memory connected via the interface 1004.
  • the computer that has received the distribution may develop the program in the main storage device 1002 and execute the predetermined processing in the above embodiment.
  • the program may be for realizing a part of predetermined processing in each embodiment.
  • the program may be a difference program that realizes the predetermined processing in the above-described embodiment in combination with another program already stored in the auxiliary storage device 1003.
  • the interface 1004 transmits / receives information to / from other devices.
  • the display device 1005 presents information to the user.
  • the input device 1006 accepts input of information from the user.
  • some elements of the computer 1000 may be omitted. For example, if the device does not present information to the user, the display device 1005 can be omitted.
  • each device is implemented by general-purpose or dedicated circuits (Circuitry), processors, etc., or combinations thereof. These may be constituted by a single chip or may be constituted by a plurality of chips connected via a bus. Moreover, a part or all of each component of each device may be realized by a combination of the above-described circuit and the like and a program.
  • each device When some or all of the constituent elements of each device are realized by a plurality of information processing devices and circuits, the plurality of information processing devices and circuits may be centrally arranged or distributedly arranged. Also good.
  • the information processing apparatus, the circuit, and the like may be realized as a form in which each is connected via a communication network, such as a client and server system and a cloud computing system.
  • FIG. 14 is a block diagram showing an outline of the medical record management apparatus of the present invention.
  • the medical record management apparatus 6 of the present invention is characterized by including a registration unit 601 and a providing unit 602.
  • a predetermined first storage unit for example, Processing according to a predetermined consensus algorithm in which record identification information (for example, record management number) for identifying a medical record and image data are stored in association with each other in the medical storage DB 4) and two or more nodes participate.
  • a medical record block including record identification information and a summary of image data is added to a predetermined block chain (for example, the block chain 22) to which a new block is added via a predetermined second storage means (for example, , Registration information DB3), patient identification information for identifying a patient (for example, patient key information), and block identification information that can identify a medical record block It stores an association.
  • a predetermined block chain for example, the block chain 22
  • a new block is added via a predetermined second storage means (for example, , Registration information DB3)
  • patient identification information for identifying a patient for example, patient key information
  • the providing unit 602 (for example, the providing unit 12, particularly the medical record providing unit 104) is stored in the first storage unit in response to a request from a user including a third party organization that is an organization other than the medical institution.
  • the image data of the medical record of the designated patient is retrieved from the image data of the current medical record and provided.
  • the patient identification information includes first patient identification information (for example, information for identifying an individual) or first information that is information that allows an organization other than the medical institution that created the medical record to identify a patient of the medical institution.
  • Second patient specifying information generated from the patient specifying information (for example, a Hash value generated from information specifying an individual) may be included.
  • the providing unit 602 receives a request including first patient specifying information as information for designating a target patient from the user, and provides patient identification information specified based on the received first patient specifying information. It may be used to identify a patient's medical record block and acquire image data of the patient's medical record.
  • the patient identification information may include medical institution information that is information on a medical institution that creates a medical record and third patient identification information that is a set of identification information on a patient in the medical institution.
  • the providing unit 602 receives a request including third patient specifying information as information specifying the target patient from the user, and patient identifying information specified based on the received third patient specifying information. May be used to identify the patient's medical record block and acquire image data of the patient's medical record.
  • First storage means for storing at least image data of medical records provided from medical institutions;
  • a second storage means for storing information associating the target patient of the medical record with the image data of the medical record;
  • record identification information for identifying the medical record and image data are stored in association with each other in the first storage means, and 2
  • Registration means for associating and storing patient identification information for identifying a patient and block specifying information that is information capable of specifying a medical record block in the storage means of 2;
  • image data of a patient's medical record designated from the medical record image data stored in the first storage means
  • a medical record management system comprising
  • Medical record image data provided by a medical institution is medical record image data that has exceeded the retention obligation period
  • the medical record management system according to supplementary note 1, wherein the registration unit receives provision of image data of a medical record of the patient from a plurality of medical institutions.
  • the registration means divides the information provided by the medical institution into public information and non-public information, and then manages information for managing information in the block, a summary of the public information and the non-public information, Registering the block including the blockchain and storing the non-public information in the first storage means or the second storage means, Private information includes medical record image data,
  • the medical record management system according to supplementary note 1 or supplementary note 2, wherein the management information includes record identification information.
  • the patient identification information is generated from first patient identification information or first patient identification information that is information that allows an organization other than the medical institution that created the medical record to identify a patient at the medical institution.
  • Second patient specific information is included,
  • the providing means receives a request including first patient specifying information as information for designating a target patient from a user, and uses the patient identification information specified based on the received first patient specifying information to perform patient medical care.
  • the medical record management system according to any one of supplementary notes 1 to 4, wherein identification of a record block and acquisition of image data of a medical record of a patient are performed.
  • the patient identification information includes third institution identification information that is a set of medical institution information that is information of a medical institution that creates a medical record and identification information of a patient in the medical institution,
  • the providing means receives a request including third patient specifying information as information for designating the target patient from the user, and uses the patient identification information specified based on the received third patient specifying information to perform patient medical care.
  • the medical record management system according to any one of supplementary notes 1 to 5, wherein identification of a recording block and acquisition of image data of a medical record of a patient are performed.
  • the providing means provides the image data after determining whether the image data has been tampered with using the summary of the image data included in the medical record recording block. Medical record management system.
  • Inquiring means for providing a registration status of information about a designated patient in the first storage means, block chain or second storage means in response to a request from a user including a third party organization that is an organization other than a medical institution
  • the medical record management system according to any one of appendix 1 to appendix 7.
  • the registration means includes at least the medical institution information which is information on the medical institution in the block chain The information block is added, and the patient identification information for identifying the patient and the block specifying information that is information that can specify the consent information block are stored in the second storage means in association with each other.
  • the medical record management system according to any one of the above.
  • First storage means for storing at least image data of medical records constructed in a secure environment and provided from a medical institution;
  • a second storage means that is constructed in a secure environment and stores information for associating the patient to be medical records with the image data of the medical records;
  • a third storage means possessed by a node operated by a third party that is an organization other than a medical institution;
  • the storage means 3 stores the medical record block including the record identification information and the summary of the image data
  • the second storage means includes patient identification information for identifying the patient and information that can specify the medical record block.
  • Registration means for associating and storing certain block identification information;
  • image data of a patient's medical record designated from the medical record image data stored in the first storage means A medical record management system comprising a providing means for searching and providing.
  • And registration means for associating and storing patient identification information for identifying a patient and block specifying information that is information capable of specifying a medical record block in a predetermined second storage means,
  • image data of a patient's medical record designated from the medical record image data stored in the first storage means
  • a medical record management apparatus comprising a providing means for searching and providing.
  • Information processing device is Each time image data of a medical record of a patient of the medical institution is provided from a medical institution, record identification information for identifying the medical record and image data are stored in association with each other in a predetermined first storage unit, In addition, a medical record block including record identification information and a summary of image data is added to a predetermined block chain in which a new block is added through processing according to a predetermined consensus algorithm in which two or more nodes participate, And in the predetermined second storage means, the patient identification information for identifying the patient and the block specifying information that is information capable of specifying the medical record block are stored in association with each other, In response to a request from a user including a third-party organization that is an organization other than a medical institution, image data of a patient's medical record designated from the medical record image data stored in the first storage means A medical record management method characterized by searching and providing.
  • the present invention is not limited to medical records, and can be suitably applied to uses that enable provision of highly confidential information to an organization other than the source organization.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

診療記録管理装置6は、医療機関から診療記録の画像データが提供される度に、所定の第1の記憶手段に診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、所定のブロックチェーンに記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、所定の第2の記憶手段に患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段601と、第三者機関を含むユーザからの要求に応じて、第1の記憶手段の中から指定された患者の診療記録の画像データを検索して提供する提供手段602とを備える。

Description

診療記録管理システム、装置、方法およびプログラム
 本発明は、診療記録を管理するための診療記録管理システム、診療記録管理装置、診療記録管理方法および診療記録管理プログラムに関する。
 医療従事者が患者の診療において知り得た患者の身体状況、病状、治療等の診療情報は、診療記録として、医療機関などに一定期間保管される。ここで、診療記録は、医師が所定の診療に関する事項を記録する診療録(カルテ)に限定されず、診療の過程で得られた患者の身体状況、病状、治療等について作成、記録または保存された書類、画像等の記録をいう。診療記録には、例えば、処方せん、手術記録、看護記録、検査所見記録、エックス線写真、紹介状、退院した患者に係る入院期間中の診療経過の記録など、診療の過程その他の過程で作成された患者に関する情報が記録された任意の媒体が含まれる。なお、診療情報が電子媒体に記録されている場合には、その電子媒体において診療情報として記録されている符号化されたデータの集合が診療記録に相当する。
 ところで、医師には、医師法により、病院または診療所の管理者において、5年間カルテを保存する義務がある。なお、病院または診療所の管理者には、カルテ以外にも、その他医療行為に関する記録(手術記録、検査結果、X線写真等)に対して2年、および保険診療における診療録以外の給付に関する帳簿及び書類に対して完結の日から3年の保存義務がある。
 したがって、医療機関は、保存義務のあるカルテその他の診療記録を少なくとも保存義務が課せられた期間(以下、保存義務期間という)、保管しなければならない。なお、医師法には、保存義務についての規定はあるが、廃棄義務についての規定はない。したがって、医療機関は、保存義務期間を超過した診療記録を保管しつづけることもできるが、廃棄することもできる。
 地域医療支援病院や特定機能病院など比較的大きな病院の中には、過去の診療情報を解析して現在の診療に役立てたり、訴訟や過去の患者からカルテの照会があった時に対応するために、電子カルテを導入するなどして診療記録を長期保存しているところがある。しかし、一次診療などを行う個人経営の診療所などでは、紙媒体の診療記録をそのまま保管しているところも多い。このような保管にかかる費用を抑えるために、多くの診療所において、保存義務期間を過ぎた診療記録は廃棄されているのが現状である。とくに小さな診療所などでは、費用だけでなく保管場所などの問題から、保存義務のない診療記録を廃棄する場合もある。一例として、医師の引退などによる閉院の際に、保存義務のない診療記録は廃棄される場合が挙げられる。
 その一方で、保険会社が、申込者や加入者からの告知内容や請求内容に対してその真偽を調査する追跡調査の対象とされる期間(以下、追跡期間という)は、現在から過去5年以上を含む期間である場合がある。保険会社は、この追跡調査で、告知内容や請求内容と照会するために、対象者とされた申込者や加入者の通院歴や病歴を調査する。医療機関以外にも、この保険会社などのように5年以上前の診療記録を必要とする他業種機関がある。
 保険会社における追跡期間は、より具体的には、加入時に指定された告知指定期間の開始時点から告知義務違反による保険契約解除の時効である解除期限までであることが多い。告知指定期間は、一般に5~7年である。また、告知義務違反による解除期限は、保険法により、責任開始日から2年もしくは5年、または告知義務違反の内容が重大な場合は無期限(時効なし)である。したがって、追跡期間のの開始時点が加入時の5~7年前であることも多い。なお、追跡期間の始まりは、照会時を基準にすれば、さらに過去の時点となる。
 例えば、告知指定期間が5年であり、責任開始日以降に支払い事由があったが、支払い事由がない場合の解除期限(責任開始日から2年)を超過後に、別事由で保険金の請求があったとする。保険会社が、当該請求の有効性を判定するためには、請求にかかる事由の真偽だけでなく、この加入者の告知義務違反の有無および告知義務違反があった場合にはその解除期限を超過しているかを調査する必要がある。したがって、この調査では、告知指定期間中および解除期限を決定づける責任開始日から2年を満了するまでの期間中の診療記録が必要となる。すなわち、調査開始時である現時点から、約7年間(責任開始日から請求までの経過期間(約2年)+加入前の告知指定期間(5年))分の診療記録が必要となる。
 さらに長い例として、責任開始日から支払い事由がある場合の解除期限である5年を経過した後の請求であっても、重大な告知義務違反の有無を調査しようとすれば、現時点から10年以上前(責任開始日から請求までの経過期間(5年超)+加入前の告知指定期間(5年))の診療記録が必要となる場合も考えられる。
 図15は、このような保険会社による追跡期間と医療機関における診療記録の保存義務期間との関係を示す説明図である。図15に示すように、保険会社が調査のために医療機関に照会を行うとき(図中の照会時)には、必要とされるカルテが既に廃棄されているケースがある。
 診療記録の保管および他機関への提供に関連する技術として、例えば、特許文献1、2に記載の技術がある。特許文献1には、複数の医療機関の電子カルテの複写を一括して保管する第1の記憶手段と、提供用の情報を保管する第2の記憶手段と、処理手段とを備えた装置による電子カルテの提供方法が記載されている。当該方法において、処理手段は、紹介元の医療機関からの要求に応じて、紹介患者の電子カルテを第1の記憶手段から取得して紹介先の医療機関情報を付加して第2の記憶手段に記憶する。また、処理手段は、紹介先医療機関からの照会要求に応じて、第2の記憶装置を検索し、該当する診療情報を送信する。
 また、特許文献2には、汎用性と保全性とを備えたとされる診療情報配信方法が記載されている。特許文献2に記載の方法は、診療情報配信サーバが、電子カルテシステムで作成されるような汎用画像フォーマットでない形式の診療情報データを取り込んでストレージに保管する。そして、診療情報配信サーバが、参照端末からの配信要求に対して、ストレージに保管されている診療情報データを画像データに変換するとともに、該画像データに改変を防止するための改変防止情報を付して配信する。
特開平11-143956号公報 特開2007-295417号公報
 上述したように、診療記録には、需要のある期間と確実に提供が可能な期間とが重複しない期間、すなわち需要があっても提供できない可能性がある期間が存在している。このため、例えば、保険会社が、調査対象者から診療記録に関する情報開示の同意を得たとしても、必要な診療記録が残っていないという問題がある。また、例えば、必要な診療記録が運よく残っていたとしても、調査対象者から告知されていない病歴に関する診療記録である場合には、保険会社がその診療記録にたどりつくのは困難であるという問題がある。
 なお、診療記録の作成元の医療機関においても、保存義務のない診療記録の需要はある。しかし、医療機関、とくに小さな診療所が、保存義務のない診療記録を保管しつづけるには負担が大きいという問題がある。
 これらの問題を解決するためには、小さな診療所を含む多くの医療機関において作成された保存義務のない診療記録を含む診療記録を比較的長期にわたり保管でき、かつ医療機関以外の機関が、自身に与えられた権限に基づいて、保管されている中から所望の診療記録を自由に参照できる仕組みを提供することが有効であると考える。
 なお、特許文献1には、複数の医療機関が保管している電子カルテの複製を一括して管理するバックアップセンターという概念を開示した上で、そのようなバックアップセンターを利用して、紹介元の医療機関から紹介先の医療機関へと診療記録を受け渡す方法が記載されている。しかし、当該方法では、医療機関が保管している電子カルテしか対象としておらず、電子カルテが導入されていない医療機関の診療記録を得ることができないという問題がある。
 また、当該方法は、紹介元の医療機関からの要求に応じて、紹介患者の電子カルテに紹介先の医療機関情報を付して第2の記憶手段に記憶する。当該方法では、紹介元の機関が紹介先の機関を知らなければ提供の情報が作成されないため、保険会社のような特定の個人の診療記録の有無を知るための調査には利用できない。
 さらに、現実に、保存義務のない複数の医療機関の電子カルテを長期間にわたり保管することを考えた場合、保管にかかるコストをだれが負担するかといった費用面の問題が生じる。例えば、特許文献1に記載の方法によって利益を享受するユーザは、紹介先の医療機関と紹介元の医療機関と紹介患者の3ユーザだけである。この3ユーザが、多くの患者にとってそれほど多くない転院等の機会に伴う当該方法による利益のために、電子カルテの保管にかかるコストを負担するとは考えにくい。
 そのような費用負担の面からも、医療機関以外の機関をユーザに含んだ上記の仕組みは有効であると考えるが、そのような仕組みを実現するためには、保管中の診療記録その他の個人情報に対する秘匿性と、医療機関以外の機関が、自身に与えられた権限に基づいて、保管されている中から所望の診療記録を自由に参照できるアクセス性とを両立させることが重要である。さらには、これら個人情報に対する秘匿性と保管中のデータのアクセス性と該データの完全性(改ざん防止)とが両立されることが好ましい。
 ここで、アクセス性は、例えば、保険会社などが該診療記録を参照することを想定し、複数の機関が各々の権限の範囲内において、受診の事実や受診先の医療機関を知らなくても、保管されている中から所望の診療記録にたどりつけることである。また、アクセス性は、例えば、登録する側の医療機関が、診療記録の記録形式にかかわらず、容易に登録できることを含んでいてもよい。
 なお、特許文献2には、データの汎用性と保全性とを両立させて診療情報を配信する方法の一例が記載されている。しかし、当該方法は、参照端末からの配信要求に応じて、汎用画像フォーマットでない形式の診療情報データにアクセス情報および改変防止情報を付加するため、ストレージに保管中の診療情報データに対する保全が十分でない。さらに、特許文献2に記載の方法は、上述したような個人情報に対する秘匿性とデータのアクセス性との両立や、さらにこれらとデータの完全性との両立については何ら考慮されていない。
 本発明の目的は、上述した課題に鑑み、個人情報に対する秘匿性とデータのアクセス性とデータの完全性とを少なくとも両立させつつ、複数の医療機関の診療記録の保管および医療機関以外の機関への提供サービスを実現することである。より具体的には、本発明の目的は、保存義務のない診療記録を含む複数の医療機関の診療記録を比較的長期にわたり保管でき、かつ異業種を含む複数の機関が自身に与えられた権限に基づいて所望の診療記録を参照できる診療記録管理システム、診療記録管理装置、診療記録管理方法および診療記録管理プログラムを提供することである。
 本発明による診療記録管理システムは、医療機関から提供された診療記録の画像データを少なくとも記憶する第1の記憶手段と、診療記録の対象患者と診療記録の画像データとを対応づける情報を記憶する第2の記憶手段と、医療機関から該医療機関の患者の診療記録の画像データが提供される度に、第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、かつ第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段と、医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する提供手段とを備えたことを特徴とする。
 また、本発明による診療記録管理システムは、セキュアな環境に構築され、医療機関から提供された診療記録の画像データを少なくとも記憶する第1の記憶手段と、セキュアな環境に構築され、診療記録の対象患者と診療記録の画像データとを対応づける情報を記憶する第2の記憶手段と、医療機関以外の機関である第三者機関が運営するノードが有する第3の記憶手段と、医療機関から該医療機関の患者の診療記録の画像データが提供される度に、第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ第3の記憶手段に、記録識別情報と画像データの要約とを含む診療記録ブロックを記憶し、かつ第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段と、医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する提供手段とを備えたことを特徴とする。
 本発明による診療記録管理装置は、医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段と、医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、前記第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する提供手段とを備えたことを特徴とする。
 本発明による診療記録管理方法は、情報処理装置が、医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶し、医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、前記第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供することを特徴とする。
 本発明による診療記録管理プログラムは、コンピュータに、医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する処理、および医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、前記第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する処理を実行させることを特徴とする。
 本発明によれば、個人情報に対する秘匿性とデータのアクセス性とを少なくとも両立させつつ、複数の医療機関の診療記録の保管および医療機関以外の機関への提供サービスを実現できる。
第1の実施形態の診療記録管理システムの例を示すブロック図である。 管理ノード21の構成例を示すブロック図である。 本発明の実施形態のデータの流れの概略を示す説明図である。 ブロックチェーン22、登録情報DB3および診療記録DB4に記憶される情報のデータ構造の例を示す説明図である。 診療記録管理システム10の各段階のフローの一例を示す説明図である。 診療記録管理システム10の動作の一例を示すシーケンス図である。 診療記録管理システム10の動作の一例を示すシーケンス図である。 診療記録管理システム10の動作の一例を示すシーケンス図である。 診療記録管理システム10の動作の一例を示すシーケンス図である。 権限チェックの例を示す説明図である。 診療記録管理装置1の他の例を示すブロック図である。 診療記録管理装置1の他の例を示すブロック図である。 本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。 本発明の診療記録管理システムの概要を示すブロック図である。 保険会社による追跡期間と医療機関における診療記録の保存義務期間との関係を示す説明図である。
 以下、図面を参照して本発明の実施形態について説明する。まず、本発明の診療記録管理システムの構成に至ったビジネスモデルについて簡単に説明する。
 本発明による診療記録管理システムは、医療機関から診療記録を預かり保管するとともに、診療記録を預けた医療機関および本システムが提供する診療記録提供サービスに加盟している他の機関から要求があった場合に、それら機関に与えられた権限に基づいて、保管している診療記録を提供する。
 本発明では、システムを利用する機関の1つとして、保険会社や調査会社といった医療機関以外の機関であって、特定の個人の診療記録を所望する機関(以下、第三者機関という)を想定する。そのような第三者機関をユーザに加え、かつ該第三者機関にシステム運用にかかるリソースまたは費用を分散して負担させることができるシステム構成とすることにより、診療記録を提供する医療機関側の導入コストを抑え、小さな診療所であっても比較的低負担で本システムを利用できるようにする。
 例えば、本システムにおいて、医療機関に対しては、本システムが提供する診療記録の参照サービスにかかる利用料を無料とする一方で、第三者機関に対しては、該利用料としての年会費などをサービス加盟条件としてもよい。このとき、該利用料を従量課金制とすることなども考えられる。例えば、本システムが参照サービスにおいて提供した情報の量や提供回数や照会回数などといった本システムの利用量に応じて利用料を定めてもよい。
 また、例えば、本システムにおいて、第三者機関にシステム運用にかかる物理リソースを分散して負担させる方法として、公開してもよい診療記録の一部の情報を、第三者機関が運営する装置(ノード)に記憶するなどして、第三者機関側に保有させてもよい。
 このような医療機関と医療機関以外の第三者機関とに向けて、診療記録を長期保管・参照できるサービスを提供することにより、第三者機関と医療機関とをつなげ、診療記録の利用価値を高める。
 例えば、小さな診療所等は、かかりつけ医として一次診療を行うことが多く、担当分野における患者の病歴を網羅するような診療記録を保有している可能性が高い。このような小さな診療所でも利用できるようなサービスを提供することで、他機関での診療記録の利用価値をさらに高めることができる。なお、サービスの提供先に、患者自身を含めることも可能である。
 次に、そのようなビジネスモデルを実現するための技術コンセプトを簡単に説明する。
 本発明では、複数の医療機関と複数の第三者機関といった異なる機関による利用を前提とすることから、複数のノードによる分散管理が可能で、保全性が高く、かつデータ同士が繋がりやすいという特徴を有するブロックチェーンを利用して、診療記録の属性情報を管理する。一方、診療記録自体は、秘匿性が高いことから、セキュアな環境に構築された所定の記憶装置に記憶することにより管理する。
 さらに、本発明では、電子カルテ未導入の医療機関も利用できるよう、診療記録を全て画像データとして扱い、特定のフォーマットを必要としないようにする。例えば、紙媒体の診療記録や他の形式の電子カルテについては、スキャナで読み込んだり印刷データ形式にフォーマット変換するなどして画像化した上で登録するようにする。これにより、電子カルテを導入していないような比較的小さな診療所であっても、本システムを利用できるようにする。
 ここで、ブロックチェーンは、ブロックとよばれる所定のデータ構造を有するデータ群を時系列に並べたものであり、各ブロックに記録した情報を保持しつづける記録台帳としての役割を有する。各ブロックは、ブロックチャーンに保持させたい情報の他に、一つ以上前のブロック(以下、前ブロックという)の情報と、改ざんの有無を検知するための情報(ノンスと呼ばれる検証情報や署名など)とを含む。
 ブロックチェーン管理システムでは、ブロックチェーンに新たなブロックを追加する際に、2台以上の管理ノードが参加する所定のコンセンサスアルゴリズムに従った処理(以下、コンセンサス処理という)が行われる。そして、管理ノードの各々は、当該コンセンサス処理の実行を通して、ブロックチェーンのコピーを保持する。
 例えば、コンセンサスアルゴリズムの一つであるPoW(Proof of Work)では、前ブロックの情報とノンスとを含む各ブロック(データ群)に対して、「ブロックのHash値が閾値(ターゲット値)以下であること」といった規則が予め決められており、ブロックを追加する際に、そのような規則を満たすようなノンスを複数の管理ノードが同時並列的に探索する処理が行われる。このようなコンセンサス処理を行うことにより、改ざん困難性を担保しつつ、複数の管理ノードに情報の複製を保持させることができる。なお、ブロックチェーン管理システムにおけるコンセンサスアルゴリズムは、PoWに限定されない。例えば、PoW以外にもBFT(Byzantine fault tolerance)等のコンセンサスアルゴリズムも利用可能である。
 ただし、ブロックチェーンは、上記の特徴と引き換えに複製が複数のノードに保持される特徴も有していることから、データの秘匿性は低い。このため、上述したように秘匿性の高い情報については、セキュアな環境に構築した別の周辺システムに記憶させる。その上で、周辺システムとブロックチェーンとを連携させる。
 本システムは、例えば、診療記録の画像データや該診療記録の属性情報などの保管対象情報が医療機関から提供される度に、それらを公開情報と非公開情報とに分類し、非公開情報を周辺システムに記憶させるとともに、公開情報と非公開情報の要約とを含むブロックをブロックチェーンに追加してもよい。また、診療記録の画像データは非公開情報に分類される。このとき、ブロックチェーンに追加するブロックに、非公開情報を識別する情報や、患者を識別する情報を含めてもよい。
 周辺システムは、例えば、公開情報が登録されるブロックチェーンとの連携が可能なシステムであって、内部仕様がクローズドなシステムが好ましい。なお、「連携」は、少なくともブロックチェーンへのブロックの追加およびブロックチェーン内のデータ参照を含む。周辺システムで、ユーザからのアクセスに対して権限チェックを行い、ユーザごとに許可された範囲の情報の参照のみを許可する。このようにして、非公開情報の秘匿性を確保する。
 このようなブロックチェーンを利用して、例えば、サービスに加盟した第三者機関が、管理ノードのいずれかが保持するブロックチェーンを自由に参照できるようにしてもよい。また、ブロックチェーンを利用すれば、複製を保持するノードの追加や削除といった動的環境への適応が容易であるので、例えば、上記のノードを、第三者機関が提供するサーバ上に実装させるなどの運用を行えば、運用にかかるリソースを第三者機関に分散して負担させることができるだけでなく、新たな第三者機関の加盟時にも動的に対応できる。
[実施形態1]
 次に、本発明の実施形態について図面を参照して説明する。図1は、本実施形態の診療記録管理システムの例を示すブロック図である。図1に示すように、診療記録管理システム10は、診療記録管理装置1と、ブロックチェーン管理システム2と、登録情報DB(データベース)3と、診療記録DB4とを備える。これらは各々、ネットワーク5を介して接続されている。
 ブロックチェーン管理システム2は、上述したような、ブロックチェーンを複数のノードが共有して管理するシステムである。なお、ブロックチェーンを管理するシステムとして、ブロックチェーン管理システム2を例示するが、所定のコンセンサス処理を実行可能で、かつ改ざんが困難なブロックチェーンを記録台帳としてシステム内の端末で共有するシステムであれば、詳細な構成・仕様等は特に限定されない。
 管理ノード21は、ブロックチェーン管理システム2において、コンセンサス処理を実行するノードである。管理ノード21の各々は、当該コンセンサス処理の実行を通して、ブロックチェーン22のコピーを保持する。
 本実施形態のブロックチェーン22には、医療機関から診療記録の画像データが提供される度に、診療記録の属性情報の少なくとも一部と診療記録の画像データの要約とを含む記録ブロックが登録(追加)される。なお、ブロックチェーン22への記録ブロックの追加処理の詳細は後述する。
 登録情報DB3は、本システムへの診療記録の提供に承諾した患者と、ブロックチェーン22に登録した当該患者の情報を含むブロックとを対応づける患者管理情報を記憶する。登録情報DB3は、例えば、診療記録管理装置1における当該患者のキー情報と対応づけて、当該患者の公開情報および診療記録の画像データその他の非公開情報の要約を記録したブロックを検索および検証するためのブロック管理情報を記憶する。
 患者のキー情報として、診療記録管理装置1が、当該登録情報DB3の管理対象とされる患者の検索を容易にするために、医療機関情報や提供元医療機関における患者の識別子などの検索用情報を記憶してもよい。患者のキー情報は、上記の例以外にも、前述の患者情報に含まれる患者(個人)を特定する情報や、そのような情報から生成されるHash値等であってもよい。なお、患者のキー情報は複数あってもよい。
 また、本実施形態では、ブロック管理情報としてブロックのHash値を用いる。
 なお、登録情報DB3は、患者のキー情報と対応づけて、当該患者の保管対象情報を記録した全てのブロックのブロック管理情報を記憶してもよい。例えば、登録情報DB3は、後述する承諾情報ブロックと診療記録ブロックの少なくとも2つのブロックのブロック管理情報を記憶してもよい。なお、登録情報DB3は、同じ患者について複数の診療機関等から診療記録の画像データが登録される場合には、2以上の診療記録ブロックのブロック管理情報を記憶してもよい。
 また、上述したように、登録情報DB3は、患者のキー情報と対応づけて、当該患者に関する非公開情報をさらに記憶してもよい。
 診療記録DB4は、医療機関から提供される診療記録の画像データを少なくとも記憶する。診療記録DB4は、例えば、医療機関から提供される患者の診療記録の属性情報を含む保管対象情報のうち所定の非公開情報を記憶してもよい。なお、診療記録の画像データは非公開情報に属する。
 保管対象情報とされる診療記録の属性情報は、例えば、該診療記録の対象とされた患者に関する情報である患者情報、作成元の医療機関に関する情報である医療機関情報、作成日時、病状に関する情報等である。なお、保管対象情報には、診療記録の画像データおよびその属性情報以外の情報、例えば、診療記録の提供に関する承諾書の画像データ等が含まれていてもよい。なお、データの秘匿性の観点から、診療記録DB4には、非公開情報のうち、患者(個人)を特定する情報を除いた非公開情報を記憶してもよい。その場合、診療記憶DB3は、例えば、患者(個人)を特定する情報に代えて、該情報のHash値等、照合時に情報の同一性を判定できる情報を記憶してもよい。
 診療記録の画像データ以外の非公開情報は、後述する登録情報DB3に記憶されてもよい。すなわち、非公開情報は、患者を特定可能な情報もしくは該情報と対応する情報とともに、周辺システムのいずれかの記憶装置に記憶されればよい。
 公開情報の例としては、医療機関情報や、患者情報のうち個人が特定されない情報(性別、生年月日、診断名、診療開始日、診療終了日、システムの利用許諾日、許諾対象)などが挙げられる。また、非公開情報の例としては、診療記録の画像データ、診療記録の提供に関する承諾書の画像データ、患者情報のうち作成元の医療機関以外の機関が患者(個人)を特定する情報(氏名と生年月日の組、保険証番号)などが挙げられる。
 なお、保管対象情報に含まれる個々の項目に対して、公開情報か非公開情報かを対象患者が設定できるようにしてもよい。
 診療記録DB4は、例えば、診療記録の画像データが登録されるごとに割り当てられる管理番号(以下、記録管理番号という)と、該診療記録の画像データと、存在すれば他の非公開情報とを対応づけて記憶する。記録管理番号は、診療記録の画像データが本システムに登録される任意の単位に対して固有の値を示す識別子であればよい。記録管理番号は、例えば、ある単位に対して、ランダムに割り当てられる値が好ましい。例えば、記録管理番号として、医療機関を識別する情報と、該医療機関において患者を識別する情報と、対象情報(診療記録の画像データ)を受け付けた日時等とを結合して得た情報のHash値を用いてもよい。このような記録管理番号を用いて診療記録の画像データを管理すれば、当該診療記録DB4内の情報から、対象患者の特定がされないようにできる。
 記録管理番号は、例えば、該記録管理番号が対応する画像データの要約ともにブロックに記録されてもよい。ここで、「要約」は、元の情報(本例では、非公開情報)に基づく情報であって、該情報が改ざんされた場合にそれを検知可能な情報であれば、特に限定されない。要約は、例えば、元の情報(上記の場合、画像データ)のHash値など、一方向関数により得られる情報であってもよい。ブロックチェーン22に周辺システムである診療記録DB4に記憶される画像データや非公開情報の要約をブロックチェーンに登録することにより、診療記録DB4に記憶される情報が改ざんされた場合にそれを検知できるようにするとともに、診療記憶DB3への情報の登録履歴をブロックチェーン上で保持することができる。
 また、診療記録DB4は、診療記録に対する秘匿性をさらに向上させるために、診療記録の画像データその他非公開情報を暗号化して記憶してもよい。
 診療記録管理装置1は、保管対象情報を登録、検索および参照するためのインタフェースをユーザに提供するとともに、ユーザからの要求に従って、保管対象情報を登録、検索、参照するための各種制御を実行する。図1に示すように、診療記録管理装置1は、患者登録部101と、診療記録登録部102と、登録情報照会部103と、診療記録提供部104を含んでいてもよい。
 患者登録部101は、医療機関からの要求に応じて、指定された患者の登録処理を行う。この登録処理で、患者登録部101は、例えば、当該登録にかかる保管対象情報として、要求元の医療機関の情報(医療機関情報)と、登録対象の患者情報とを少なくとも受信し、受信したそれらの情報を、ブロックチェーン22と診療記録DB4とに適宜登録した上で、患者情報を基に生成した当該患者のキー情報とブロック管理情報とを対応づけて登録情報DB3に記憶させる。
 なお、ブロックチェーンへの情報登録は、ブロックチェーン管理システム2が備えるいずれかの管理ノード21に、ブロックチェーン22に登録したい情報を渡してブロックの作成を依頼することにより行えばよい。
 患者登録部101は、例えば、受信した情報に非公開情報が含まれている場合には、受信した非公開情報に対して記録管理番号を割り当てて診療記録DB4に記憶させた上で、該記録管理番号と、公開情報と、非公開情報の要約とを含む承諾情報ブロックの作成を、管理ノード21に依頼してもよい。なお、受信した情報に非公開情報が含まれていない場合は、患者登録部101は、公開情報を含む承諾情報ブロックの作成を、管理ノード21に依頼すればよい。
 患者登録部101は、このような登録処理が完了すると、例えば、登録が完了した旨を要求元ユーザ(医療機関の端末等)に返信してもよい。患者登録部101は、このとき、患者のキー情報を併せて返信してもよい。
 診療記録登録部102は、医療機関からの要求に応じて、指定された患者の診療記録の画像データの登録処理を行う。この登録処理で、診療記録登録部102は、例えば、当該登録にかかる保管対象情報として、要求元の医療機関情報と、患者情報と、診療記録の画像データとを少なくとも受信し、受信したそれら情報を、ブロックチェーン22と診療記録DB4とに適宜登録した上で、患者情報を基に生成した当該患者のキー情報を基に、登録情報DB3に記憶されている患者管理情報に、今回ブロックチェーン22に登録したブロックのブロック管理情報を追記する。
 診療記録登録部102は、例えば、受信した診療記録の画像データその他の非公開情報に対して、記録管理番号を割り当てて診療記録DB4に記憶させるとともに、該記録管理番号と、公開情報と、非公開情報の要約とを含む診療記録ブロックの作成を、管理ノード21に依頼してもよい。なお、受信した情報に公開情報が含まれていない場合は、診療記録登録部102は、記録管理番号と、非公開情報の要約とを含む診療記録ブロックの作成を、管理ノード21に依頼すればよい。
 診療記録登録部102は、このような登録処理が完了すると、例えば、登録が完了した旨を要求元(医療機関の端末等)に返信してもよい。診療記録登録部102は、このとき、記録管理番号を併せて返信してもよい。
 登録情報照会部103は、医療機関や第三者機関からの要求に応じて、指定された患者や契約者(個人)に関する登録情報の照会を行う。この照会処理で、登録情報照会部103は、要求元のアクセス権限に基づいて、指定された患者または契約者個人に関する保管対象情報の登録有無や保管対象情報のリストなどの情報を提供する。
 診療記録提供部104は、医療機関や第三者機関からの要求に応じて、指定された患者や契約者(個人)に関する保管対象情報(特に、診療記録の画像データ)の提供を行う。この提供処理で、診療記録提供部104は、要求元のアクセス権限に基づいて、指定された患者または契約者個人に関する保管対象情報を提供する。
 また、図2は、管理ノード21の構成例を示すブロック図である。図2に示す管理ノード21は、データ受付部211と、ブロック生成部212と、ブロック共有部213と、情報記憶部214と、ブロック検証部215と、データ出力部216とを含む。
 データ受付部211は、外部ノードから、ブロックチェーン22に追加する情報を受け付ける。本実施形態では、データ受付部211は、ブロックチェーン22に追加する情報として、記録管理番号や公開情報や非公開情報の要約を受け付ける。
 ブロック生成部212は、データ受付部211が受け付けた情報を用いて、ブロックチェーンに追加するブロックを生成する。ブロック生成部212は、前ブロックに基づく情報と、データ受付部211が受け付けた情報とを含むブロックを生成する。また、ブロック生成部212は、自身が生成したブロックまたは後述するブロック共有部213を介して他の管理ノード21が生成したブロックに対して、所定のコンセンサス処理として、例えば、ノンスを探索する処理や署名を付与する処理を行った上で、自身が管理するブロックチェーン(ブロックチェーン22のコピーに相当)にブロックを追加する。なお、ブロック生成部212が生成したブロックに対して、複数の管理ノード21が所定のコンセンサス処理を行って得られたものが、最終的にブロックチェーン22に追加されるブロックとなる。
 ブロック共有部213は、ブロックチェーン管理システム2に属する管理ノード21間で情報交換を行う。ブロック共有部213は、より具体的には、データ受付部211が受け付けた情報や、ブロック生成部212が生成したブロックや、他の管理ノード21から受け付けたブロック等を、適宜他の管理ノード21に送信する。これにより、可能な限り全ての管理ノード21でこれらの情報および最新のブロックチェーン22を共有する。
 情報記憶部214は、ブロックチェーン22のコピーを記憶する。なお、情報記憶部214は、ブロックチェーン22のコピー以外にも、例えば、後述するブロック検証部215での検証処理に必要となる情報などを記憶してもよい。
 ブロック検証部215は、自身が保持するブロックチェーンにブロックを追加する際に、該ブロック内の検証を行う。例えば、ブロック検証部215は、追加するブロックが実際に規則を満たしているか、ブロックを作成したノードと署名が一致するか、追加するブロックに含まれる前ブロックに基づく情報が実際の前ブロックから生成した情報と一致するかなどを検証してもよい。
 データ出力部216は、外部ノードからの要求に応じて、自身が保持するブロックチェーン22の中から所望の情報を含むブロックを検索して出力する。
 なお、図2の構成はあくまで一例であって、管理ノード21は、改ざんが困難なブロックチェーン22を複数のノードが共有して管理するための所定のコンセンサス処理を実行可能であり、外部ノードからの要求に応じて台帳への情報追加および台帳の参照が可能なノードであれば、具体的な構成は問わない。
 また、図1には、診療記録管理装置1と管理ノード21とを別々のものとして示しているが、診療記録管理装置1が管理ノード21の機能を有していてもよい。
 図3は、本発明の実施形態のデータの流れの概略を示す説明図である。なお、図3では、承諾情報として、承諾書の画像データ、患者情報、医療機関情報などを示しているが、承諾情報はこれらに限定されない。
 図3に示す例では、医療機関等が、まずシステム登録承諾をとった患者情報や医療期間情報を含む承諾情報を本システムに登録する。システムは、承諾情報のうち非公開情報と、該患者のキー情報とを対応づけて登録情報DB3に記憶するとともに、承諾情報のうち公開情報と、非公開情報のHash値(図中のHash X)とを含む承諾情報ブロック(図中のブロックi)を作成し、ブロックチェーン22に追加する。また、システムは、追加した承諾情報ブロックのHash値(図中のHash i)を、ブロック管理情報として、該患者のキー情報と対応づけて登録情報DB3に記憶する。
 次いで、システム登録承諾をとった患者の診察終了から5年を経過後、医療機関が、保管義務のなくなった当該患者の診療記録の画像データを本システムに登録する。システムは、診療記録DB4に、診療記録の画像データと記録管理番号とを対応づけて記憶するとともに、記録管理番号と診療記録の画像データのHash値(図中のHash Y)とを含む診療記録ブロック(図中のブロックn)を作成し、ブロックチェーン22に追加する。
 また、システムは、追加した診療記録ブロックのHash値(図中のHash n)を、ブロック管理情報として、該患者のキー情報と対応づけて登録情報DB3に記憶する。このとき、すでに記憶されているブロック管理情報があれば、新たなブロック管理情報を追記して、2以上のブロック管理情報を保持するようにしてもよい。なお、すでに記憶されているブロック管理情報を上書きする場合、システムは、すでに記憶されているブロック管理情報(上書き前のブロック管理情報)を診療記録ブロックに含ませる。
 なお、医療機関から診療記録の画像データとともに、新たな公開情報が提供された場合、システムは、該公開情報を診療記録ブロックに含ませてブロックチェーン22に登録すればよい。また、医療機関から診療記録の画像データとともに、新たな非公開情報が提供された場合、システムは、当該非公開情報を、診療記録の画像データと同様に、診療記録DB4に記憶するとともに、そのHash値を診療記録ブロックに含ませてブロックチェーン22に登録すればよい。
 また、医療機関から提供される診療記録の画像データには、保管義務期間中の診療記録の画像データが含まれていてもよい。すなわち、本システムが保管対象とする診療記録の画像データは、保管義務のなくなったものに限定されない。
 既に説明したように、各ブロックは、時系列に繋がっており、前ブロックに基づく値を保持している。例えば、ブロックnは、ブロックn-1のHash値であるブロックHash n-1を保持する。同様に、ブロックn+1は、ブロックnのHash値であるブロックHash nを保持する。したがって、ブロックの内容を改ざんするには、後続ブロックを全て作成し直す必要があり、このようなブロックチェーンの性質より、ブロックチェーン内のデータを改ざんすることは困難とされている。
 また、図4は、ブロックチェーン22、登録情報DB3および診療記録DB4に記憶される情報のデータ構造の例を示す説明図である。診療記録管理システム10が用いるブロックには、承諾情報ブロックと、診療記録ブロックの2種類があるが、本例では両ブロックについて同じデータ構造を用いる。
 診療記録管理システム10が用いるブロックは、例えば、ヘッダ部D21と、データ部D22とを含んでいてもよい。ヘッダ部D21は、前ブロック管理情報D211を含む。また、データ部D22は、管理番号D221と、公開情報D222と、非公開情報管理情報D223とを含んでいてもよい。
 前ブロック管理情報D211は、前ブロックに基づく情報であって、前ブロックのデータが改ざんされた場合にそれを検知できるような情報であればよい。前ブロック管理情報D211の例としては、前ブロックのHash値等が挙げられる。
 管理番号D221は、当該ブロックに記憶されているデータを識別するための情報である。管理番号D221の例としては、診療記録ブロックであれば記録管理番号、承諾情報ブロックであればキー情報やキー情報から生成される第2のキー情報が挙げられる。なお、承諾情報ブロックの管理番号D221は省略されてもよい。
 公開情報D222は、医療機関から提供される保管対象情報のうちの公開情報である。なお、公開情報D222は、当該ブロックを生成することとなった保管対象情報の提供において、該保管対象情報に公開情報が含まれていない場合は、省略されてもよい。
 非公開情報管理情報D223は、医療機関から提供される保管対象情報のうちの非公開情報に基づく情報であって、当該非公開情報が改ざんされた場合にそれを検知できるような情報であればよい。非公開情報管理情報D223の例としては、対象とされる非公開情報のHash値等が挙げられる。なお、非公開情報管理情報D223は、当該ブロックを生成することとなった保管対象情報の提供において、該保管対象情報に非公開情報が含まれていない場合は、省略されてもよい。
 なお、図示省略しているが、データ部D22は、当該ブロックより前にブロックチェーン22に登録されている、当該患者に関する情報が記憶されたブロックのブロック管理情報をさらに含んでいてもよい。
 また、図4に示すように、登録情報DB3は、医療機関から診療記録が提供される患者ごとに、患者管理情報として、例えば、キー情報D31と、非公開情報D32と、ブロック管理情報D33とを記憶してもよい。
 キー情報D31は、上述した患者のキー情報である。
 非公開情報D32は、診療記録の画像データ以外の患者の非公開情報である。なお、非公開情報D32は省略されてもよい。なお、診療記録の画像データは、後述するように、診療記録DB4に記憶される。
 ブロック管理情報D33は、患者の公開情報および/または非公開情報の要約を含むブロックのブロック管理情報である。
 また、図4に示すように、診療記録DB4は、医療機関から診療記録の画像データが提供されるごとに、診療記録情報として、例えば、記録管理番号D41と、診療記録画像データD42とを記憶してもよい。
 記録管理番号D41は、上述した記録管理番号である。
 診療記録画像データD42は、提供された診療記録の画像データである。
 なお、図示省略しているが、診療記録DB4は、診療記録情報として、診療記録画像データD42と併せて、または診療記録画像データD42に代えて、患者の非公開情報をさらに記憶してもよい。
 次に、図5を用いて、診療記録管理システム10の患者の登録、診療記録の登録、登録情報の照会および診療記録の参照の各段階のフローの一例を説明する。図5(a)は、診療記録管理システム10に患者を登録するフェーズのフロー例である。図5(a)に示す例では、医療機関が、診療記録のシステム登録を承諾した患者の患者情報、医療機関情報および承諾書の画像データを含む承諾情報を、診療記録管理システム10に登録する。これにより、例えば、承諾情報のうちの公開情報と非公開情報の要約とを含む承諾情報ブロックがブロックチェーン22に登録されるとともに、患者情報等から生成された当該患者のキー情報と、承諾情報のうちの非公開情報と、該承諾情報ブロックのHash値(ブロック管理情報)とが対応づけられて登録情報DB3に記憶される。
 図5(b)は、診療記録管理システム10に承諾を得た患者の診療記録の画像データを登録するフェーズのフロー例である。図5(b)に示す例では、医療機関が、診療記録のシステム登録を承諾した患者の診療記録の画像データを、診療記録管理システム10に登録する。このとき、医療機関は、診療記録の画像データとともに、患者を特定する情報と自身の医療機関情報を診療記録管理システム10に入力し、当該患者に関し登録されている情報を照会した上で、診療記録の画像データの登録を行う。これにより、例えば、承諾を得た患者の診療記録の画像データが、当該画像データに割り当てられた記録管理番号とともに診療記録DB4に登録される。また、該画像データの要約と記録管理番号とを含む診療記録ブロックがブロックチェーン22に登録されるとともに、当該患者のキー情報と、該診療記録ブロックのHash値(ブロック管理情報)とが対応づけられて登録情報DB3に記憶(追記)される。
 図5(c)は、診療記録管理システム10に登録された情報を照会する登録情報照会フェーズのフロー例である。図5(c)に示す例では、医療機関または契約者等から承諾を得た保険会社等の第三者機関が、許可された患者または契約者に関し登録されている情報を診療記録管理システム10に照会する。医療機関または第三者機関は、例えば、患者(個人)を特定可能な情報を指定して、診療記録管理システム10に照会依頼を行う。診療記録管理システム10は、指定された情報を基に、患者を特定して登録情報DB3の患者管理情報と照会した上で、患者管理情報に含まれる情報や該情報を基に取得可能な情報を、要求元の機関に対し許可された範囲内で提供する。これにより、医療機関または第三者機関は、自身に許可された範囲内で、指定した個人の診療記録の当該システムへの登録有無などを知ることができる。患者(個人)を特定可能な情報の例としては、患者の生年月日と氏名の組、医療機関の識別情報と当該医療機関における患者の識別情報の組、診療記録管理システム10が割り当てた患者のキー情報、他のシステム(行政等)が割り当てた個人を特定可能な情報(保険証番号)などが挙げられる。
 図5(d)は、診療記録管理システム10に登録された診療記録を参照するフェーズのフロー例である。図5(d)に示す例では、医療機関または契約者等から承諾を得た保険会社等の第三者機関が、診療記録管理システム10に登録されている診療記憶の画像データの中から、許可された患者または契約者の診療記録の画像データを参照する。医療機関または第三者機関は、例えば、患者(個人)を特定可能な情報および参照する診療記録を特定可能な情報を指定して、診療記録管理システム10に参照依頼を行う。診療記録管理システム10は、指定された情報を基に、患者および診療記録を特定して、要求元の機関に対し許可された範囲内で情報を提供する。これにより、医療機関または第三者機関は、自身に許可された範囲内で、指定した個人の診療記録の画像データを参照することができる。診療記録を特定可能な情報の例としては、登録情報照会フェーズで得た記録管理番号が挙げられる。なお、診療記録を特定可能な情報に代えて、診療日時や期間など、絞り込み条件を指定することも可能である。
 次に、診療記録管理システム10の動作を説明する。図6~図9は、診療記録管理システム10の動作の一例を示すシーケンス図である。各図において、患者登録機能、診療記録登録機能、照会機能および提供機能はそれぞれ、診療記録管理装置1の患者登録部101、診療記録登録部102、登録情報照会部103および診療記録提供部104を表す。また、図中のユーザは、各々のユーザが操作するユーザ端末を表す。
 まず、図6を参照して、診療記録管理システム10における患者登録動作を説明する。当該動作におけるユーザは、登録対象とする患者の受診先すなわち当該患者の診療記録を作成する医療機関を想定している。図6に示す例では、まず、承諾情報として患者情報と医療機関情報とを含む承諾登録要求を、診療記録管理装置1の患者登録部101に送信する(ステップS101)。ユーザは、例えば、診療記録管理装置1が提供するWebページ等を介して、まず診療記録管理装置1に患者の登録を要求する承諾登録録要求を送信し、その返信として受信する情報入力要求に従って患者情報や医療機関情報と、存在すれば承諾書の画像データや承諾内容等とを入力してもよい。
 承諾情報を受信した患者登録部101は、受信した情報を基に、患者のキー情報を生成する(ステップS102)。また、患者登録部101は、受信した情報に含まれる保管対象とされる非公開情報について、そのHash値を計算する(ステップS103)。そして、患者登録部101は、ブロックチェーン22に登録する内容(承諾情報ブロックのデータ部D22)を作成する(ステップS104)。ステップS104では、患者登録部101は、管理番号D221、公開情報D222または非公開情報管理情報D223を少なくとも含むデータ部D22を作成する。そして、作成したデータ部D22を含むブロック追加要求をブロックチェーン管理システム2のいずれかの管理ノード21に送信する(ステップS105)。
 ブロック追加要求を受信した管理ノード21は、受信したデータ部D22と、自身が管理しているブロックチェーン22の情報とを基に作成したヘッダ部D21とを少なくとも含むブロックを生成する(ステップS106)。そして、ブロックチェーン管理システム2の管理ノード21の各々が、所定のコンセンサス処理を実行し、生成したブロックを台帳に追加する(ステップS107)。また、ブロック追加要求を受信した管理ノード21は、要求されたデータ部D22が記録されたブロックが正常に追加されたことを受けて、追加されたブロックのHash値であるブロックHashを、要求元の患者登録部101に送信する(ステップS108)。
 患者登録部101は、ブロックHashを受信すると、該ブロックHashをブロック管理情報とし、ステップS102で生成した患者のキー情報と、該ブロック管理情報と、承諾情報に含まれる非公開情報とを対応づけて、登録情報DB3に記録させる(ステップS109)。なお、承諾情報に保持対象とする非公開情報が含まれていなければ、上記の非公開情報は省略される。
 具体的には、患者登録部101は、患者のキー情報と、ブロック管理情報としてのブロックHashと、承諾情報に保持対象とする非公開情報があれば該非公開情報とを含むDB登録要求を登録情報DB3に送信する。登録情報DB3は、受信したDB登録要求に含まれる情報が記録された新たなレコードを作成し、記憶する(ステップS110)。
 患者登録部101は、登録情報DB3から登録が完了した旨を受信すると(ステップS111)、要求元ユーザに、登録完了を通知して処理を終了する(ステップS112)。
 次に、図7を参照して、診療記録管理システム10における登録情報照会動作を説明する。当該動作におけるユーザは、照会対象とする患者の診療記録の作成元の医療機関や、診療記録の作成元以外の医療機関や、第三者機関を想定している。
 図7に示す例では、まずユーザが、ユーザ情報として自身の機関を示す機関情報と、患者を特定する情報とを含む登録情報照会要求を、診療記録管理装置1の登録情報照会部103に送信する(ステップS201)。ユーザは、例えば、診療記録管理装置1が提供するWebページ等を介して、診療記録管理装置1に患者の照会を要求する登録情報照会要求を送信し、その返信として受信する情報入力要求に従ってユーザ情報(機関情報)と、患者を特定する情報とを入力してもよい。
 患者を特定する情報の例としては、患者の氏名や生年月日や医療機関における患者の識別子などの承諾情報に含まれる情報や、該情報から生成したキー情報などが挙げられる。例えば、ユーザである医療機関が自身の患者を特定する場合、患者を特定する情報として、医療機関情報と該医療機関における患者の識別情報の組を入力してもよい。また、ユーザである医療機関が自身以外の医療機関の患者を特定する場合、患者を特定する情報として、その患者の受診先の医療機関情報と該医療機関における患者の識別情報の組や、その患者を個人として特定可能な情報(氏名と生年月日の組、保険証番号等)を入力してもよい。また、ユーザである第三者機関が、患者(契約者)を特定する場合、患者を特定する情報として、その患者を個人として特定可能な情報(氏名と生年月日の組、保険証番号等)を入力してもよい。
 ユーザ情報と患者を特定する情報とを受信した登録情報照会部103は、受信した情報を基に、ユーザが該患者の登録情報にアクセス可能な否かを判定する権限チェックを行う(ステップS202)。なお、権限チェックの詳細は後述する。
 権限チェックの結果、ユーザが該患者の登録情報にアクセス不可であると判定された場合、登録情報照会部103は、要求元ユーザにその旨を返信して当該処理を終了する(ステップS203)。
 一方、権限チェックの結果、ユーザが該患者の登録情報にアクセス可能であると判定された場合、登録情報照会部103は、患者のキー情報を取得し、取得した患者のキー情報を基に、登録情報DB3を参照(検索)する(ステップS204~ステップS207)。より具体的には、登録情報照会部103は、受信した情報を基に患者のキー情報を取得した上で、患者のキー情報を含むDB検索要求を登録情報DB3に送信する(ステップS204、ステップS205)。登録情報DB3は、DB検索要求に含まれる情報に基づき、記録媒体に記録したデータを検索する(ステップS206)。
 本例では、指定されたキー情報を含む患者管理情報が登録情報DB3に登録されており、そのレコードが登録情報DB3から登録情報照会部103に返信される(ステップS207)。なお、登録情報DB3に該当するレコードが登録されていない場合、登録情報照会部103は、その旨を要求元ユーザに返信する(ステップS208)。
 登録情報照会部103は、登録情報DB3から該当レコードを受信すると、レコードに含まれるブロック管理情報を取得する(ステップS209)。そして、登録情報照会部103は、取得したブロック管理情報を基に当該患者の承諾情報ブロックや診療記録ブロックを検索する。より具体的には、登録情報照会部103は、ステップS209で取得したブロック管理情報を含むブロックデータ要求をブロックチェーン管理システム2のいずれかの管理ノード21に送信する(ステップS210)。
 ブロックデータ要求を受信した管理ノード21は、自身が管理しているブロックチェーン22から該当するブロックを検索して、該ブロックのデータ部を返信する(ステップS211、ステップS212)。
 該当するブロックのデータ部を受信した登録情報照会部103は、受信したデータ部に記録されたデータに対するユーザのアクセス権限チェックを行い(ステップS213)、要求元ユーザに許可された範囲内で、取得した情報を提供する(ステップS214)。
 なお、登録情報照会部103は、指定した患者が複数の医療機関を受診していた場合など、複数の患者管理情報のレコードが存在した場合や1つのレコード内に複数のブロックのブロック管理情報が登録された場合には、ブロック管理情報の数分、ステップS209~ステップS213の動作を行った上で、情報提供を行ってもよい。
 ステップS214で提供される情報の例としては、システム登録の有無、存在すれば診療記録ブロックのデータ部に含まれる管理番号D221および公開情報D222の一覧などが挙げられる。さらに、ユーザによっては、登録情報DB3に記憶されている非公開情報D32やキー情報D31やキー情報D31の生成に用いる患者情報なども挙げられる。
 次に、図8を参照して、診療記録管理システム10における診療記録登録動作を説明する。当該動作におけるユーザは、登録対象とする診療記録の作成元の医療機関を想定している。
 図8に示す例では、まずユーザが、ユーザ情報として自身の機関を示す機関情報と、患者を特定する情報とを含む登録情報照会要求を、診療記録管理装置1の登録情報照会部103に送信する(ステップS301)。なお、患者を特定する情報は省略してもよい。その場合、システムは、ユーザが過去に承諾登録を行った患者全てが指定されたものとして動作すればよい。
 ユーザ情報と患者を特定する情報とを受信した登録情報照会部103は、登録情報照会処理を行う(ステップS302)。当該登録情報照会処理は、図7に示したステップS202~ステップS213の動作と同様でよい。なお、当該登録情報照会処理において、登録情報照会部103は、受信した情報を基に、指定された患者のキー情報を生成または取得して、指定された患者について、登録情報DB3に登録されている患者管理情報と、ブロックチェーン22に登録されている承諾情報ブロックのデータ部とを少なくとも取得する。
 なお、患者を特定する情報が省略された場合、登録情報照会部103は、患者のキー情報に代えて医療機関情報としてユーザ情報を指定して登録情報DB3にDB検索要求を行い、医療機関情報が一致するレコードを取得すればよい。そして、取得したレコードの各々について当該レコードに含まれるブロック管理情報を基に、承諾情報ブロックのデータ部を取得すればよい。
 患者管理情報と承諾情報ブロックのデータ部とを少なくとも取得すると、登録情報照会部103は、要求元ユーザに許可された範囲内で、取得した情報を提供する(ステップS303)。本例では、患者からの承諾を得て診療記録を登録する正規のユーザ(受診先の医療機関)に対して、指定された患者の診療記録の登録状況やキー情報D31や該キー情報D31の生成に用いる患者情報や登録済みの診療記録の属性情報(医療機関、診療日、記録管理番号)等が提供される。
 次に、ユーザは、患者を特定する情報としてステップS303で取得したキー情報や患者情報等と、診療記録の画像データとを含む診療記録登録要求を、診療記録管理装置1の診療記録登録部102に送信する(ステップS304)。ユーザは、例えば、登録情報を照会する際にアクセスしたWebページ上において、登録情報照会要求の結果を取得した後、同Webページ上において取得した情報の中から患者を指定して診療記録の登録要求を送信し、その返信として受信する情報入力要求に従って診療記録の画像データを入力してもよい。
 なお、本例では、同Webページ等を介して、登録情報照会部103から診療記録登録部102へ、登録情報照会部103が照会したデータを参照するためのリストである照会データ参照リストが提供されるものとする。照会データ参照リストは、例えば、照会要求時の情報であるユーザ情報(機関情報)および患者を特定する情報と、それに対して提供した情報であるキー情報および/または患者情報と、存在すれば当該患者の診療記録の記録管理番号とその記録管理番号を含むブロックのブロックHashとを含む情報であってもよい。なお、照会データ参照リストは、ユーザが患者や診療記録を指定するための情報(患者情報や記録管理番号)と、指定された患者や診療記録の情報にアクセスするための情報(キー情報やブロックHash等)とが含まれていることが好ましい。なお、これらの情報の他に、ユーザに提供した情報(ブロック内の公開情報等)を含んでいてもよい。
 ユーザから患者を特定する情報と診療記録の画像データとを受信した診療記録登録部102は、受信した情報およびユーザ情報を基に、承諾チェックを行う(ステップS305)。承諾チェックでは、例えば、要求元ユーザである医療機関と対応づけられて指定された患者の承諾情報ブロックがブロックチェーン22に登録されているかや、当該承諾情報ブロックおよび該承諾情報ブロックにHash値を記憶した非公開情報が改ざんされていないか等を確認する。診療記録登録部102は、例えば、承諾情報ブロックがブロックチェーン22に登録されており、当該承諾情報ブロックおよび該承諾情報ブロックにHash値を記憶した非公開情報が改ざんされていないと判定された場合には、承諾がされていると判断する。
 承諾がされている場合、診療記録登録部102は、受信した診療記録の画像データに割り当てる記録管理番号を採択する(ステップS306)。また、診療記録登録部102は、受信した診療記録の画像データ(非公開情報)について、そのHash値を計算する(ステップS307)。なお、診療記録登録部102は、診療記録の画像データの他に非公開情報を受信した場合、該非公開情報についてもHash値を計算すればよい。
 そして、診療記録登録部102は、ブロックチェーン22に登録する内容(診療記録ブロックのデータ部D22)を作成する(ステップS308)。ステップS308では、診療記録登録部102は、管理番号D221として記録管理番号と、非公開情報管理情報D223として診療記録の画像データのHash値とを少なくとも含むデータ部D22を作成する。なお、診療記録登録部102は、ステップS304で受信した情報に、診療記録の画僧データ以外の非公開情報が含まれている場合には、非公開情報管理情報D223に、該非公開情報のHash値も含ませる。
 次いで、診療記録登録部102は、作成したデータ部D22を含む診療記録ブロックをブロックチェーン22に追加するブロック追加処理を行う(ステップS309)。ブロック追加処理は、図6に示したステップS105~ステップS108の動作と同様でよい。
 ブロック追加処理の結果、診療記録登録部102は、ブロックHashを管理ノード21から受信すると、登録情報DB3に、受信したブロックHashをブロック管理情報として、患者のキー情報に対応づけて登録する。より具体的には、診療記録登録部102は、キー情報と、取得したブロックHashとを含むDB更新要求を登録情報DB3に送信し、登録情報DB3の患者管理情報のうち、キー情報が合致するレコードにおけるブロック管理情報D33を更新(追記)する(ステップS310、ステップS311)。
 診療記録登録部102は、登録情報DB3から更新が完了した旨を受信すると(ステップS312)、診療記録DB4に、ステップS306で取得した記録管理番号と、ユーザから受信した診療記録の画像データとを対応づけて登録する。このとき、受信した情報に他の非公開情報があれば、該非公開情報も併せて登録する。診療記録登録部102は、記録管理番号と、診療記録の画像データとを少なくとも含むDB登録要求を診療記録DB4に送信し、診療記録DB4に、新たなレコード(診療記録情報)を登録する(ステップS313、ステップS314)。
 最後に、診療記録登録部102は、診療記録DB4から登録が完了した旨を受信すると(ステップS315)、要求元ユーザに、登録完了を通知して処理を終了する(ステップS315)。
 なお、図8の例において、診療記録登録部102は、ブロックチェーン22に診療記録ブロックを追加した後に、診療記録DB4に診療記録の画像データを登録しているが、例えば、診療記録DB4に診療記録の画像データを登録した後で、ブロックチェーン22に診療記録ブロックを追加してもよい。
 一方、承諾チェックの結果、承諾がされていない場合には、診療記録登録部102は、診療記録の登録は受け付けられない旨を要求元ユーザに返信して処理を終了する。
 次に、図9を参照して、診療記録管理システム10における診療記録参照動作を説明する。当該動作におけるユーザは、照会対象とする診療記録の作成元の医療機関や、診療記録の作成元以外の医療機関や、第三者機関を想定している。
 図9に示す例では、まずユーザが、ユーザ情報と患者を特定する情報とを含む登録情報照会要求を診療記録管理装置1の登録情報照会部103に送信する(ステップS401)。
 ユーザ情報と患者を特定する情報とを受信した登録情報照会部103は、指定された患者の登録情報を照会する登録情報照会処理を行う(ステップS402)。当該登録情報照会処理は、図8のステップS302の動作すなわち図7のステップS202~ステップS213の動作と同様でよい。なお、患者を特定する情報が省略された場合も同様である。
 登録情報照会処理で、指定された患者の患者管理情報と承諾情報ブロックのデータ部とを少なくとも取得すると、登録情報照会部103は、要求元ユーザに許可された範囲内で、取得した情報を提供する(ステップS403)。本例では、患者や契約者からの承諾を得て診療記録を参照する正規のユーザ(受診先の医療機関、参照権限のある他の医療機関、開示の同意がされた第三者機関等)に対して、指定された患者の診療記録の登録状況やキー情報D31や該キー情報D31の生成に用いる患者情報や登録済みの診療記録の属性情報(医療機関、診療日、記録管理番号)等が提供される。
 次に、ユーザは、参照する診療記録の画像データを特定する情報としてステップS403で取得した記録管理番号等を含む診療記録参照要求を、診療記録管理装置1の診療記録提供部104に送信する(ステップS404)。ユーザは、例えば、登録情報を照会する際にアクセスしたWebページ上において、登録情報照会要求の結果を取得した後、同Webページ上において取得した情報の中から参照したい診療記録を指定して診療記録の参照要求を送信してもよい。
 なお、本例でも、同Webページ等を介して、登録情報照会部103から診療記録提供部104へ、登録情報照会部103が照会したデータを参照するためのリストである照会データ参照リストが提供されるものとする。
 ユーザから記録管理番号や診療記録ブロックのブロックHashなどの診療記録を特定する情報を受信した診療記録提供部104は、受信した情報およびユーザ情報を基に、権限チェックを行う(ステップS405)。
 権限チェックの結果、ユーザが該患者の登録情報にアクセス可能であると判定された場合、診療記録提供部104は、記録管理番号を含むDB検索要求を診療記録DB4に送信する(ステップS406)。このとき、診療記録提供部104は、診療記録を特定する情報としてユーザから診療記録ブロックのブロックHashを受信した場合、ブロックチェーン管理システム2に要求または照会データリストを参照して、該当するブロックのデータ部に含まれる記録管理番号を取得すればよい。
 記録管理DB4は、DB検索要求に含まれる情報に基づき、記録媒体に記録したデータを検索する(ステップS407)。
 本例では、指定された記録管理番号を含む診療記録情報が診療記録DB4に登録されており、そのレコードが診療記録DB4から診療記録提供部104に返信される(ステップS408)。
 また、診療記録提供部104は、指定された診療記録の記録管理番号を含む診療記録ブロックのデータ部が未取得であれば、該診療記録ブロックのデータ部を取得する(ステップS409)。ブロックデータ取得処理は、図7に示したステップS210~ステップS212の動作と同様でよい。
 次いで、診療記録提供部104は、ユーザから指定された診療記録の記録管理番号を含むデータ部に含まれる非公開情報管理情報D223が示すHash値と、ステップS408で受信したレコードに含まれる非公開情報(診療記録の画像データ)から生成したHash値とを照合する(ステップS410)。Hash値が一致した場合、該非公開情報は改ざんされていないとして、該非公開情報を要求元ユーザに送信する(ステップS411)。
 なお、診療記録提供部104は、ユーザから指定された診療記録が複数あった場合、指定された診療記録の数分、ステップS405~ステップS411の動作を行えばよい。
 なお、図8や図9では、ユーザが登録情報照会要求を行った上で、その結果得られた情報に基づき、診療記録登録要求や診療記録参照要求を行う例を示したが、ユーザは、1回の要求で、診療記録の登録や診療記録の参照を行うことも可能である。
 例えば、ユーザは、ユーザ情報と患者を特定する情報と診療記録の画像データとを含む診療記録登録要求を診療記録登録部102に送信してもよい。その場合、診療記録登録部102は、受信した情報を基に、登録情報照会部103に登録情報の照会を依頼し、指定された患者の登録情報を得た上で、上記の診療記録登録処理を行えばよい。
 また、例えば、ユーザは、ユーザ情報と患者を特定する情報と取得範囲(日時や条件等)とを含む診療記録参照要求を診療記録提供部104に送信してもよい。その場合、診療記録提供部104は、受信した情報を基に、登録情報照会部103に登録情報の照会を依頼し、指定された患者の登録情報を得た上で、取得範囲に基づき提供する診療記録を特定して、上記の診療記録提供処理を行えばよい。
 また、図10は、診療記録管理システム10における権限チェックの例を示す説明図である。診療記録管理システム10(特に、登録情報照会部103、診療記録提供部104)は、図10に示すような条件に従い、要求元ユーザのアクセス権限を確認してもよい。すなわち、診療記録管理システム10は、まず要求元ユーザがサービス加入者か否かを判定する。サービス加入者でなければ、該ユーザは照会先の情報に対してアクセス権がないものとする。一方、サービス加入者であれば、さらにユーザの機関が医療機関かそれ以外(第三者機関)かを判定する。
 ユーザの機関が医療機関であれば、さらに照会先の情報がユーザ(医療機関)の患者または診療記録かどうかを判定する。照会先の情報がユーザ(医療機関)の患者の情報または診療記録であれば、該ユーザは照会先の情報に対してアクセス権があるものとする。
 一方、照会先の情報がユーザ(医療機関)の患者または診療記録でなければ、さらにユーザに対して参照権限が設定されているか否かを判定する。参照権限は、例えば、照会先として指定した患者の受診先または照会先として指定した診療記録の作成元の医療機関や参照したいユーザ(医療機関)自身や患者自身が、開示先として該ユーザ(医療機関)を指定した紹介状または承諾書などを本システム(登録情報DB3)に登録することにより設定できる。ユーザに対してこのような参照権限が設定されている場合、該ユーザは照会先の情報に対してアクセス権があるものとする。一方、参照権限が設定されていなければ、該ユーザは照会先の情報に対してアクセス権がないものとする。
 また、ユーザの機関が医療機関以外の第三者機関であれば、さらに照会先の情報が契約者の情報でありかつ開示同意書があるか否かを判定する。照会先の情報がユーザ(第三者機関)の契約者の情報であり、かつ開示同意書があれば、該ユーザは照会先の情報に対してアクセス権があるものとする。なお、照会先の情報が契約者の情報であるか否かや開示同意書があるか否かは、例えば、本システムに対して個人を指定した契約者の設定や参照権限を設定できるようにし、それらの設定と患者管理情報とを対応づけることにより、判定できる。
 一方、照会先の情報がユーザ(第三者機関)の契約者の情報でないまたは開示同意書がない場合、該ユーザは照会先の情報に対してアクセス権がないものとする
 以上のように、本実施形態によれば、第三者機関は、患者から開示が許された範囲内で医療機関が登録した診療記録が照会可能になるので、今まで破棄されていたような診療記録をも得ることができる。また、得た情報を利用して、医療機関に問い合わせることも可能である。このため、第三者機関が保険会社であれば、調査コストが減り、かつ精度が向上したり、不正な給付金の支払いを抑制できるといった利益を得ることができる。
 また、医療機関は、診療記録の保存にかかる負担を低減できる。このため、例えば、費用面から破棄せざるを得なかった診療記録を破棄しないですむ。また、診療記録が長期にわたり保管されていれば、患者から古い診療記録の照会要求があった場合にも対応できる。例えば、閉院後の医療訴訟等に備えることもできる。
 また、第三者機関と医療機関とをつなげることにより、各機関におけるサービスの質向上やリスク軽減を図ることができる。
 なお、図11は、本実施形態の診療記録管理装置1の他の例を示すブロック図である。図11に示すように、診療記録管理装置1は、さらに課金部105を備えていてもよい。課金部105は、ユーザが本システムを利用した際に、ユーザおよび利用内容に応じて、ユーザに対して課金を行う。
 課金部105は、ユーザが医療機関であれば、診療記録の登録および他の医療機関が登録した診療記録の参照に対してのみ課金を行ってもよい。この場合、自身が登録した診療記録の参照については無料とされる。また、課金部105は、ユーザが第三者機関であれば、利用料として、一定の年会費に加えて、登録情報の照会および診療記録の参照に対して、従量課金を行ってもよい。例えば、本システムが提供した情報の量や提供回数や照会回数などといった本システムの利用量に応じた課金を行ってもよい。また、課金部105は、情報が保管されていた期間に応じた課金を行うことも可能である。
 このような課金制を組み込むことにより、長期間にわたりシステムの維持費などを確保できる仕組みを実現できる。
 また、図12は、本実施形態の診療記録管理装置1の他の例を示すブロック図である。図12に示すように、診療記録管理装置1は、さらに権限判定部106を備えていてもよい。権限判定部106は、登録情報照会部103や診療記録提供部104からの要求を受けて、要求元ユーザに対して指定された患者または診療記録に関する情報へのアクセス権の有無を判定する。
 なお、図12に示すように、診療記録管理装置1は、登録部11と提供部12と課金部105とを備え、登録部11が、患者登録部101と診療記録登録部102とを含み、提供部12が、登録情報照会部103と診療記録提供部104と権限判定部106とを含む構成であってもよい。
 次に、本発明の実施形態にかかるコンピュータの構成例を示す。図13は、本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。コンピュータ1000は、CPU1001と、主記憶装置1002と、補助記憶装置1003と、インタフェース1004と、ディスプレイ装置1005と、入力装置1006とを備える。
 上述の診療記録管理システムの各装置(ノードを含む)は、例えば、コンピュータ1000に実装されてもよい。その場合、各装置の動作は、プログラムの形式で補助記憶装置1003に記憶されていてもよい。CPU1001は、プログラムを補助記憶装置1003から読み出して主記憶装置1002に展開し、そのプログラムに従って上記の実施形態における所定の処理を実施する。
 補助記憶装置1003は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例として、インタフェース1004を介して接続される磁気ディスク、光磁気ディスク、CD-ROM、DVD-ROM、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ1000に配信される場合、配信を受けたコンピュータは1000がそのプログラムを主記憶装置1002に展開し、上記の実施形態における所定の処理を実行してもよい。
 また、プログラムは、各実施形態における所定の処理の一部を実現するためのものであってもよい。さらに、プログラムは、補助記憶装置1003に既に記憶されている他のプログラムとの組み合わせで上記の実施形態における所定の処理を実現する差分プログラムであってもよい。
 インタフェース1004は、他の装置との間で情報の送受信を行う。また、ディスプレイ装置1005は、ユーザに情報を提示する。また、入力装置1006は、ユーザからの情報の入力を受け付ける。
 また、実施形態における処理内容によっては、コンピュータ1000の一部の要素は省略可能である。例えば、装置がユーザに情報を提示しないのであれば、ディスプレイ装置1005は省略可能である。
 また、各装置の各構成要素の一部または全部は、汎用または専用の回路(Circuitry)、プロセッサ等やこれらの組み合わせによって実施される。これらは単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
 各装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
 次に、本発明の概要を説明する。図14は、本発明の診療記録管理装置の概要を示すブロック図である。図14に示すように、本発明の診療記録管理装置6は、登録手段601と、提供手段602とを備えることを特徴とする。
 登録手段601(例えば、登録部11、特に診療記録登録部102)は、医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段(例えば、診療記憶DB4)に、診療記録を識別する記録識別情報(例えば、記録管理番号)と、画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーン(例えば、ブロックチェーン22)に、記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段(例えば、登録情報DB3)に、患者を識別する患者識別情報(例えば、患者のキー情報)と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する。
 また、提供手段602(例えば、提供部12、特に診療記録提供部104)は、医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する。
 ここで、患者識別情報には、診療記録の作成元の医療機関以外の機関が医療機関の患者を特定可能な情報である第1の患者特定情報(例えば、個人を特定する情報)または第1の患者特定情報から生成される第2の患者特定情報(例えば、個人を特定する情報から生成されるHash値等)が含まれていてもよい。そのよう場合において、提供手段602は、ユーザから、対象患者を指定する情報として第1の患者特定情報を含む要求を受信し、受信した第1の患者特定情報に基づき特定される患者識別情報を用いて、患者の診療記録ブロックの特定および患者の診療記録の画像データの取得を行ってもよい。
 また、患者識別情報には、診療記録の作成元の医療機関の情報である医療機関情報と該医療機関における患者の識別情報の組である第3の患者特定情報が含まれていてもよい。そのような場合において、提供手段602は、ユーザから、対象患者を指定する情報として第3の患者特定情報を含む要求を受信し、受信した第3の患者特定情報に基づき特定される患者識別情報を用いて、患者の診療記録ブロックの特定および患者の診療記録の画像データの取得を行ってもよい。
 このような構成を有することにより、個人情報に対する秘匿性とデータのアクセス性とを少なくとも両立させつつ、複数の医療機関の診療記録の保管および医療機関以外の機関への提供サービスを実現できる。なお、上記構成によれば、診療記録ブロックの記録先としてブロックチェーンを利用しているので、個人情報に対する秘匿性とデータのアクセス性とデータの完全性とを両立させつつ、複数の医療機関の診療記録の保管および医療機関以外の機関への提供サービスを実現できる。
 なお、上記の実施形態は以下の付記のようにも記載できる。
 (付記1)医療機関から提供された診療記録の画像データを少なくとも記憶する第1の記憶手段と、
 診療記録の対象患者と診療記録の画像データとを対応づける情報を記憶する第2の記憶手段と、
 医療機関から該医療機関の患者の診療記録の画像データが提供される度に、第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、かつ第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段と、
 医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する提供手段とを備えた
 ことを特徴とする診療記録管理システム。
 (付記2)医療機関から提供される診療記録の画像データは、保存義務期間を超過した診療記録の画像データであり、
 登録手段は、複数の医療機関から、自身の患者の診療記録の画像データの提供を受け付ける
 付記1記載の診療記録管理システム。
 (付記3)登録手段は、医療機関から提供される情報を公開情報と非公開情報とに分けた上で、ブロック内の情報を管理するための管理情報と公開情報と非公開情報の要約とを含むブロックをブロックチェーンに登録し、かつ非公開情報を第1の記憶手段または第2の記憶手段に記憶し、
 非公開情報には、診療記録の画像データが含まれ、
 管理情報には、記録識別情報が含まれる
 付記1または付記2記載の診療記録管理システム。
 (付記4)非公開情報には、診療記録の対象患者に関する情報である患者情報が含まれる
 付記3記載の診療記録管理システム。
 (付記5)患者識別情報には、診療記録の作成元の医療機関以外の機関が医療機関の患者を特定可能な情報である第1の患者特定情報または第1の患者特定情報から生成される第2の患者特定情報が含まれ、
 提供手段は、ユーザから、対象患者を指定する情報として第1の患者特定情報を含む要求を受信し、受信した第1の患者特定情報に基づき特定される患者識別情報を用いて、患者の診療記録ブロックの特定および患者の診療記録の画像データの取得を行う
 付記1から付記4のうちのいずれかに記載の診療記録管理システム。
 (付記6)患者識別情報には、診療記録の作成元の医療機関の情報である医療機関情報と該医療機関における患者の識別情報の組である第3の患者特定情報が含まれ、
 提供手段は、ユーザから、対象患者を指定する情報として第3の患者特定情報を含む要求を受信し、受信した第3の患者特定情報に基づき特定される患者識別情報を用いて、患者の診療記録ブロックの特定および患者の診療記録の画像データの取得を行う
 付記1から付記5のうちのいずれかに記載の診療記録管理システム。
 (付記7)提供手段は、診療記録ブロックに含まれる画像データの要約を用いて、画像データに対する改ざん有無を判定した上で、画像データを提供する
 付記1から付記6のうちのいずれかに記載の診療記録管理システム。
 (付記8)提供手段は、
 医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、第1の記憶手段、ブロックチェーンまたは第2の記憶手段における指定された患者に関する情報の登録状況を提供する照会手段を含む
 付記1から付記7のうちのいずれかに記載の診療記録管理システム。
 (付記9)提供手段は、
 要求元のユーザに対して、指定された患者または診療記録に関する情報へのアクセス権の有無を判定する権限判定手段を含む
 付記1から付記8のうちのいずれかに記載の診療記録管理システム。
 (付記10)登録手段は、医療機関から診療記録の提供に対する承諾を受けた患者に関する情報である承諾情報が提供されると、ブロックチェーンに、医療機関の情報である医療機関情報を少なくとも含む承諾情報ブロックを追加し、かつ第2の記憶手段に、患者を識別する患者識別情報と、承諾情報ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する
 付記1から付記9のうちのいずれかに記載の診療記録管理システム。
 (付記11)セキュアな環境に構築され、医療機関から提供された診療記録の画像データを少なくとも記憶する第1の記憶手段と、
 セキュアな環境に構築され、診療記録の対象患者と診療記録の画像データとを対応づける情報を記憶する第2の記憶手段と、
 医療機関以外の機関である第三者機関が運営するノードが有する第3の記憶手段と、
 医療機関から該医療機関の患者の診療記録の画像データが提供される度に、第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ第3の記憶手段に、記録識別情報と画像データの要約とを含む診療記録ブロックを記憶し、かつ第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段と、
 医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する提供手段とを備えた
 ことを特徴とする診療記録管理システム。
 (付記12)医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段と、
 医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する提供手段とを備えた
 ことを特徴とする診療記録管理装置。
 (付記13)情報処理装置が、
 医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶し、
 医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する
 ことを特徴とする診療記録管理方法。
 (付記14)コンピュータに、
 医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段に、診療記録を識別する記録識別情報と、画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、記録識別情報と画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段に、患者を識別する患者識別情報と、診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する処理、および
 医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する処理
 を実行させるための診療記録管理プログラム。
 以上、本実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
 この出願は、2017年6月5日に出願された日本特許出願2017-111002を基礎とする優先権を主張し、その開示の全てをここに取り込む。
 本発明は、診療記録に限らず、秘匿性の高い情報について、作成元の機関以外の機関への提供を可能にする用途に好適に適用可能である。
 10 診療記録管理システム
 1 診療記録管理装置
 101 患者登録部
 102 診療記録登録部
 103 登録情報照会部
 104 診療記録提供部
 105 課金部
 106 権限判定部
 11 登録部
 12 提供部
 2 ブロックチェーン管理システム
 21 管理ノード
 211 データ受付部
 212 ブロック生成部
 213 ブロック共有部
 214 情報記憶部
 215 ブロック検証部
 216 データ出力部
 22 ブロックチェーン
 3 登録情報DB
 4 診療記録DB
 5 ネットワーク
 1000 コンピュータ
 1001 CPU
 1002 主記憶装置
 1003 補助記憶装置
 1004 インタフェース
 1005 ディスプレイ装置
 1006 入力装置
 6 診療記録管理装置
 601 登録手段
 602 提供手段

Claims (14)

  1.  医療機関から提供された診療記録の画像データを少なくとも記憶する第1の記憶手段と、
     前記診療記録の対象患者と前記診療記録の画像データとを対応づける情報を記憶する第2の記憶手段と、
     医療機関から該医療機関の患者の診療記録の画像データが提供される度に、前記第1の記憶手段に、前記診療記録を識別する記録識別情報と、前記画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、前記記録識別情報と前記画像データの要約とを含む診療記録ブロックを追加し、かつ前記第2の記憶手段に、前記患者を識別する患者識別情報と、前記診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段と、
     医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、前記第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する提供手段とを備えた
     ことを特徴とする診療記録管理システム。
  2.  医療機関から提供される診療記録の画像データは、保存義務期間を超過した診療記録の画像データであり、
     前記登録手段は、複数の医療機関から、自身の患者の診療記録の画像データの提供を受け付ける
     請求項1記載の診療記録管理システム。
  3.  前記登録手段は、医療機関から提供される情報を公開情報と非公開情報とに分けた上で、ブロック内の情報を管理するための管理情報と公開情報と非公開情報の要約とを含むブロックを前記ブロックチェーンに登録し、かつ非公開情報を前記第1の記憶手段または前記第2の記憶手段に記憶し、
     前記非公開情報には、前記診療記録の画像データが含まれ、
     前記管理情報には、前記記録識別情報が含まれる
     請求項1または請求項2記載の診療記録管理システム。
  4.  前記非公開情報には、診療記録の対象患者に関する情報である患者情報が含まれる
     請求項3記載の診療記録管理システム。
  5.  前記患者識別情報には、診療記録の作成元の医療機関以外の機関が前記医療機関の患者を特定可能な情報である第1の患者特定情報または前記第1の患者特定情報から生成される第2の患者特定情報が含まれ、
     前記提供手段は、ユーザから、対象患者を指定する情報として前記第1の患者特定情報を含む要求を受信し、受信した前記第1の患者特定情報に基づき特定される前記患者識別情報を用いて、前記患者の診療記録ブロックの特定および前記患者の診療記録の画像データの取得を行う
     請求項1から請求項4のうちのいずれかに記載の診療記録管理システム。
  6.  前記患者識別情報には、診療記録の作成元の医療機関の情報である医療機関情報と該医療機関における患者の識別情報の組である第3の患者特定情報が含まれ、
     前記提供手段は、ユーザから、対象患者を指定する情報として前記第3の患者特定情報を含む要求を受信し、受信した前記第3の患者特定情報に基づき特定される前記患者識別情報を用いて、前記患者の診療記録ブロックの特定および前記患者の診療記録の画像データの取得を行う
     請求項1から請求項5のうちのいずれかに記載の診療記録管理システム。
  7.  前記提供手段は、前記診療記録ブロックに含まれる画像データの要約を用いて、前記画像データに対する改ざん有無を判定した上で、前記画像データを提供する
     請求項1から請求項6のうちのいずれかに記載の診療記録管理システム。
  8.  前記提供手段は、
     医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、前記第1の記憶手段、前記ブロックチェーンまたは前記第2の記憶手段における指定された患者に関する情報の登録状況を提供する照会手段を含む
     請求項1から請求項7のうちのいずれかに記載の診療記録管理システム。
  9.  前記提供手段は、
     要求元のユーザに対して、指定された患者または診療記録に関する情報へのアクセス権の有無を判定する権限判定手段を含む
     請求項1から請求項8のうちのいずれかに記載の診療記録管理システム。
  10.  前記登録手段は、医療機関から診療記録の提供に対する承諾を受けた患者に関する情報である承諾情報が提供されると、前記ブロックチェーンに、前記医療機関の情報である医療機関情報を少なくとも含む承諾情報ブロックを追加し、かつ前記第2の記憶手段に、前記患者を識別する患者識別情報と、前記承諾情報ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する
     請求項1から請求項9のうちのいずれかに記載の診療記録管理システム。
  11.  セキュアな環境に構築され、医療機関から提供された診療記録の画像データを少なくとも記憶する第1の記憶手段と、
     セキュアな環境に構築され、前記診療記録の対象患者と前記診療記録の画像データとを対応づける情報を記憶する第2の記憶手段と、
     医療機関以外の機関である第三者機関が運営するノードが有する第3の記憶手段と、
     医療機関から該医療機関の患者の診療記録の画像データが提供される度に、前記第1の記憶手段に、前記診療記録を識別する記録識別情報と、前記画像データとを対応づけて記憶し、かつ前記第3の記憶手段に、前記記録識別情報と前記画像データの要約とを含む診療記録ブロックを記憶し、かつ前記第2の記憶手段に、前記患者を識別する患者識別情報と、前記診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段と、
     医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、前記第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する提供手段とを備えた
     ことを特徴とする診療記録管理システム。
  12.  医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段に、前記診療記録を識別する記録識別情報と、前記画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、前記記録識別情報と前記画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段に、前記患者を識別する患者識別情報と、前記診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する登録手段と、
     医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、前記第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する提供手段とを備えた
     ことを特徴とする診療記録管理装置。
  13.  情報処理装置が、
     医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段に、前記診療記録を識別する記録識別情報と、前記画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、前記記録識別情報と前記画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段に、前記患者を識別する患者識別情報と、前記診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶し、
     医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、前記第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する
     ことを特徴とする診療記録管理方法。
  14.  コンピュータに、
     医療機関から該医療機関の患者の診療記録の画像データが提供される度に、所定の第1の記憶手段に、前記診療記録を識別する記録識別情報と、前記画像データとを対応づけて記憶し、かつ2台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される所定のブロックチェーンに、前記記録識別情報と前記画像データの要約とを含む診療記録ブロックを追加し、かつ所定の第2の記憶手段に、前記患者を識別する患者識別情報と、前記診療記録ブロックを特定可能な情報であるブロック特定情報とを対応づけて記憶する処理、および
     医療機関以外の機関である第三者機関を含むユーザからの要求に応じて、前記第1の記憶手段に記憶されている診療記録の画像データの中から指定された患者の診療記録の画像データを検索して提供する処理
     を実行させるための診療記録管理プログラム。
PCT/JP2018/017434 2017-06-05 2018-05-01 診療記録管理システム、装置、方法およびプログラム WO2018225428A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2019523401A JP6801922B2 (ja) 2017-06-05 2018-05-01 診療記録管理システム、装置、方法およびプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017111002 2017-06-05
JP2017-111002 2017-06-05

Publications (1)

Publication Number Publication Date
WO2018225428A1 true WO2018225428A1 (ja) 2018-12-13

Family

ID=64567045

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/017434 WO2018225428A1 (ja) 2017-06-05 2018-05-01 診療記録管理システム、装置、方法およびプログラム

Country Status (2)

Country Link
JP (1) JP6801922B2 (ja)
WO (1) WO2018225428A1 (ja)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110070926A (zh) * 2019-03-21 2019-07-30 深圳壹账通智能科技有限公司 基于区块链的数据查询方法、装置、设备及可读存储介质
CN110097935A (zh) * 2019-04-24 2019-08-06 杭州宇链科技有限公司 一种基于区块链的医疗救助平台
CN110706766A (zh) * 2019-08-31 2020-01-17 华南理工大学 一种基于区块链的电子病历管理系统和转诊方法
CN110993112A (zh) * 2019-11-20 2020-04-10 泰康保险集团股份有限公司 基于区块链的肿瘤治疗案例管理方法、系统、介质及电子设备
CN111128322A (zh) * 2019-12-06 2020-05-08 北京先通康桥医药科技有限公司 基于区块链的医疗数据处理方法、服务器及系统
WO2020175042A1 (ja) * 2019-02-25 2020-09-03 株式会社イシダ 検査装置、検査結果管理システム、検査結果記憶方法及び検査結果管理方法
JP2021019271A (ja) * 2019-07-19 2021-02-15 キヤノン株式会社 画像形成装置、制御方法、プログラム
JP2021515338A (ja) * 2018-03-06 2021-06-17 アメリコープ インベストメンツ エルエルシー ブロックチェーンベースの商用インベントリシステムおよび方法
JP2021135543A (ja) * 2020-02-21 2021-09-13 富士通株式会社 管理プログラム、管理装置および管理方法
CN113658656A (zh) * 2021-10-19 2021-11-16 宁波杜比医疗科技有限公司 一种基于区块链的诊断记录存证方法、系统及相关装置
WO2022107336A1 (ja) * 2020-11-20 2022-05-27 富士通株式会社 情報処理プログラム、情報処理方法および情報処理装置
WO2022145312A1 (ja) * 2020-12-28 2022-07-07 ハッシュピーク株式会社 情報処理方法、情報処理装置及びプログラム
JP7101281B1 (ja) 2021-03-18 2022-07-14 エヌ・ティ・ティ・コミュニケーションズ株式会社 提供装置、提供方法および提供プログラム
JP2022538392A (ja) * 2019-06-19 2022-09-02 エレクトロニック・ヘルス・レコード・データ・インコーポレイテッド 電子医療記録データブロックチェーンシステム
WO2022195643A1 (ja) * 2021-03-13 2022-09-22 株式会社クエスト ブロックチェーンシステム、記憶装置及び管理装置
CN115148322A (zh) * 2022-08-31 2022-10-04 神州医疗科技股份有限公司 临床医疗通用数据结构模型的临床数据储存方法和系统
JP7490368B2 (ja) 2020-01-16 2024-05-27 キヤノン株式会社 情報処理装置、制御方法、およびプログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0258153A (ja) * 1988-08-24 1990-02-27 Mitsubishi Electric Corp 情報処理装置
JP2002034907A (ja) * 2000-07-25 2002-02-05 Olympus Optical Co Ltd 内視鏡画像記録装置及び内視鏡画像管理システム
JP2006511881A (ja) * 2002-12-18 2006-04-06 ジーイー・メディカル・システムズ・グローバル・テクノロジー・カンパニー・エルエルシー 統合医療知識ベースインターフェースシステム及び方法
JP2016209468A (ja) * 2015-05-13 2016-12-15 株式会社島津製作所 カルテ要約作成装置
WO2017087769A1 (en) * 2015-11-18 2017-05-26 Global Specimen Solutions, Inc. Distributed systems for secure storage and retrieval of encrypted biological specimen data
JP6268624B1 (ja) * 2017-02-17 2018-01-31 株式会社Kompath データ管理システム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0258153A (ja) * 1988-08-24 1990-02-27 Mitsubishi Electric Corp 情報処理装置
JP2002034907A (ja) * 2000-07-25 2002-02-05 Olympus Optical Co Ltd 内視鏡画像記録装置及び内視鏡画像管理システム
JP2006511881A (ja) * 2002-12-18 2006-04-06 ジーイー・メディカル・システムズ・グローバル・テクノロジー・カンパニー・エルエルシー 統合医療知識ベースインターフェースシステム及び方法
JP2016209468A (ja) * 2015-05-13 2016-12-15 株式会社島津製作所 カルテ要約作成装置
WO2017087769A1 (en) * 2015-11-18 2017-05-26 Global Specimen Solutions, Inc. Distributed systems for secure storage and retrieval of encrypted biological specimen data
JP6268624B1 (ja) * 2017-02-17 2018-01-31 株式会社Kompath データ管理システム

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7005051B2 (ja) 2018-03-06 2022-01-21 アメリコープ インベストメンツ エルエルシー ブロックチェーンベースの商用インベントリシステムおよび方法
JP2021515338A (ja) * 2018-03-06 2021-06-17 アメリコープ インベストメンツ エルエルシー ブロックチェーンベースの商用インベントリシステムおよび方法
WO2020175042A1 (ja) * 2019-02-25 2020-09-03 株式会社イシダ 検査装置、検査結果管理システム、検査結果記憶方法及び検査結果管理方法
US11714922B2 (en) 2019-02-25 2023-08-01 Ishida Co., Ltd. Inspection device, inspection results management system, inspection results storage method, and inspection results management method
JP6783495B1 (ja) * 2019-02-25 2020-11-11 株式会社イシダ 検査装置、検査結果管理システム、検査結果記憶方法及び検査結果管理方法
CN110070926A (zh) * 2019-03-21 2019-07-30 深圳壹账通智能科技有限公司 基于区块链的数据查询方法、装置、设备及可读存储介质
CN110097935A (zh) * 2019-04-24 2019-08-06 杭州宇链科技有限公司 一种基于区块链的医疗救助平台
JP7253865B2 (ja) 2019-06-19 2023-04-07 エレクトロニック・ヘルス・レコード・データ・インコーポレイテッド 電子医療記録データブロックチェーンシステム
JP2022538392A (ja) * 2019-06-19 2022-09-02 エレクトロニック・ヘルス・レコード・データ・インコーポレイテッド 電子医療記録データブロックチェーンシステム
JP2021019271A (ja) * 2019-07-19 2021-02-15 キヤノン株式会社 画像形成装置、制御方法、プログラム
JP7263167B2 (ja) 2019-07-19 2023-04-24 キヤノン株式会社 画像形成装置、制御方法、プログラム
CN110706766A (zh) * 2019-08-31 2020-01-17 华南理工大学 一种基于区块链的电子病历管理系统和转诊方法
CN110993112A (zh) * 2019-11-20 2020-04-10 泰康保险集团股份有限公司 基于区块链的肿瘤治疗案例管理方法、系统、介质及电子设备
CN110993112B (zh) * 2019-11-20 2023-04-18 泰康保险集团股份有限公司 基于区块链的肿瘤治疗案例管理方法、系统、介质及电子设备
CN111128322A (zh) * 2019-12-06 2020-05-08 北京先通康桥医药科技有限公司 基于区块链的医疗数据处理方法、服务器及系统
JP7490368B2 (ja) 2020-01-16 2024-05-27 キヤノン株式会社 情報処理装置、制御方法、およびプログラム
JP2021135543A (ja) * 2020-02-21 2021-09-13 富士通株式会社 管理プログラム、管理装置および管理方法
JP7381881B2 (ja) 2020-02-21 2023-11-16 富士通株式会社 管理プログラム、管理装置および管理方法
WO2022107336A1 (ja) * 2020-11-20 2022-05-27 富士通株式会社 情報処理プログラム、情報処理方法および情報処理装置
JP7487793B2 (ja) 2020-11-20 2024-05-21 富士通株式会社 情報処理プログラム、情報処理方法および情報処理装置
WO2022145312A1 (ja) * 2020-12-28 2022-07-07 ハッシュピーク株式会社 情報処理方法、情報処理装置及びプログラム
WO2022195643A1 (ja) * 2021-03-13 2022-09-22 株式会社クエスト ブロックチェーンシステム、記憶装置及び管理装置
JP2022143911A (ja) * 2021-03-18 2022-10-03 エヌ・ティ・ティ・コミュニケーションズ株式会社 提供装置、提供方法および提供プログラム
WO2022196774A1 (ja) * 2021-03-18 2022-09-22 エヌ・ティ・ティ・コミュニケーションズ株式会社 提供装置、提供方法および提供プログラム
JP7101281B1 (ja) 2021-03-18 2022-07-14 エヌ・ティ・ティ・コミュニケーションズ株式会社 提供装置、提供方法および提供プログラム
CN113658656A (zh) * 2021-10-19 2021-11-16 宁波杜比医疗科技有限公司 一种基于区块链的诊断记录存证方法、系统及相关装置
CN115148322A (zh) * 2022-08-31 2022-10-04 神州医疗科技股份有限公司 临床医疗通用数据结构模型的临床数据储存方法和系统

Also Published As

Publication number Publication date
JPWO2018225428A1 (ja) 2019-11-21
JP6801922B2 (ja) 2020-12-16

Similar Documents

Publication Publication Date Title
WO2018225428A1 (ja) 診療記録管理システム、装置、方法およびプログラム
US10936732B2 (en) System and method for registering multi-party consent
Patel A framework for secure and decentralized sharing of medical imaging data via blockchain consensus
JP7250568B2 (ja) ブロックチェーン・ノード、ブロックチェーン・ノードの方法、およびブロックチェーン・ノードのコンピュータ・プログラム
US20130006865A1 (en) Systems, methods, apparatuses, and computer program products for providing network-accessible patient health records
US20210375408A1 (en) Blockchain-based distribution of medical data records
CN110909073A (zh) 基于智能合约分享隐私数据的方法及系统
US20060095958A1 (en) Distributed data consolidation network
Churches A proposed architecture and method of operation for improving the protection of privacy and confidentiality in disease registers
Ismail et al. Healthcare insurance frauds: Taxonomy and blockchain-based detection framework (Block-HI)
Chang et al. DeepLinQ: distributed multi-layer ledgers for privacy-preserving data sharing
US20200372983A1 (en) Methods and devices for storing and processing electronic medical record on blockchain
Daudén-Esmel et al. Lightweight blockchain-based platform for gdpr-compliant personal data management
US20210250165A1 (en) Tracking and linking item-related data
Ismail et al. Performance evaluation of a patient-centric blockchain-based healthcare records management framework
Xu et al. Decentralized autonomous imaging data processing using blockchain
CN112735552A (zh) 一种基于区块链及ipfs的电子病历夹信息系统
Kim et al. A trusted sharing model for patient records based on permissioned Blockchain
Ismail et al. BlockHR: A blockchain-based framework for health records management
Ghayvat et al. Sharif: Solid pod-based secured healthcare information storage and exchange solution in internet of things
US11374755B1 (en) Entangled token structure for blockchain networks
CN113722731A (zh) 一种医疗数据共享方法、装置、电子设备及存储介质
Wang et al. Health data security sharing method based on hybrid blockchain
US20110060607A1 (en) Health care information systems
Ahmed et al. Augmenting security and accountability within the eHealth Exchange

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18812798

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019523401

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18812798

Country of ref document: EP

Kind code of ref document: A1