WO2021131794A1 - 制御方法、プログラム及び制御装置 - Google Patents

制御方法、プログラム及び制御装置 Download PDF

Info

Publication number
WO2021131794A1
WO2021131794A1 PCT/JP2020/046287 JP2020046287W WO2021131794A1 WO 2021131794 A1 WO2021131794 A1 WO 2021131794A1 JP 2020046287 W JP2020046287 W JP 2020046287W WO 2021131794 A1 WO2021131794 A1 WO 2021131794A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction data
medical
patient
smart contract
doctor
Prior art date
Application number
PCT/JP2020/046287
Other languages
English (en)
French (fr)
Inventor
綾香 三谷
勇二 海上
哲司 渕上
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
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 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to CN202080089167.3A priority Critical patent/CN114846561A/zh
Priority to JP2021567241A priority patent/JPWO2021131794A1/ja
Priority to EP20906573.9A priority patent/EP4084015A4/en
Publication of WO2021131794A1 publication Critical patent/WO2021131794A1/ja
Priority to US17/842,104 priority patent/US20220311629A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring

Definitions

  • Patent Document 2 proposes a method of sharing and managing medical information including a patient's statement of intention in advance via the Internet in consideration of reliability and privacy.
  • Non-Patent Document 1 it cannot be verified whether or not the medical procedure considering the patient's intention is determined and implemented in a situation where the patient's intention cannot be expressed. In other words, it cannot be verified that the patient's intention reflected in advance in POLST or the like was taken into consideration in the actual medical procedure when the patient's intention cannot be actually expressed.
  • the control method of the present disclosure is a control method in a system, in which a smart contract programmed so that a medical treatment decision obtained as a result of discussion between a patient and a doctor can be executed is stored in a distributed ledger.
  • the control method acquires first transaction data including the biometric information of the patient obtained from the sensor, and acquires second transaction data including information on the diagnosis result of the doctor with respect to the biometric information.
  • the smart contract is executed, and the smart contract is executed to obtain the patient.
  • a recording medium such as a system, an integrated circuit, a computer program or a computer-readable CD-ROM, and the system, method, integrated circuit, computer program and the like. It may be realized by any combination of recording media.
  • FIG. 9 is a diagram conceptually showing the algorithm of the medical judgment support smart according to the embodiment.
  • FIG. 10 is a diagram conceptually showing the algorithm of the medical judgment support smart contract according to the first embodiment.
  • FIG. 11 is a diagram conceptually showing the algorithm of the medical judgment support smart contract according to the second embodiment.
  • FIG. 12 is a block diagram showing an example of the configuration of the server device according to the embodiment.
  • FIG. 13A is a diagram showing an outline of the operation until the patient's statement of intention of the medical procedure management system according to the embodiment is stored in the distributed ledger.
  • FIG. 13B is a diagram showing an outline of the operation until it is verifiable that the medical treatment measures according to the patient's intention stored in the distributed ledger of the medical treatment treatment management system according to the present embodiment are determined and implemented.
  • the first transaction data and the second transaction data include a contract address indicating the address of the smart contract.
  • FIG. 1 is a diagram showing an overall configuration of a medical procedure management system 1 according to the present embodiment.
  • the smart contract generation unit 103 uses data such as a medical proposal subset acquired via the communication unit 101 to program the algorithm of the medical decision support smart contract, thereby providing the medical decision support smart contract. To generate. Then, the smart contract generation unit 103 transmits the generated medical decision support smart contract to the blockchain control unit 104.
  • the medical proposal subset is data indicating a combination of medical procedures that can be proposed.
  • the smart contract generation unit 103 uses the derived conditional expressions, variables, and constants to edit a program that can be executed on the blockchain and returns a unique output for a unique input value, thereby making a medical judgment. Generate assistive smart contracts.
  • the smart contract generation unit 103 binaries the conditional expression described in Solidity, which is a script language that can be executed on the Ethereum-based blockchain, and the derived constant and variable access method. Generate as a converted program. Then, the smart contract generation unit 103 transmits the generated binary program to the blockchain control unit 104 as a medical judgment support smart contract.
  • the blockchain control unit 104 controls the formation of the blockchain network by establishing Peer-to-Peer communication in accordance with the specified blockchain protocol.
  • the display unit 105 uses data such as a medical proposal subset acquired via the communication unit 101 to determine the patient's intention in advance for medical treatment in a situation where the patient cannot express his / her intention while discussing with a doctor. Display questions and so on.
  • the display unit 105 displays the medical procedure obtained as a result of the discussion between the patient and the doctor, and displays the content of the medical judgment support smart contract generated by the smart contract generation unit 103 in a form that can be understood by the user such as the patient. To do.
  • the display unit 105 may convey the display content to the user audibly and tactilely, not only when the display is visually displayed.
  • the doctor terminal 20 is, for example, a terminal such as a PC used by a doctor, but is not limited thereto.
  • the doctor terminal 20 is not limited to the terminal but may be a server as long as it has a distributed ledger, can form a blockchain network, and can be used by a doctor or can directly communicate with a doctor.
  • the display unit 204 may display the question displayed by the patient terminal 10 in synchronization with the patient terminal 10 by using data such as a medical proposal subset acquired via the communication unit 101.
  • the question displayed by the patient terminal 10 is a question to the patient for determining the patient's intention in advance for the medical procedure in a situation where the patient cannot express his / her intention.
  • the storage unit 205 stores the doctor's opinion generated by the doctor's opinion generation unit 202, the text data input by the doctor's operation, the voice data, and the data input by the patient.
  • the blockchain address is information given to each node constituting the blockchain network, and is information that can uniquely identify the node.
  • the patient address 11 shown in FIG. 5 is a blockchain address assigned to the patient terminal 10.
  • the doctor address 21 shown in FIG. 5 is a blockchain address assigned to the doctor terminal 20, and the server address 31 is a blockchain address assigned to the server device 30.
  • the physical transaction data includes a destination address, content data, and a source address.
  • the destination address includes the medical decision support contract address 32, and the source address includes the patient address 11.
  • the content data includes information indicating the patient's condition and the signature of the patient terminal 10 which is the transmission source.
  • the information indicating the patient's condition is a medical fact indicating the patient's condition, such as vital data of the patient.
  • the signature is used to prove the authenticity of the physical transaction data.
  • the signature may be, for example, a digest value of a value indicating the patient's condition encrypted with a private key. In this case, the public key may be separately stored in the distributed ledger and made public.
  • the next selection step is executed only when the registered signature, the physical transaction data, and the content data of the opinion transaction data, that is, the input signature, match as a result of verification.
  • the process is interrupted and the variables of the medical judgment support smart contract are initialized.
  • the execution of the medical decision support smart contract is stopped.
  • the patient terminal 10 and the doctor terminal 20 may be notified that the execution of the medical judgment support smart contract has been stopped.
  • the medical decision support smart contract may include the patient address 11 and the doctor address 21 and generate alert transaction data indicating that the execution has been stopped.
  • the medical proposal subset included in the content data of the medical proposal transaction data is shared with the doctor via the doctor terminal 20, and the doctor implements the medical treatment according to this medical proposal subset.
  • the medical judgment support smart contract executes the signature confirmation step and confirms that the registered signature matches the input signature contained in the content data of each of the physical transaction data and the opinion transaction data. Verify the reliability of the value.
  • the patient's condition is not anxiety stop
  • Example 2 Next, a case will be described in which a subset of medical procedures conforming to the current living will format is pre-registered in the medical decision support smart contract as medical procedures obtained as a result of discussion between the patient and the doctor. In the following, the same description as in Example 1 will be omitted.
  • FIG. 12 is a block diagram showing an example of the configuration of the server device 30 according to the present embodiment.
  • the blockchain control unit 303 executes the medical judgment support smart contract based on the patient's biological information included in the physical transaction data and the diagnosis result of the doctor for the patient's biological information included in the opinion transaction data. Let me. Further, the blockchain control unit 303 outputs the proposal information regarding the medical treatment to be performed to the patient obtained from the medical judgment support smart contract by executing the medical judgment support smart contract.
  • the blockchain control unit 303 links the medical treatment implementation result transaction data acquired from the doctor terminal 20 with the medical proposal transaction data output by the medical judgment support smart contract. More specifically, the blockchain control unit 303 stores in the storage unit 302 information that associates the medical treatment implementation result included in the medical treatment implementation result transaction data with the medical proposal subset included in the medical proposal transaction data. The blockchain control unit 303 may execute a smart contract different from the medical judgment support smart contract and store the information in which the medical measure implementation result and the medical proposal subset are linked in the distributed ledger.
  • the working memory 305 is a memory that functions as an on-memory of the server device 30.
  • the working memory 305 reads the block recorded in the distributed ledger and holds the smart contract to operate the smart contract.
  • the working memory 305 may hold a contract address indicating a smart contract.
  • step S3 the medical procedure management system 1 operates the medical judgment support smart contract generated in step S2. More specifically, the medical procedure management system 1 operates the medical decision support smart contract by storing and deploying the medical decision support smart contract generated in step S2 in the distributed ledger.
  • step S6 the medical judgment support smart contract outputs a medical procedure proposal to the patient as an execution result. More specifically, the medical judgment support smart contract takes the physical transaction data and the opinion transaction data as inputs, and outputs the proposal information uniquely determined and the proposal information regarding the medical procedure to be performed on the patient.
  • the medical procedure management system 1 can ensure the difficulty and reliability of tampering with the medical procedure process that reflects the patient's intention. That is, the medical procedure management system 1 records in a blockchain, which is extremely difficult to falsify, the medical procedure judgment including the patient's expression of intention and the implementation result of the medical procedure based on the medical procedure judgment result. This makes it possible to verify whether or not the medical procedure has been determined and implemented in consideration of the patients' prior statements of intention.
  • step S102 determines whether the discussion in step S102 has been completed (S103).
  • the patient terminal 10 generates a third transaction data including the medical judgment support smart contract generated in step S106 (S107).
  • the patient terminal 10 includes the medical judgment support smart contract generated as a program binarized in the content data, and the patient address 11 in the destination address and the source address, as shown in FIG. 6, for example. Generate the third transaction data.
  • the patient terminal 10, the doctor terminal 20, and the server device 30 are synchronized. More specifically, the patient terminal 10, the doctor terminal 20, and the server device 30 each execute a consensus algorithm, take in the third transaction data acquired in step S110 into a block, and store the block in the distributed ledger.
  • the doctor terminal 20 confirms whether or not the doctor's diagnosis result for the patient's condition included in the condition transaction data has been acquired (S207).
  • the doctor terminal 20 When the diagnosis result is acquired in step S207 (Yes in S207), the doctor terminal 20 generates opinion transaction data including information on the doctor's diagnosis result with respect to the above-mentioned patient's biological information indicating the doctor's opinion (S209).
  • the doctor terminal 20 has the doctor's opinion and the signature of the doctor terminal 20 in the content data, the medical judgment support contract address 32 in the destination address, and the doctor address 21 in the source address. Generate views transaction data that includes.
  • the server device 30 transmits the medical proposal transaction data acquired in step S212 to the doctor terminal 20 (S213).
  • a blockchain network is configured by one patient terminal 10, one doctor terminal 20, and one server device 30 has been described as an example.
  • a blockchain network may be configured by a plurality of patient terminals 10, a plurality of doctor terminals 20, and a plurality of server devices.
  • the blockchain network may be configured by combining one patient terminal 10, a plurality of doctor terminals 20, and a plurality of server devices.
  • the patient terminal 10 has been described as generating a medical decision support smart contract, but the present invention is not limited to this.
  • the patient terminal 10 may be generated in cooperation with the doctor terminal 20, or the doctor terminal 20 may be generated in cooperation with the patient terminal 10.
  • the signatures of the patient terminal 10 and the doctor terminal 20 may be required as a multisig to issue transaction data including the medical judgment support smart contract.
  • the data format of the smart contract included in the transaction data is binary data
  • the data format may be executable by the selected blockchain platform, for example, an application binary interface.
  • the medical fact is included in the transaction data and transmitted / received, but the medical fact is not limited to this. Any format may be used as long as the patient terminal 10, the doctor terminal 20, and the server device 30 can communicate with each other. Medical facts may be transmitted and received using, for example, file transport within P2P, or may be transmitted and received via communication on the web.
  • the input to the medical judgment support smart contract is described as the physical transaction data transmitted by the patient terminal 10 and the opinion transaction data transmitted by the doctor terminal 20, but the input is not limited to this.
  • the doctor terminal 20 may acquire the condition transaction data generated by the patient terminal 10 and collect the patient's condition included in the condition transaction data into the view transaction data as the input.
  • the input to the medical judgment support smart contract is described as the physical transaction data and the opinion transaction data, it does not specify the data division of the transaction data. If the algorithm in the medical judgment support smart contract corresponds, one transaction data such as physical transaction data may be divided into two or more and input.
  • Each device in the above embodiment may be composed of a part or all of the constituent elements of one system LSI (Large Scale Integration).
  • a system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on a single chip, and specifically, is a computer system including a microprocessor, a ROM, a RAM, and the like. ..
  • a computer program is recorded in the RAM. When the microprocessor operates according to the computer program, the system LSI achieves its function.
  • the IC card or the module is a computer system composed of a microprocessor, ROM, RAM and the like.
  • the IC card or the module may include the above-mentioned super multifunctional LSI.
  • the microprocessor operates according to a computer program, the IC card or the module achieves its function.
  • This IC card or this module may have tamper resistance.
  • the present disclosure may be the method shown above. Further, it may be a computer program that realizes these methods by a computer, or it may be a digital signal composed of the computer program.
  • the present disclosure is a computer system including a microprocessor and a memory, in which the memory records the computer program, and the microprocessor may operate according to the computer program.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • Biomedical Technology (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Pathology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

本開示の制御方法は、システムにおける制御方法であって、患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化されたスマートコントラクトが分散台帳に格納されており、センサから得られる患者の生体情報を含む容体トランザクションデータを取得し（Ｓ２０５）、生体情報に対する医師の診断結果に関する情報を含む見解トランザクションデータを取得し（Ｓ２１０）、取得した容体トランザクションデータ及び見解トランザクションデータに含まれる生体情報及び診断結果に基づき、スマートコントラクトを実行させ、スマートコントラクトを実行させることで得られた、患者に施されるべき医療処置に関する医療提案情報を出力する（Ｓ２１１、Ｓ２１２）。

Description

制御方法、プログラム及び制御装置
　本開示は、ブロックチェーン技術を用いた制御方法、プログラム及び制御装置に関する。
　例えば特許文献１には、サーバに集積した既知の医学的ファクトに評価を与えて、当該評価に基づいて最も効果的な医療提案を選択する医療判断支援システムが提案されている。
　ここで、医学的ファクトは、例えば医療診断、医学的所見、薬物治療、既往歴、補助的提案、検査値の評価、医学的妥当性、医学的結論、医療処置、医療上の指示、医療報告書、医療上の質問、症状、症状の群、テキストブロック、または、栄養上の勧告である。また、医学的ファクトは、例えば運動提案、ケアの提案、リハビリ提案、遺伝面、組織学所見、生理的過程、病理生理的過程の発見、質指標、治療勧告、療法勧告、プロセス提案、医療調査提案、患者アンケート、または、専門的なアンケート調査であってもよい。なお、医学的ファクトは、これらの任意の組合せから構成されてもよい。
　また、例えば特許文献２には、事前の患者の意思表明を含む医療情報を、信頼度及びプライバシーを考慮した上でインターネットを介して共有及び管理する方法が提案されている。
　しかしながら、上記の特許文献１及び特許文献２で提案される手法では、患者本人による意思表明が可能な状況下において医療処置を決定することができるに過ぎない。つまり、患者が意思表示できない状況下においては、患者の意思を考慮して医療処置を決定することができない。
　それに対して、患者らの事前の意思表明が反映されたリビングウィルまたはPOLSTを用いて、患者本人による意思表明が不可能な状況下で患者の意思を考慮した医療処置を決定する方法がある（例えば非特許文献１）。ここで、POLSTは、Physician Orders for Life-Sustaining Treatmentの略である。POLSTは、患者の人生の最終段階における蘇生処置を含む医療処理に関する医師による指示文書であり、蘇生不要指示書であるDNAR(Do Not Attempt Resuscitate)が含まれる。そして、医師は、「生命を脅かす疾患」に直面している患者に対して、心肺蘇生処置を行うか否かなど実施する医療処置の判断をPOLSTのもとに行うことができる。なお、DNARにおいて癌の末期などで心停止ないし呼吸停止した際に心肺蘇生を行わないという特別な指示がある場合、医師は、DNARに従って心肺蘇生を省略することができる。
特表２０１６－５１６２３１号公報 特表２０１５－５０７２８２号公報
　しかしながら、非特許文献１に開示されるPOLSTを用いたとしても、患者本人による意思表明が不可能な状況下では患者の意思を考慮した医療処置を決定して実施したかどうかを検証できない。つまり、実際に患者が意思表示できない状況になった時において、POLSTなどに予め反映された患者の意思が実際の医療処置に考慮されたことを検証できない。
　このため、このような状況下において、患者の意思を無視した医療処置が行われた場合、その妥当性を検証することもできないし、その処置の責任の所在もわからない。
　本開示は、上述の事情を鑑みてなされたもので、患者らの事前の意思表明を考慮した医療処置を決定して実施したかどうかを検証できる制御方法、プログラム及び制御装置を提供することを目的とする。
　上記目的を達成するために、本開示の制御方法は、システムにおける制御方法であって、患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化されたスマートコントラクトが分散台帳に格納されており、前記制御方法は、センサから得られる前記患者の生体情報を含む第１トランザクションデータを取得し、前記生体情報に対する前記医師の診断結果に関する情報を含む第２トランザクションデータを取得し、取得した前記第１トランザクションデータ及び前記第２トランザクションデータに含まれる前記生体情報及び前記診断結果に基づき、前記スマートコントラクトを実行させ、前記スマートコントラクトを実行させることで得られた、前記患者に施されるべき医療処置に関する医療提案情報を出力する。
　なお、これらの包括的または具体的な態様は、システム、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
　本開示の制御方法等によれば、患者らの事前の意思表明を考慮した医療処置を決定して実施したかどうかを検証できる制御方法、プログラム及び制御装置を提供することを目的とする。
図１は、実施の形態に係る医療処置管理システムの全体構成を示す図である。 図２は、実施の形態に係る患者端末の構成の一例を示すブロック図である。 図３は、ブロックチェーンのデータ構造を示す説明図である。 図４は、実施の形態に係る医師端末の構成の一例を示すブロック図である。 図５は、実施の形態に係る分散台帳に保持されるブロックチェーンネットワーク内のアドレス構成を示す図である。 図６は、実施の形態に係る第３トランザクションデータのデータ構造を概念的に示す図である。 図７は、実施の形態に係る容体トランザクションデータのデータ構造を概念的に示す図である。 図８は、実施の形態に係る見解トランザクションデータのデータ構造を概念的に示す図である。 図９は、実施の形態に係る医療判断支援スマートのアルゴリズムを概念的に示す図である。 図１０は、実施例１に係る医療判断支援スマートコントラクトのアルゴリズムを概念的に示す図である。 図１１は、実施例２に係る医療判断支援スマートコントラクトのアルゴリズムを概念的に示す図である。 図１２は、実施の形態に係るサーバ装置の構成の一例を示すブロック図である。 図１３Ａは、実施の形態に係る医療処置管理システムの患者の意思表明を分散台帳に格納するまでの動作の概要を示す図である。 図１３Ｂは、本実施の形態に係る医療処置管理システムの分散台帳に格納された患者の意思に沿った医療措置を決定して実施したかを検証可能に記録するまでの動作の概要を示す図である。 図１４は、実施の形態に係る医療処置管理システムにより医療判断支援スマートコントラクトが生成されて稼働するまでのシーケンスを示す図である。 図１５は、実施の形態に係る医療判断支援スマートコントラクトが実行され、医療処置の実施結果が記録されるまでのシーケンスを示す図である。
　本開示の一実施態様の制御方法は、システムにおける制御方法であって、患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化されたスマートコントラクトが分散台帳に格納されており、前記制御方法は、センサから得られる前記患者の生体情報を含む第１トランザクションデータを取得し、前記生体情報に対する前記医師の診断結果に関する情報を含む第２トランザクションデータを取得し、取得した前記第１トランザクションデータ及び前記第２トランザクションデータに含まれる前記生体情報及び前記診断結果に基づき、前記スマートコントラクトを実行させ、前記スマートコントラクトを実行させることで得られた、前記患者に施されるべき医療処置に関する医療提案情報を出力する。
　このように、患者の事前の意思表明を考慮して患者の容体等から医療処置の提案を、一意に決定するスマートコントラクトに、患者本人による意思表明が不可能な状況下での医療処置の提案をさせることができる。これにより、実際に行った医療処置とスマートコントラクトに提案させた医療処置とを後日比較することができる。よって、患者らの事前の意思表明を考慮した医療処置を決定して実施したかどうかを検証できる。
　また、例えば、前記第１トランザクションデータ及び前記第２トランザクションデータを取得する前において、前記患者と前記医師とが合議した結果得た前記医療処置判断に基づき生成した前記スマートコントラクトを含む第３トランザクションデータを取得し、前記第３トランザクションデータを含むブロックを前記分散台帳に格納してもよい。
　これにより、患者の事前の意思表明を考慮して当該スマートコントラクトを生成して分散台帳に格納することができる。
　ここで、例えば、前記第３トランザクションデータには、前記第３トランザクションデータの真贋性を証明するための署名が含まれていてもよい。
　また、例えば、前記スマートコントラクトは、前記第１トランザクションデータ及び前記第２トランザクションデータを入力値として、前記医療処置判断を実行するための条件式を含む記述を有するプログラムであってもよい。
　また、例えば、前記第１トランザクションデータと前記第２トランザクションデータとは、前記スマートコントラクトのアドレスを示すコントラクトアドレスを含む。
　また、例えば、さらに、前記医師が前記患者に対して実施した医療処置に関する情報である医療処置結果情報を含む第４トランザクションデータを取得し、前記医療処置結果情報を前記医療提案情報と紐づけて前記分散台帳に格納してもよい。
　これにより、実際に行った医療処置を分散台帳に格納することで、実際に行った医療処置とスマートコントラクトに提案させた医療処置との比較を、より信頼性を伴って行うことができる。よって、患者らの事前の意思表明を考慮した医療処置を決定して実施したかどうかを検証できる。
　ここで、例えば、前記生体情報は、心肺停止を示す情報であり、前記診断結果は外傷なしを示す情報であり、前記医療提案情報は、前記患者に施されるべき医療処置が心肺蘇生術の実施である旨を示す情報であってもよい。
　また、前記分散台帳は、ブロックチェーン基盤上に構築されてもよい。
　また、本開示の一態様に係る制御装置は、プロセッサとメモリと分散台帳とを有する制御装置であって、前記分散台帳には、患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化されたスマートコントラクトが格納されており、前記プロセッサは、センサから得られる前記患者の生体情報を含む第１トランザクションデータを取得し、前記プロセッサは、前記生体情報に対する前記医師の診断結果に関する情報を含む第２トランザクションデータを取得し、前記プロセッサは、前記メモリを用いて、取得した前記第１トランザクションデータ及び前記第２トランザクションデータに含まれる前記生体情報及び前記診断結果に基づき、前記スマートコントラクトを実行させ、前記プロセッサは、前記スマートコントラクトを実行させることで得られた、前記患者に施されるべき医療処置に関する医療提案情報を出力する。
　以下、図面を参照しながら、実施の形態について説明する。なお、以下で説明する実施の形態は、いずれも本開示の好ましい一具体例を示す。つまり、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置及び接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。本開示は、請求の範囲の記載に基づいて特定される。したがって、以下の実施の形態における構成要素のうち、本開示の最上位概念を示す独立請求項に記載されていない構成要素は、本開示の課題を達成するために必ずしも必要ではないが、より好ましい形態を構成する構成要素として説明される。
　（実施の形態）
　まず、本開示のシステム構成について説明する。
　［１．　システム構成］
　本開示の医療処置管理システムは、ブロックチェーン基盤上に構築される信頼性及び透明性の高い分散台帳に、患者の意思表明を記録し、患者の事前の意思表明を汲み取った医療処置をブロックチェーン上のスマートコントラクトに自律的に判定させて医療提案情報として出力させる。また、本開示の医療処置管理システムは、判定した医療処置と医師が実施した医療措置とを紐づけて分散台帳に記録する。これにより、医師が、患者らの事前の意思表明を考慮した医療処置を決定して実施したかどうかを高い信頼性をもって検証できる。
　以下、図面を参照しながら実施の形態に係る医療処置管理システム等の説明を行う。
　［１．１　医療処置管理システム１の全体構成］
　図１は、本実施の形態に係る医療処置管理システム１の全体構成を示す図である。
　医療処置管理システム１は、図１に示すように、１以上の患者端末１０と、１以上の医師端末２０と、１以上のサーバ装置３０とを備える。これらは、通信ネットワーク４０で接続されている。
　１以上の患者端末１０と１以上の医師端末２０と１以上のサーバ装置３０とは、ブロックチェーンのトランザクションデータ及びブロックが電子的に記録される分散台帳を有する記憶装置と接続する。１以上の患者端末１０と１以上の医師端末２０と１以上のサーバ装置３０とは、それぞれ記憶装置と通信ネットワーク４０を介して接続されていてもよいし、内部に記憶部として備えてもよい。
　このようにして、１以上の患者端末１０と１以上の医師端末２０と１以上のサーバ装置３０とは、ブロックチェーンネットワークを構成する。
　［１．２　患者端末１０の構成］
　患者端末１０は、例えば患者が使用するＰＣ（Personal Computer）等の端末であるが、これに限られない。患者端末１０は、分散台帳を有し、ブロックチェーンネットワークを構成することができ、かつ、患者が使用するまたは患者と直接通信を行うことができれば、端末に限らずサーバであってもよい。
　図２は、本実施の形態に係る患者端末１０の構成の一例を示すブロック図である。
　患者端末１０は、図２に示すように、通信部１０１と、センサ情報取得部１０２と、スマートコントラクト生成部１０３と、ブロックチェーン制御部１０４と、表示部１０５と、記憶部１０６とを備える。
　＜通信部１０１＞
　通信部１０１は、通信ネットワーク４０を介して、医師端末２０及びサーバ装置３０と通信を行う。また、通信部１０１は、患者が使用するキーボード、マイクなどの入力装置と通信する。
　通信部１０１は、例えば、患者の操作等により入力されるテキストデータ、音声データを取得したり、表示部１０５とインタラクティブに患者により入力されるデータを取得したりする。
　＜センサ情報取得部１０２＞
　センサ情報取得部１０２は、通信部１０１を介して、患者端末１０と接続したセンサ群からの情報であるセンサ情報を取得する。ここで、センサ情報は、患者の容体を示すために用いられる情報であり、医学的ファクトを示す情報である。センサ情報は、センサ群から得られる患者の生体情報であってもよい。生体情報は、患者の心拍数、血糖値、認知機能評価、呼吸数といった患者のバイタルデータを示す。
　センサ情報取得部１０２は、取得したセンサ情報を、その内容に応じて、スマートコントラクト生成部１０３、ブロックチェーン制御部１０４、表示部１０５、または記憶部１０６へ送信する。
　＜スマートコントラクト生成部１０３＞
　スマートコントラクト生成部１０３は、患者と医師とが合議した結果得た医療処置判断に基づき、医療判断支援スマートコントラクトを生成する。ここで、スマートコントラクトは、ブロックチェーン上で実行可能なプログラムであり、一意の入力値に対して一意の出力を返すプログラムである。そして、医療判断支援スマートコントラクトは、患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化されたスマートコントラクトである。医療判断支援スマートコントラクトは、実行されることで患者に施されるべき医療処置に関する医療提案情報を出力することができる。
　本実施の形態では、スマートコントラクト生成部１０３は、通信部１０１を介して取得した医療提案サブセットなどのデータを用いて、医療判断支援スマートコントラクトのアルゴリズムをプログラム化することで、医療判断支援スマートコントラクトを生成する。そして、スマートコントラクト生成部１０３は、生成した医療判断支援スマートコントラクトをブロックチェーン制御部１０４へ送信する。なお、医療提案サブセットは、提案可能な医療処置の組み合わせを示すデータである。
　ここで、医療判断支援スマートコントラクトを生成する方法の一例について説明する。
　まず、スマートコントラクト生成部１０３は、通信部１０１を介して、サーバ装置３０から医療提案サブセットなどのデータを取得する。次いで、スマートコントラクト生成部１０３は、患者と医師とが合議しながら、表示部１０５とインタラクティブに患者により入力される医療判断支援スマートコントラクトの内容を示すデータを取得し、医療提案サブセットに基づいて、医療判断支援スマートコントラクトを生成する。より詳細には、スマートコントラクト生成部１０３は、患者端末１０から取得したセンサ情報と医師端末２０から取得した医学的ファクトとを入力値として、入力値に対する判断を行う条件式と、その条件式を構成する定数と、条件式の入力及び出力結果に対応する変数及び定数とを導出する。そして、スマートコントラクト生成部１０３は、導出した条件式、変数及び定数を用いて、ブロックチェーン上で実行可能な、一意の入力値に対して一意の出力を返すプログラムに編集することで、医療判断支援スマートコントラクトを生成する。
　なお、本実施の形態では、スマートコントラクト生成部１０３は、Ethereumベースのブロックチェーン上で実行可能なスクリプト言語であるSolidityで記述した条件式と、導出した定数及び変数へのアクセス方法とを、バイナリ化されたプログラムとして生成する。そして、スマートコントラクト生成部１０３は、生成したバイナリ化されたプログラムを、医療判断支援スマートコントラクトとして、ブロックチェーン制御部１０４に送信する。
　＜ブロックチェーン制御部１０４＞
　ブロックチェーン制御部１０４は、ブロックチェーンネットワークの形成、トランザクションデータの生成、分散台帳の同期またはコンセンサスアルゴリズムの実行を制御する。また、ブロックチェーン制御部１０４は、それぞれの制御結果を記憶部１０６に記憶する制御も行う。
　本実施の形態では、ブロックチェーン制御部１０４は、センサ情報取得部１０２から受信した例えばセンサから得られる患者の生体情報などのセンサ情報を含むトランザクションデータを生成する。また、例えば、ブロックチェーン制御部１０４は、スマートコントラクト生成部１０３が生成した医療判断支援スマートコントラクトを含むトランザクションデータを生成する。なお、以下では、センサから得られる患者の生体情報などのセンサ情報を含むトランザクションデータを、患者の容体を示すトランザクションデータまたは容体トランザクションデータと称する。また、医療判断支援スマートコントラクトを含むトランザクションデータを第３トランザクションデータとも称する。ブロックチェーン制御部１０４は、容体トランザクションデータを生成する際、宛先アドレスに、医療判断支援スマートコントラクトのアドレスを示すコントラクトアドレスを含める。詳細は後述する。
　ここで、ブロックチェーンのデータ構造について説明する。
　図３は、ブロックチェーンのデータ構造を示す説明図である。
　ブロックチェーンは、その記録単位であるブロックがチェーン（鎖）状に接続されたものである。それぞれのブロックは、複数のトランザクションデータと、直前のブロックのハッシュ値とを有している。具体的には、ブロックＢ２には、その前のブロックＢ１のハッシュ値が含まれている。そして、ブロックＢ２に含まれる複数のトランザクションデータと、ブロックＢ１のハッシュ値とから演算されたハッシュ値が、ブロックＢ２のハッシュ値として、ブロックＢ３に含められる。このように、前のブロックの内容をハッシュ値として含めながら、ブロックをチェーン状に接続することで、接続されたトランザクションデータの改ざんを有効に防止する。
　仮に過去のトランザクションデータが変更されると、ブロックのハッシュ値が変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。
　続いて、ブロックチェーンプラットフォームにスマートコントラクトの実装を前提としたEthereumを選択した場合を例にあげて説明する。
　ブロックチェーン制御部１０４は、規定のブロックチェーンプロトコルに即してPeer-to-Peerの通信を確立することで、ブロックチェーンネットワークの形成を制御する。
　また、ブロックチェーン制御部１０４は、スマートコントラクト生成部１０３が生成した医療判断支援スマートコントラクトのバイナリデータを受信し、これを内容データとして含むトランザクションデータを生成する。また、ブロックチェーン制御部１０４は、スマートコントラクト生成部１０３が生成したセンサ情報を受信し、これを含むトランザクションデータを生成する。なお、詳細は後述するが、ブロックチェーン制御部１０４は、トランザクションデータを生成する際、患者端末１０に紐づくブロックチェーンアドレスを、宛先アドレスを送り先アドレスとして含める。そして、ブロックチェーン制御部１０４は、生成したトランザクションデータを患者端末１０の分散台帳に格納（記録）する。
　このようにして、ブロックチェーン制御部１０４は、トランザクションデータの生成を制御する。生成されたトランザクションデータは、ブロックチェーンネットワーク内のアドレス間で送受信される。なお、生成したトランザクションデータは、ブロックチェーン制御部１０４または患者端末１０固有の署名をさらに含む。
　また、ブロックチェーン制御部１０４は、生成したトランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行し、正当性について合意された場合、当該トランザクションデータを含むブロックを分散台帳に記録する。本実施の形態では、ブロックチェーン制御部１０４は、コンセンサスアルゴリズムを実行することでブロックへの取り込みを確定させ、分散台帳に記録する。
　ところで、Ethereumなどでは、スマートコントラクトは、ブロックチェーン上に展開されるコードである。このため、スマートコントラクトのバイナリデータを含むトランザクションデータは、nullアドレスに送信されることで、スマートコントラクトをデプロイすることができる。なお、スマートコントラクトをデプロイするとは、スマートコントラクトの実態であるスマートコントラクトのプログラムをブロックチェーンネットワーク上に展開させることである。一方、スマートコントラクトを実行するための情報または履歴として残すための情報を含むトランザクションデータは、ブロードキャストされることで、コンセンサスアルゴリズムを経て、分散台帳に格納される。
　本実施の形態では、ブロックチェーン制御部１０４は、新たに生成したトランザクションデータを、ブロックチェーンネットワークを構成する他のノードである医師端末２０とサーバ装置３０に、当該トランザクションデータをブロードキャストする。そして、ブロックチェーン制御部１０４は、ブロックチェーンネットワークを構成するすべてのノードと同期して、新たに生成したトランザクションデータを分散台帳に格納する。また、ブロックチェーン制御部１０４は、ブロックチェーンネットワークを構成するすべてのノード間でコンセンサスアルゴリズムを実行することで新たに生成したトランザクションデータをブロックに取り込んで確定させるかどうかを判定する。
　このようにして、ブロックチェーン制御部１０４は、第３トランザクションデータを含むブロックを前記分散台帳に格納し、第３トランザクションデータには、第３トランザクションデータの真贋性を証明するための署名が含まれている。
　＜表示部１０５＞
　表示部１０５は、患者の操作等により入力されるテキストデータ、音声データを取得したり、患者により入力されるデータをインタラクティブに表示する。表示部１０５は、さらに入力装置（不図示）を備えたインタフェースとして機能してもよい。
　また、表示部１０５は、通信部１０１を介して取得した医療提案サブセットなどのデータを用いて、医師と合議しながら、患者が意思表示できない状況における医療処置に対する事前の患者の意思表明を決めるための質問などを表示する。
　また、表示部１０５は、患者と医師とが合議した結果得た医療処置を表示したり、スマートコントラクト生成部１０３が生成した医療判断支援スマートコントラクトの内容を患者等のユーザが理解できる形で表示したりする。なお、表示部１０５は、視覚的な表示を行う場合に限らず、表示内容を聴覚的、触覚的にユーザへ伝えてもよい。
　＜記憶部１０６＞
　記憶部１０６は、センサ情報取得部１０２が取得したセンサ情報、スマートコントラクト生成部１０３が生成した医療判断支援スマートコントラクト、患者の操作等により入力されるテキストデータ、音声データ、及び、患者により入力されるデータを記憶する。
　また、記憶部１０６は、分散台帳を有する図１に示す記憶装置であってもよい。この場合、記憶部１０６には、分散台帳領域が区画され、当該分散台帳領域に分散台帳を有すればよい。
　［１．３　医師端末２０の構成］
　医師端末２０は、例えば医師が使用するＰＣ等の端末であるが、これに限られない。医師端末２０は、分散台帳を有し、ブロックチェーンネットワークを構成することができ、かつ、医師が使用するまたは医師と直接通信を行うことができれば、端末に限らずサーバであってもよい。
　図４は、本実施の形態に係る医師端末２０の構成の一例を示すブロック図である。
　医師端末２０は、図４に示すように、通信部２０１と、医師見解生成部２０２と、ブロックチェーン制御部２０３と、表示部２０４と、記憶部２０５とを備える。
　＜通信部２０１＞
　通信部２０１は、通信ネットワーク４０を介して、患者端末１０及びサーバ装置３０と通信を行う。また、通信部２０１は、医師が使用するキーボード、マイクなどの入力装置と通信する。
　通信部２０１は、例えば、医師の操作等により入力されるテキストデータ、音声データを取得したり、表示部２０４とインタラクティブに医師により入力されるデータを取得したりする。
　＜医師見解生成部２０２＞
　医師見解生成部２０２は、医師の操作等により入力されるデータに基づき医師による診断結果を、医師による見解として生成する。医師による診断結果には、上述した医学的ファクトが示されている。
　本実施の形態では、医師見解生成部２０２は、センサから得られる前記患者の生体情報に対する医師の診断結果に関する情報を生成する。より詳細には、医師見解生成部２０２は、患者端末１０から取得した生体情報に対する医師の診断結果を生成する。医師見解生成部２０２は、生成した医師の診断結果を、医療判断支援スマートコントラクトに即した数値または等号で記述される様式に変換する。医師見解生成部２０２は、変換した医師の診断結果を、医師の診断結果に関する情報としてブロックチェーン制御部２０３に送信する。
　また、医師見解生成部２０２は、医師の操作等により入力されるデータに基づき、医師が患者に対して実施した医療処置に関する情報である医療処置結果情報を、医師による見解として生成する。
　＜ブロックチェーン制御部２０３＞
　ブロックチェーン制御部２０３は、ブロックチェーンネットワークの形成、トランザクションデータの生成、分散台帳の同期またはコンセンサスアルゴリズムの実行を制御する。また、ブロックチェーン制御部２０３は、それぞれの制御結果を記憶部２０５に記憶する制御も行う。
　本実施の形態では、ブロックチェーン制御部２０３は、医師見解生成部２０２が生成した医師の診断結果に関する情報を含むトランザクションデータを生成する。また、例えば、ブロックチェーン制御部２０３は、スマートコントラクト生成部１０３が生成した医療処置結果情報を含むトランザクションデータを生成する。なお、以下では、医師の診断結果に関する情報を含むトランザクションデータを、医師の見解を示すトランザクションデータまたは見解トランザクションデータと称する。また、医療処置結果情報を含むトランザクションデータを、医療処置実施結果トランザクションデータと称する。ブロックチェーン制御部２０３は、見解トランザクションデータを生成する際、宛先アドレスに、医療判断支援スマートコントラクトのアドレスを示すコントラクトアドレスを含める。詳細は後述する。
　なお、ブロックチェーン制御部２０３のその他の制御については、患者端末１０におけるブロックチェーン制御部１０４と同様であるため、ここでの詳細説明は省略する。
　＜表示部２０４＞
　表示部２０４は、医師の操作等により入力されるテキストデータ、音声データを取得したり、医師により入力されるデータをインタラクティブに表示する。表示部２０４は、さらに入力装置（不図示）を備えたインタフェースとして機能してもよい。
　また、表示部２０４は、通信部１０１を介して取得した医療提案サブセットなどのデータを用いて、患者端末１０に同期して、患者端末１０が表示する質問を表示してもよい。患者端末１０が表示する質問は、上述したように、患者が意思表示できない状況における医療処置に対する事前の患者の意思表明を決めるための患者への質問などである。
　＜記憶部２０５＞
　記憶部２０５は、医師見解生成部２０２が生成した医師による見解、医師の操作等により入力されるテキストデータ、音声データ、及び、患者により入力されるデータを記憶する。
　また、記憶部２０５は、分散台帳を有する図１に示す記憶装置であってもよい。この場合、記憶部２０５には、分散台帳領域が区画され、当該分散台帳領域に分散台帳を有すればよい。
　［１．４　ブロックチェーンネットワーク内のアドレス構成］
　図５は、本実施の形態に係る分散台帳に保持されるブロックチェーンネットワーク内のアドレス構成を示す図である。
　ブロックチェーンアドレスは、ブロックチェーンネットワークを構成するノードそれぞれに付与された情報であり、当該ノードを一意に特定できる情報である。図５に示される患者アドレス１１は、患者端末１０に付与されたブロックチェーンアドレスである。同様に、図５に示される医師アドレス２１は、医師端末２０に付与されたブロックチェーンアドレスであり、サーバアドレス３１は、サーバ装置３０に付与されたブロックチェーンアドレスである。
　一方、図５に示される医療判断支援コントラクトアドレス３２は、ブロックチェーンネットワークにデプロイされた医療判断支援スマートコントラクトに与えれた固有のアドレスである。当該固有のアドレスを参照することができれば、医療判断支援スマートコントラクトを実行することができる。
　なお、図５に示すアドレス構成では、患者アドレス１１、医師アドレス２１、サーバアドレス３１及び医療判断支援コントラクトアドレス３２が、分散台帳に保持されることで、トランザクションデータを生成する際に利用可能であることを示している。
　［１．５　トランザクションデータのデータ構造］
　本実施の形態では、トランザクションデータは、宛先アドレス、送信元アドレス、内容データを含んで構成されるが、これらの情報を含めば別の形態をとってもよい。
　図６は、本実施の形態に係る第３トランザクションデータのデータ構造を概念的に示す図である。第３トランザクションデータは、医療判断支援スマートコントラクトを含むトランザクションデータであり、患者端末１０のブロックチェーン制御部１０４により生成される。医療判断支援スマートコントラクトは、上述したように、容体トランザクションデータ及び見解トランザクションデータを入力値として、医療処置判断を実行するための条件式を含む記述を有するプログラムである。
　図６に示すように、第３トランザクションデータは、宛先アドレス、内容データ及び送信元アドレスを含んで構成される。宛先アドレス及び送信元アドレスには、共に患者アドレス１１が含まれる。Ethereumなどではスマートコントラクトをデプロイするためにトランザクションデータがnullアドレスに送信される必要があるためである。また、内容データには、医療判断支援スマートコントラクトバイナリプログラムすなわちバイナリ化されたプログラムとして生成された医療判断支援スマートコントラクトが含まれる。なお、内容データには、プログラム化された医療判断支援スマートコントラクトであればバイナリプログラムでなくてもよい。
　患者端末１０は、このようなデータ構造の第３トランザクションデータを生成し、自分自身に送信することで、医療判断支援スマートコントラクトを、ブロックチェーンネットワークにデプロイする。なお、第３トランザクションデータの内容データには、さらに、第１トランザクションデータの真贋性を証明するための署名（不図示）が含まれる。
　続いて、医療判断支援スマートコントラクトへの入力となるトランザクションデータすなわち患者の容体を示すトランザクションデータと医師の見解を示すトランザクションデータとのデータ構造について説明する。以下、患者の容体を示すトランザクションデータと医師の見解を示すトランザクションデータとを容体トランザクションデータと見解トランザクションデータと称して説明する。
　図７は、本実施の形態に係る容体トランザクションデータのデータ構造を概念的に示す図である。
　図７に示すように、容体トランザクションデータは、宛先アドレス、内容データ及び送信元アドレスを含んで構成される。宛先アドレスには、医療判断支援コントラクトアドレス３２が含まれ、送信元アドレスには、患者アドレス１１が含まれる。また、内容データには、患者の容体を示す情報と、送信元である患者端末１０の署名とが含まれる。患者の容体を示す情報は、例えば患者のバイタルデータなど患者の容体を示す医学的ファクトである。署名は、容体トランザクションデータの真贋性を証明するために用いられる。署名は、例えば患者の容体を示す値のダイジェスト値を秘密鍵で暗号化されたものであってもよい。この場合、公開鍵は別途分散台帳に格納され公開されていればよい。
　患者端末１０は、このようなデータ構造の容体トランザクションデータを生成し、医療判断支援コントラクトアドレス３２に送信する。
　図８は、本実施の形態に係る見解トランザクションデータのデータ構造を概念的に示す図である。
　図８に示すように、見解トランザクションデータは、宛先アドレス、内容データ及び送信元アドレスを含んで構成される。宛先アドレスには、医療判断支援コントラクトアドレス３２が含まれ、送信元アドレスには、医師アドレス２１が含まれる。内容データには、医師の見解を示す情報と、送信元である医師端末２０の署名とが含まれる。医師の見解を示す情報は、例えば患者の容体に対する医師の診断結果であり、患者の容体を示す医学的ファクトに対して医療判断支援スマートコントラクトを実行させるための見解をさらに含んでいてもよい。署名は、見解トランザクションデータの真贋性を証明するために用いられる。署名は、例えば医師の見解を示す値のダイジェスト値を秘密鍵で暗号化されたものであってもよい。この場合、公開鍵は別途分散台帳に格納され公開されていればよい。
　医師端末２０は、このようなデータ構造の見解トランザクションデータを生成し、医療判断支援コントラクトアドレス３２に送信する。
　このような容体トランザクションデータ及び見解トランザクションデータが医療判断支援コントラクトアドレス３２に送信されることで、医療判断支援スマートコントラクトを実行させることができる。これにより、医療判断支援スマートコントラクトに患者に施されるべき医療処置に関する医療提案情報を含む医療提案トランザクションデータを出力させることができる。
　なお、医療提案トランザクションデータは、図示しないが、宛先アドレス、内容データ及び送信元アドレスを含んで構成される。内容データには、医療提案情報が含まれ、宛先アドレスには、医師アドレス２１が含まれる。送信元アドレスには、医療判断支援コントラクトアドレス３２または医療判断支援スマートコントラクトを実行させたノードのブロックチェーンアドレスが含まれる。
　続いて、本実施の形態に係る医療判断支援スマートコントラクトのアルゴリズムの概要について説明する。
　［１．６　医療判断支援スマートコントラクトのアルゴリズム］
　図９は、本実施の形態に係る医療判断支援スマートのアルゴリズムを概念的に示す図である。
　医療判断支援スマートコントラクトは、上述したように、患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化されたスマートコントラクトである。実行させることで患者に施されるべき医療処置に関する医療提案情報を出力する。ここで、患者と医師とが合議した結果得た医療処置判断を実行することは、患者本人による意思表明が不可能な状況下において事前の患者の意思を考慮した患者に施されるべき医療処置を決定して出力することである。つまり、医療判断支援スマートコントラクトは、実行させることで、患者本人による意思表明が不可能な状況下において事前の患者の意思を考慮した患者に施されるべき医療処置を決定して医療提案情報として出力するようにプログラムされたスマートコントラクトである。
　より具体的には、医療判断支援スマートコントラクトのアルゴリズムは、図９に示すように、条件０～２で示されるような条件分岐と、条件により選択される医療提案サブセット１－１～２－２で示されるような医療処置の組み合わせを示す変数／定数とを含めて構成される。また、医療判断支援スマートコントラクトのアルゴリズムには、患者本人による意思表明が不可能な状況下における患者の容体を示す容体トランザクションデータとそれに対する医師の見解を示す見解トランザクションデータとが入力となる条件式を含む。さらに、これらのトランザクションデータに含まれる署名の正当性等を確認したことを条件として上記の条件０～２に進む条件式を含んでいる。また、医療判断支援スマートコントラクトのアルゴリズムには、これらのトランザクションデータが入力された場合に、患者に施されるべき医療処置に関する医療提案情報を一つの出力として導出される条件式も含まれている。
　換言すると、図９に示されるように、医療判断支援スマートコントラクトのアルゴリズムには、上記２つのトランザクションデータの入力ステップと、上記２つのトランザクションデータそれぞれに含まれる署名を確認する署名確認ステップとを含んでいる。また、医療判断支援スマートコントラクトのアルゴリズムは、条件０～２で示される３つの条件分岐による医療提案サブセットの選定ステップと、医療提案情報の出力ステップとを含んでいる。
　続いて、医療判断支援スマートコントラクトのアルゴリズムの処理フローについて説明する。
　まず、患者の容体トランザクションデータと医師の見解トランザクションデータが医療判断支援コントラクトアドレス３２に送信されると、医療判断支援スマートコントラクトの入力ステップが実行される。入力ステップでは、容体トランザクションデータに含まれる患者の容体を示す情報と見解トランザクションデータに含まれる医師の見解を示す情報とが、変数に代入される形式で保持される。
　次に、医療判断支援スマートコントラクトは、署名確認ステップを実行する。署名確認ステップでは、医療判断支援スマートコントラクトに定数として登録されているトランザクションデータの真贋性を証明するための署名と、容体トランザクションデータ、見解トランザクションデータそれぞれの内容データに含まれる署名とが一致するかの検証を行う。なお、トランザクションデータの真贋性を証明するための署名である登録済み署名は、医療判断支援スマートコントラクトがデプロイされる際に定数として登録される。
　署名確認ステップでは、検証の結果、登録済み署名と容体トランザクションデータ、見解トランザクションデータそれぞれの内容データに含まれる署名すなわち入力署名とが一致している場合のみ、次の選定ステップを実行する。一方、検証の結果、登録済み署名と入力署名とが一致しない場合には、処理を中断し、医療判断支援スマートコントラクトの変数を初期化する。つまり、医療判断支援スマートコントラクトの実行を中止する。なお、医療判断支援スマートコントラクトの実行を中止したことを、患者端末１０及び医師端末２０に通知してもよい。この場合、医療判断支援スマートコントラクトは、患者アドレス１１及び医師アドレス２１を含み、実行を中止したことを示すアラートトランザクションデータを生成すればよい。
　医療提案サブセットの選定ステップでは、医療判断支援スマートコントラクトに予め登録されている条件式に従って、予め登録されている複数の医療提案サブセットのうちから１つの医療提案サブセットを選択する。医療判断支援スマートコントラクトに予め登録されている条件式は、患者と医師とが合議した結果得た医療処置判断を実行するための条件式である。この条件式に容体トランザクションデータ及び見解トランザクションデータに含まれる内容データを代入すると、１つの医療提案サブセットを選択する。
　図９に示す例では、条件０～２で示される３つの条件分岐それぞれにより２つのケースを選択している。このため、医療判断支援スマートコントラクトに予め登録されている条件式は３つであり、予め登録されている複数の医療提案サブセットは４つである。
　医療提案情報の出力ステップでは、選定ステップで選定した１つの医療提案サブセットを示す医療提案情報を内容データに含む医療提案トランザクションデータを生成して出力する。ここで、医療判断支援スマートコントラクトは、宛先アドレスには医師アドレス２１、送信元アドレスには医療判断支援コントラクトアドレス３２を含む医療提案トランザクションデータを生成する。
　医療提案トランザクションデータの内容データに含まれる医療提案サブセットは、医師端末２０を介して医師に共有され、医師はこの医療提案サブセットに即した医療処置を実施する。
　なお、医療判断支援スマートコントラクトに、医療実施結果を記録ステップをさらに含めてもよい。また、医療判断支援スマートコントラクトと異なるスマートコントラクトに医療実施結果を記録ステップが記述されているとしてもよい。いずれのスマートコントラクトを用いる場合でも、上記の署名確認ステップと同様に、まず、医療提案トランザクションデータと医療提案サブセットに基づき医師により実施された医療処置を示すトランザクションデータとの署名を確認すればよい。そして、医療提案トランザクションデータに示される医療提案サブセットと医師により実施された医療処置とを紐づけて分散台帳に記録（格納）すればよい。
　（実施例１）
　続いて、患者と医師とが合議した結果得た医療処置として現行POLST書式に即した医療処置サブセットが、医療判断支援スマートコントラクトに予め登録されている場合について説明する。
　図１０は、実施例１に係る医療判断支援スマートコントラクトのアルゴリズムを概念的に示す図である。図１０には、医療判断支援スマートコントラクトが実行されることで、現行POLST書式に即した医療処置サブセットが選定されるアルゴリズムが概念的に示されている。
　まず、患者の容体トランザクションデータと医師の見解トランザクションデータが医療判断支援コントラクトアドレス３２に送信されると、医療判断支援スマートコントラクトの入力ステップが実行される。入力ステップでは、患者本人による意思表明が不可能な状況下における患者の容体を示す情報と、その状況下での患者についての医師の見解を示す情報を入力値として保持する。
　次に、医療判断支援スマートコントラクトは、署名確認ステップを実行し、登録済み署名と、容体トランザクションデータ及び見解トランザクションデータそれぞれの内容データに含まれる入力署名と一致しているかを確認することで、入力値の信頼性を検証する。
　次に、医療判断支援スマートコントラクトは、選定ステップを実行する。患者の容体が心肺停止を示す場合、事前条件を参照し外傷の影響を示すか否かに応じて患者及び医師が事前に合議した医療処置に即した医療提案サブセットを選択する。例えば、患者が心肺停止の状態で、かつ、患者に外傷の影響はないという医師の見解が示されている場合には、医療提案サブセットとして、「すべての心肺蘇生術を実施」することを選択する。また、例えば、患者が心肺停止の状態で、かつ、患者に外傷により重度後遺症が残るという医師の見解が示されている場合には、医療提案サブセットとして、軽度の「心肺蘇生術」を実施することを選択する。
　一方、患者の容体が心配停止でないことを示す場合、事前条件を参照し重度後遺症が残るか否かに応じて患者及び医師が事前に合議した医療処置に即した医療提案サブセットを選択する。例えば、患者が心肺停止でない状態で、かつ、患者に重度後遺症が残るという医師の見解が示されている場合には、医療提案サブセットとして、「苦痛緩和処理」を選択する。また、例えば、患者が心肺停止でない状態で、かつ、患者に重度後遺症はないという医師の見解が示されている場合には、医療提案サブセットとして、「侵襲的医療を含む医療処置」を選択する。
　なお、医療判断支援スマートコントラクトに予め登録された医療処置サブセットそれぞれには、固有の識別子が保持されており、この識別子で選択された医療処置サブセットが示す医療処置の識別を図ることができる。このため、医療判断支援スマートコントラクトは、選択した医療処置サブセットを示す識別子を、出力ステップに伝達すればよい。
　出力ステップでは、選定ステップで選定した１つの医療提案サブセットを示す識別子を医療提案情報として内容データに含む医療提案トランザクションデータを生成して出力する。
　これにより、医師は医療提案トランザクションデータで示される医療提案サブセットに基づいた医療処置を実施することで、患者の事前の意思表明を考慮した医療処置を実施できる。
　なお、医療判断支援スマートコントラクトに、医療実施結果を記録ステップをさらに含んでいてもよい（不図示）。この場合、送信元アドレスに医師アドレス２１、内容データに医療処置の実施結果を含むトランザクションデータが発行されるとする。医療判断支援スマートコントラクトは、記録ステップにおいて、選定した１つの医療提案サブセットを示す識別子と、医療処置の実施結果とを紐づけて、分散台帳に記録すればよい。
　（実施例２）
　続いて、患者と医師とが合議した結果得た医療処置として現行リビングウィル書式に即した医療処置サブセットが、医療判断支援スマートコントラクトに予め登録されている場合について説明する。なお、以下では、実施例１と同様のところの説明は省略する。
　図１１は、実施例２に係る医療判断支援スマートコントラクトのアルゴリズムを概念的に示す図である。図１１には、医療判断支援スマートコントラクトが実行されることで、現行リビングウィル書式に即した医療処置サブセットが選定されるアルゴリズムが概念的に示されている。
　まず、患者の容体トランザクションデータと医師の見解トランザクションデータが医療判断支援コントラクトアドレス３２に送信されると、医療判断支援スマートコントラクトの入力ステップが実行される。入力ステップでは、患者本人による意思表明が不可能な状況下における患者の容体を示す情報と、その状況下での患者についての医師の見解を示す情報を入力値として保持する。
　次に、医療判断支援スマートコントラクトは、署名確認ステップを実行し、登録済み署名と、容体トランザクションデータ及び見解トランザクションデータそれぞれの内容データに含まれる入力署名と一致しているかを確認することで、入力値の信頼性を検証する。
　次に、医療判断支援スマートコントラクトは、選定ステップを実行する。患者の容体から意識回復が見込めない場合、事前条件を参照し外傷と内臓損傷との有無に応じて患者及び医師が事前に合議した医療処置に即した医療提案サブセットを選択する。
　例えば、患者の意識回復が見込めない状態で、かつ、患者に外傷がなく内臓損傷もないという医師の見解が示されている場合には、医療提案サブセットとして、「すべての心肺蘇生術を実施」することを選択する。また、例えば、患者の意識回復が見込めない状態で、かつ、患者に外傷はないものの内臓損傷があるという医師の見解が示されている場合には、医療提案サブセットとして、「胃瘻による継続的な栄養補給を希望」を実施することを選択する。
　また、例えば、患者の意識回復が見込めない状態で、かつ、患者に外傷があるものの内臓損傷はないという医師の見解が示されている場合には、医療提案サブセットとして、「点滴による水分補給を希望」を実施することを選択する。また、例えば、患者の意識回復が見込めない状態で、かつ、患者に外傷も内臓損傷もあるという医師の見解が示されている場合には、医療提案サブセットとして、「水分・栄養補給はせず自然な最期を迎え」てもらうことを選択する。
　なお、上記の実施例１及び実施例２では、現行POLST書式及び現行リビングウィル書式に基づいた医療判断支援スマートコントラクトのアルゴリズムの処理フローについて説明したが、これに限らない。
　医療判断支援スマートコントラクトには、さらに、医療処置の料金に応じて、処置内容を選択する処理フローを含んでいてもよい。また、医療判断支援スマートコントラクトには、医療処置の料金に応じて、処置内容を選択する処理フローを行う際、さらに、その保険金または患者自身の口座残高を参照する処理フローを含んでいてもよい。
　［１．７　サーバ装置の構成］
　図１２は、本実施の形態に係るサーバ装置３０の構成の一例を示すブロック図である。
　サーバ装置３０は、図１２に示すように、通信部３０１と、記憶部３０２と、ブロックチェーン制御部３０３と、データベース部３０４と、ワーキングメモリ３０５とを備える。サーバ装置３０は、プロセッサがメモリを用いて所定のプログラムを実行することで実現され得る。以下、各構成要素について説明する。
　＜通信部３０１＞
　通信部３０１は、通信ネットワーク４０を介して、患者端末１０及び医師端末２０と、医学的ファクトの通信を行う。また、通信部３０１は、サーバ装置３０が受信した医学的ファクトを記憶部３０２に記録させてもよい。
　本実施の形態では、通信部３０１は、例えば、患者端末１０から医療判断支援スマートコントラクトを含む第３トランザクションデータまたは容体トランザクションデータを取得する。また、通信部３０１は、医師端末２０から見解トランザクションデータを取得したり、医療処置実施結果トランザクションデータを取得したりする。また、通信部３０１は、医療判断支援スマートコントラクトが出力した医療提案トランザクションデータを医師端末２０に送信する。
　＜記憶部３０２＞
　記憶部３０２は、例えば医療判断支援スマートコントラクトが出力した医療提案トランザクションデータを記憶する。また、記憶部３０２は、ブロックチェーン制御部３０３の制御結果を記憶する。
　なお、記憶部３０２は、分散台帳を有する図１に示す記憶装置であってもよい。この場合、記憶部３０２には、分散台帳領域が区画され、当該分散台帳領域に分散台帳を有すればよい。なお、記憶部３０２は、ワーキングメモリ３０５を有していてもよい。この場合、記憶部３０２には、ワーキングメモリ領域が区画されればよい。
　＜ブロックチェーン制御部３０３＞
　ブロックチェーン制御部３０３は、ブロックチェーンネットワークの形成、トランザクションデータの生成、分散台帳の同期またはコンセンサスアルゴリズムの実行を制御する。また、ブロックチェーン制御部３０３は、それぞれの制御結果を記憶部３０２に記憶する制御も行う。
　本実施の形態では、ブロックチェーン制御部３０３は、容体トランザクションデータに含まれる患者の生体情報及び見解トランザクションデータに含まれる患者の生体情報に対する医師の診断結果とに基づき、医療判断支援スマートコントラクトを実行させる。また、ブロックチェーン制御部３０３は、医療判断支援スマートコントラクトを実行させることで医療判断支援スマートコントラクトから得られた、患者に施されるべき医療処置に関する提案情報を出力する。
　また、ブロックチェーン制御部３０３は、コンセンサスアルゴリズムを実行し、医師端末２０から取得した医療処置実施結果トランザクションデータを分散台帳に格納する。
　また、ブロックチェーン制御部３０３は、医師端末２０から取得した医療処置実施結果トランザクションデータと、医療判断支援スマートコントラクトが出力した医療提案トランザクションデータとを紐づける。より詳細には、ブロックチェーン制御部３０３は、医療処置実施結果トランザクションデータに含まれる医療措置実施結果と、医療提案トランザクションデータに含まれる医療提案サブセットとを紐づける情報を記憶部３０２に記憶させる。なお、ブロックチェーン制御部３０３は、医療措置実施結果と医療提案サブセットとを紐づけた情報を、医療判断支援スマートコントラクトとは別のスマートコントラクトを実行させて、分散台帳に格納させてもよい。
　ブロックチェーン制御部３０３のその他の制御については、患者端末１０におけるブロックチェーン制御部１０４と同様であるため、ここでの詳細説明は省略する。
　＜データベース部３０４＞
　データベース部３０４は、医学的ファクトのデータベースとして機能する。データベース部３０４には、医学的ファクトとして、レセプトデータなどの医療情報が記録されていてもよい。
　また、データベース部３０４は、例えば、通信部３０１を介して、患者端末１０及び医師端末２０に、医学的ファクトうち提案可能な医療処置の組み合わせを示すデータを医療提案サブセットとして送信する。なお、データベース部３０４は、ブロックチェーン制御部３０３で受信したトランザクションに含まれる内容データに示される医学的ファクトについて管理し、記憶部３０２に記憶する。
　＜ワーキングメモリ３０５＞
　ワーキングメモリ３０５は、サーバ装置３０のオンメモリとして機能するメモリである。ワーキングメモリ３０５は、分散台帳に記録されたブロックを読み出して、スマートコントラクトを保持することで、スマートコントラクトを稼働させる。なお、ワーキングメモリ３０５は、スマートコントラクトを指し示すコントラクトアドレスを保持してもよい。
　本実施の形態では、ワーキングメモリ３０５は、医療判断支援スマートコントラクトを指し示すコントラクトアドレスである医療判断支援コントラクトアドレス３２を保持してもよい。さらに、ワーキングメモリ３０５は、稼働状態の医療判断支援スマートコントラクトを保持してもよい。
　［１．８　医療処置管理システムの動作等］
　次に、以上のように構成された医療処置管理システム１の動作の概要について説明する。
　図１３Ａは、本実施の形態に係る医療処置管理システム１の患者の意思表明を分散台帳に格納するまでの動作の概要を示す図である。
　まず、ステップＳ１において、医療処置管理システム１は、患者と医師とに、医療処置の合議を行わせる。より具体的には、医療処置管理システム１は、患者と医師とに、患者本人による意思表明が不可能な状況下における患者の意思に沿った医療処置を合議させる。
　本実施の形態では、患者端末１０は、例えば現行POLST書式に即した医療処置サブセットを取得し、患者が意思表示できない状況における医療処置に対する事前の患者の意思表明を決めるための質問などを表示する。患者は、医師と合議しながら、患者端末１０により表示される質問に答える形で、患者本人による意思表明が不可能な状況下における患者の意思に沿った医療処置を決定する。決定された医療処置は、患者と医師とが合議した結果得た、患者本人が事前に意思表明した医療処置判断となる。
　次に、ステップＳ２において、医療処置管理システム１は、ステップＳ２において医療処置の合議を行った結果に基づいて、医療判断支援スマートコントラクトの生成を行う。より具体的には、医療処置管理システム１は、患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化された医療判断支援スマートコントラクトを生成する。
　次に、ステップＳ３において、医療処置管理システム１は、ステップＳ２において生成した医療判断支援スマートコントラクトの稼働を行う。より具体的には、医療処置管理システム１は、ステップＳ２において生成した医療判断支援スマートコントラクトを分散台帳に格納してデプロイすることで、医療判断支援スマートコントラクトを稼働させる。
　このように、医療処置管理システム１は、患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化された医療判断支援スマートコントラクトを分散台帳に格納して稼働させることで、患者の意思表明を、分散台帳に格納する。
　図１３Ｂは、本実施の形態に係る医療処置管理システム１の分散台帳に格納された患者の意思に沿った医療措置を決定して実施したかを検証可能に記録するまでの動作の概要を示す図である。
　まず、ステップＳ４では、患者が医療処置を必要とするインシデントが発生したとする。ここで、インシデントが発生したとは、ステップＳ１で医師と医療処置の合議を行った患者が医療処置を必要とし、患者のバイタルデータが異常であるなど医療処置管理システム１を利用する必要がある状況が発生したことを意味する。この場合、医療処置管理システム１は、患者のセンサ情報を含む容体トランザクションデータと患者の生体情報に対する医師の診断結果に関する情報を含む見解トランザクションデータとを生成する。
　次に、ステップＳ５では、医療判断支援スマートコントラクトが実行される。より具体的には、医療処置管理システム１は、ステップＳ４において生成した容体トランザクションデータ及び見解トランザクションデータを分散台帳に格納することで、医療判断支援スマートコントラクトを実行させる。
　次に、ステップＳ６では、医療判断支援スマートコントラクトは、実行結果として、患者への医療処置提案を出力する。より具体的には、医療判断支援スマートコントラクトは、容体トランザクションデータ及び見解トランザクションデータを入力として、一意に決定された提案情報であって患者に施されるべき医療処置に関する提案情報を出力する。
　次に、ステップＳ７では、ステップＳ６において出力された患者に施されるべき医療処置に関する提案情報に基づいて、医師により患者への医療処置が実施される。医師は、患者へ実施した医療処置に関する情報を、医療処置の実施結果として医療処置管理システム１に入力する。
　最後に、ステップＳ８では、ステップＳ７における医療処置の実施結果が記録される。より具体的には、医療処置管理システム１は、ステップＳ７における医療処置の実施結果を、ステップＳ６において出力された患者に施されるべき医療処置に関する提案情報と対応させて分散台帳に格納する。
　このようにして、医療処置管理システム１は、患者の意思を反映した医療処置プロセスの改ざん困難性、信頼性を担保することができる。すなわち、医療処置管理システム１は、改竄が極めて困難なブロックチェーンに、患者の意思表明を含む医療処置判断と医療処置判断結果に基づく医療処置の実施結果とを参照可能に記録する。これにより、患者らの事前の意思表明を考慮した医療処置を決定して実施したかどうかを検証できる。
　［１．８．１　医療判断支援スマートコントラクトのデプロイシーケンス］
　続いて、医療処置管理システム１において医療判断支援スマートコントラクトが生成されてデプロイされるまでのシーケンスについて説明する。
　図１４は、本実施の形態に係る医療処置管理システム１により医療判断支援スマートコントラクトが生成されて稼働するまでのシーケンスを示す図である。
　まず、サーバ装置３０は、医療提案サブセットを送信する（Ｓ１０１）。本実施の形態では、サーバ装置３０は、患者の事前の意思表明に用いられるリビングウィル書式またはPOLST書式などに則した医学的ファクトと医療処置の組み合わせとを示す医療提案サブセットを送信する。
　次に、患者は患者端末１０を、医師は医師端末２０を用いて、患者と医師とで医療処置の合議を行う（Ｓ１０２）。ここでは、医療判断支援スマートコントラクトの生成にも用いられる医療処置判断すなわち患者本人が事前に意思表明した医療処置判断を患者と医師との合議により決定する。本実施の形態では、患者端末１０は、リビングウィル書式またはPOLST書式など即した医学的ファクトと医療処置の組み合わせを患者に示しながら質問し、患者は医者と合議しながら、質問に答えることで医療処置判断を決定する。なお、患者端末１０は、医療処置判断を決定する処理を行いながら、決定された医療処置判断に基づく医療判断支援スマートコントラクトを生成している。詳細については、図１３ＡのステップＳ１において説明した通りであるので、ここでの説明は省略する。
　次に、患者端末１０及び医師端末２０は、ステップＳ１０２の合議が終了したかを判断する（Ｓ１０３）。
　ステップＳ１０３のおいて、ステップＳ１０２の合議が終了したと判断した場合（Ｓ１０３でＹｅｓ）、医師端末２０は、医師端末２０の署名を送信する（Ｓ１０４）。
　次に、患者端末１０は、ステップＳ１０４において送信された医師端末２０の署名を取得する（Ｓ１０５）。
　次に、患者端末１０は、ステップＳ１０２において患者と医師とが合議した結果得た医療処置判断に基づき医療判断支援スマートコントラクトを生成する（Ｓ１０６）。本実施の形態では、患者端末１０は、ステップＳ１０２の合議において患者による医療処置判断の決定とともに、医療判断支援スマートコントラクト（のドラフト）を生成している。このため、患者端末１０は、医師端末２０の署名を取得することで、当該医療判断支援スマートコントラクトの生成を完了させるために、医療判断支援スマートコントラクトを例えばバイナリプログラムなどプログラム化する。
　次に、患者端末１０は、ステップＳ１０６において生成した医療判断支援スマートコントラクトを含む第３トランザクションデータを生成する（Ｓ１０７）。本実施の形態では、患者端末１０は、例えば図６に示すように、内容データにバイナリ化されたプログラムとして生成された医療判断支援スマートコントラクトを、宛先アドレス及び送信元アドレスに患者アドレス１１を含む第３トランザクションデータを生成する。
　次に、患者端末１０は、ステップＳ１０７において生成した第３トランザクションデータを自分自身に送信することで（Ｓ１０８）、患者端末１０が構成するブロックチェーンネットワークに医療判断支援スマートコントラクトをデプロイする（Ｓ１０９）。
　次に、医師端末２０及びサーバ装置３０は、ステップＳ１０９においてデプロイされることで送信された第３トランザクションデータを取得する（Ｓ１１０）。
　次に、患者端末１０、医師端末２０及びサーバ装置３０は、同期する。より具体的には、患者端末１０、医師端末２０及びサーバ装置３０はそれぞれ、コンセンサスアルゴリズムを実行し、ステップＳ１１０で取得した第３トランザクションデータをブロックに取り込み、そのブロックを分散台帳に格納する。
　次に、患者端末１０、医師端末２０及びサーバ装置３０は、医療判断支援スマートコントラクトを稼働させる（Ｓ１１２）。
　［１．８．２　医療判断支援スマートコントラクトの実行シーケンス］
　続いて、医療処置管理システム１において医療判断支援スマートコントラクトが実行されることで医療提案が出力され、医師による医療処置の実施結果を記録するまでのシーケンスについて説明する。
　図１５は、本実施の形態に係る医療判断支援スマートコントラクトが実行され、医療処置の実施結果が記録されるまでのシーケンスを示す図である。
　まず、患者端末１０は、患者の生体情報などのセンサ情報を取得している（Ｓ２０１）。具体的には、患者端末１０は、例えば、患者ないし患者に取り付けられたモニタデバイスから患者の生体情報などのセンサ情報を取得する。
　次に、患者端末１０は、ステップＳ２０１で取得したセンサ情報に基づき、患者のバイタルが異常であるかを確認する（Ｓ２０２）。
　ステップＳ２０２において患者のバイタルが異常である場合（Ｓ２０２でＹｅｓ）、患者端末１０は、患者の容体を示す患者のセンサ情報を含む容体トランザクションデータを生成する（Ｓ２０３）。なお、ステップＳ２０２のＹｅｓすなわち患者のバイタルが異常である場合とは、上述した図１３ＢのステップＳ４のインシデント発生の場合に該当する。本実施の形態では、患者端末１０は、例えば図７に示すように、内容データに患者の容体及び患者端末１０の署名を、宛先アドレスに医療判断支援コントラクトアドレス３２、送信元アドレスに患者アドレス１１を含む容体トランザクションデータを生成する。
　次に、患者端末１０は、ステップＳ２０３で生成した容体トランザクションデータを、ブロードキャストすることで、医師端末２０及びサーバ装置３０に送信する（Ｓ２０４）。
　次に、医師端末２０及びサーバ装置３０は、容体トランザクションデータを取得する（Ｓ２０５）。
　次に、医師端末２０は、容体トランザクションデータに含まれる患者の容体に対する医師の診断結果を取得したかを確認する（Ｓ２０７）。
　ステップＳ２０７において診断結果を取得した場合（Ｓ２０７でＹｅｓ）、医師端末２０は、医師の見解を示す上記の患者の生体情報に対する医師の診断結果に関する情報を含む見解トランザクションデータを生成する（Ｓ２０９）。本実施の形態では、医師端末２０は、例えば図８に示すように、内容データに医師の見解及び医師端末２０の署名を、宛先アドレスに医療判断支援コントラクトアドレス３２、送信元アドレスに医師アドレス２１を含む見解トランザクションデータを生成する。
　次に、医師端末２０は、ステップＳ２０８で生成した見解トランザクションデータを、サーバ装置３０に送信する（Ｓ２０９）。
　次に、サーバ装置３０は、ステップＳ２０９で送信された容体トランザクションデータを患者端末１０に転送する（Ｓ２１０）。なお、医師端末２０は、ステップＳ２０８で生成した見解トランザクションデータをブロードキャストすることで、患者端末１０及びサーバ装置３０に送信してもよい。この場合、ステップＳ２１０は行われない。
　次に、患者端末１０と医師端末２０とサーバ装置３０とは、コンセンサスアルゴリズムを実行する（Ｓ２１１）。より具体的には、患者端末１０と医師端末２０とサーバ装置３０とはそれぞれ、容体トランザクションデータ及び見解トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それらを含むブロックを生成する。そして、患者端末１０と医師端末２０とサーバ装置３０とは、容体トランザクションデータ及び見解トランザクションデータを含むブロックをそれぞれの分散台帳に格納する。すると、患者端末１０と医師端末２０とサーバ装置３０とは、ブロックに取り込まれた容体トランザクションデータ及び見解トランザクションデータを、分散台帳に格納されワーキングメモリに書き出されて稼働している医療判断支援スマートコントラクトに入力する。これにより、容体トランザクションデータ及び見解トランザクションデータを入力値として医療判断支援スマートコントラクトが実行される。
　次に、サーバ装置３０は、医療判断支援スマートコントラクトの出力を取得する（Ｓ２１２）。
　次に、サーバ装置３０は、ステップＳ２１２において取得した医療提案トランザクションデータを医師端末２０に送信する（Ｓ２１３）。
　次に、医師端末２０は、ステップＳ２１３で送信された医療提案トランザクションデータを取得する（Ｓ２１４）。医師端末２０を用いている医師は、取得した医療提案トランザクションデータに含まれる提案情報に基づいて、患者への医療処置を実施する。そして、医師は、患者へ実施した医療処置に関する情報を、医療処置の実施結果として医師端末２０に入力する。なお、サーバ装置３０及び医師端末２０は、別途、患者端末１０とともに、取得した医療提案トランザクションデータを分散台帳に記録してもよい。
　次に、医師端末２０は、医療処置の実施結果を取得したかを確認する（Ｓ２１５）。
　ステップＳ２１５において医療処置の実施結果を取得した場合（Ｓ２１５でＹｅｓ）、医師端末２０は、医療処置の実施結果を含む医療処置実施結果トランザクションデータを生成する（Ｓ２１６）。
　次に、医師端末２０は、ステップＳ２１６で生成した医療処置実施結果トランザクションデータを、サーバ装置３０に送信する（Ｓ２１８）。
　次に、サーバ装置３０は、ステップＳ２１８で送信された医療処置実施結果トランザクションデータを患者端末１０に転送する（Ｓ２１９）。なお、医師端末２０は、ステップＳ２１６で生成した医療処置実施結果トランザクションデータをブロードキャストすることで、患者端末１０及びサーバ装置３０に送信してもよい。この場合、ステップＳ２１９は行われない。
　次に、患者端末１０と医師端末２０とサーバ装置３０とは、コンセンサスアルゴリズムを実行する（Ｓ２２０）。より具体的には、患者端末１０と医師端末２０とサーバ装置３０とはそれぞれ、医療処置実施結果トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、医療処置実施結果トランザクションデータを含むブロックを生成する。そして、患者端末１０と医師端末２０とサーバ装置３０とは、医療処置実施結果トランザクションデータを含むブロックをそれぞれの分散台帳に格納する。
　次に、サーバ装置３０は、分散台帳に格納された医療処置実施結果トランザクションデータと医療提案トランザクションデータとから、医療提案情報と医療処置の実施結果とを連携して記録する（Ｓ２２１）。なお、医療提案情報と医療処置の実施結果とを連携して記録するためのスマートコントラクトが、分散台帳に格納されてワーキングメモリに書き出されることで稼働しているとする。この場合、サーバ装置３０は、ブロックに取り込まれた医療処置実施結果トランザクションデータを、当該スマートコントラクトに入力してもよい。これにより、医療処置実施結果トランザクションデータと医療提案トランザクションデータを入力値としてスマートコントラクトが実行され、医療提案情報と医療処置の実施結果とを連携して記録される。
　［１．１０　効果等］
　以上のように、本開示の制御方法等によれば、患者本人による意思表明が不可能な状況下での医療処置の決定に関する医学的ファクトを含むあらゆる情報を分散台帳に記録できる。さらに、本開示の制御方法等によれば、患者の事前の意思表明を考慮して患者の容体等から医療処置の提案を、一意に決定する医療判断支援スマートコントラクトに、患者本人による意思表明が不可能な状況下での医療処置の提案をさせる。これにより、医療判断支援スマートコントラクトを含むあらゆる情報すなわち患者本人による意思表明が不可能な状況下での医療処置の決定に関するあらゆる情報の改ざんを困難にさせるので、患者らの事前の意思表明を考慮した医療処置を決定して実施したかどうかを検証できる。さらに、当該あらゆる情報を分散台帳により改ざん困難にさせることで、医療情報の不正操作による攻撃を防ぐことができるので、高い信頼性をもって患者らの事前の意思表明を考慮した医療処置を決定して実施したかどうかを検証できる。
　（その他変形例）
　なお、本開示を上記実施の形態に基づいて説明してきたが、本開示は、上記各実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。
　（１）上記の実施の形態では、患者端末１０が１つのブロックチェーン制御部を有するとして説明したが、これに限定されない。患者端末１０は、複数のブロックチェーン制御部を有していてもよいし、例えば、患者端末１０と接続するモニタデバイスがブロックチェーン制御部を有してもよい。また、これらを組み合わせた構成であってもよい。
　（２）また、上記の実施の形態では、１つの患者端末１０と、１つの医師端末２０と、１つのサーバ装置３０とでブロックチェーンネットワークを構成する場合を例にあげて説明したが、これに限定されない。例えば、複数の患者端末１０と、複数の医師端末２０と、複数のサーバ装置とでブロックチェーンネットワークを構成してもよい。また、１つの患者端末１０と、複数の医師端末２０と、複数のサーバ装置となど、組み合わせた構成でブロックチェーンネットワークを構成してもよい。
　（３）また、上記の実施の形態では、サーバ装置３０は、データベース部３０４を有する場合を例にあげて説明したが、これに限定されない。例えば、複数のサーバ装置３０が１つのデータベース部３０４を分割して有していてもよい。
　（４）上記の実施の形態では、患者端末１０が医療判断支援スマートコントラクトを生成するとして説明したが、これに限定されない。患者端末１０は医師端末２０と連携して生成してもよいし、医師端末２０が患者端末１０と連携して生成してもよい。この場合には、医療判断支援スマートコントラクトを含むトランザクションデータの発行に患者端末１０と医師端末２０の署名をマルチシグとして必要としてもよい。
　（５）上記の実施の形態では、分散台帳を構築するブロックチェーン基盤すなわちブロックチェーンのプラットフォームとしてEthereumを用いる場合を例にあげて説明したが、これに限定されない。例えば、Hyperledger Fabricなど、ブロックチェーン上にスマートコントラクトを記述できるプラットフォームであればよく、プラットフォームの種類には限定されない。
　（６）上記の実施の形態では、スマートコントラクトの開発言語としてEthereumの開発言語であるSolidityを用いる例をあげて説明したが、これに限定されない。選択したブロックチェーンのプラットフォームにおいてスマートコントラクトの記述が可能な開発言語であればよい。
　（７）上記の実施の形態では、トランザクションデータに含まれるスマートコントラクトのデータ形式はバイナリデータである場合を例にあげて説明したが、これに限定されない。例えば、アプリケーション・バイナリ・インタフェースなど、選択したブロックチェーンのプラットフォームが実行可能なデータ形式であればよい。
　（８）上記の実施の形態では、医学的ファクトは、トランザクションデータに含められて送受信されたが、これに限定されない。患者端末１０、医師端末２０及びサーバ装置３０が通信可能な形式であればよい。医学的ファクトは、例えば、Ｐ２Ｐ内でのファイルトランスポーテーションを用いて送受信されてもよいし、ｗｅｂ上の通信で送受信されてもよい。
　（９）上記の実施の形態では、医療判断支援スマートコントラクトに対する入力は、患者端末１０が送信する容体トランザクションデータと医師端末２０が送信する見解トランザクションデータであるとして説明したが、これに限定されない。例えば患者端末１０が生成する容体トランザクションデータを医師端末２０が取得し、容体トランザクションデータに含まれる患者の容体を見解トランザクションデータにまとめたものを当該入力としてもよい。なお、医療判断支援スマートコントラクトに対する入力は、容体トランザクションデータと見解トランザクションデータとであるとして説明したが、トランザクションデータのデータ分割を指定するものではない。医療判断支援スマートコントラクト内のアルゴリズムが対応していれば容体トランザクションデータなどの１つのトランザクションデータが２つ以上に分割されて入力されてもよい。
　（１０）また、上記の実施の形態では、医療判断支援スマートコントラクトに対する入力は、患者端末１０が送信する容体トランザクションデータと医師端末２０が送信する見解トランザクションとであるとして説明したが、これに限定されない。他のスマートコントラクトを含む分散台帳に記録されたデータを、医療判断支援スマートコントラクトを含むスマートコントラクトが参照する形式をとってもよい。他のスマートコントラクトとしては、例えば患者自身の遺言情報を記したスマートコントラクト、患者の家族の情報を記載したスマートコントラクトであってもよい。また、他のスマートコントラクトとしては、第三者の決定を医療判断支援スマートコントラクトの要領で記載したスマートコントラクトであってもよい。また、生前の医療だけでなく、臓器提供などを含む死亡時の対応を医療判断支援スマートコントラクトの要領で記載したスマートコントラクトであってもよい。他のスマートコントラクトとしては、さらに、これらを組み合わせたスマートコントラクトであってもよい。これらの場合には、予めスマートコントラクト内に参照先のスマートコントラクトないしトランザクションの条件が記述されていればよい。
　（１１）上記の実施の形態では、医療判断支援スマートコントラクト内の署名確認処理において、トランザクションデータに含まれる署名が不正な署名であった場合には処理を中断すると説明したが、これに限定されない。この場合、医療判断支援スマートコントラクトは、患者端末１０、医師端末２０及び／またはサーバ装置３０に、トランザクションデータに不正署名が含まれていたことを示すトランザクションデータを生成して送信してもよい。また、医療判断支援スマートコントラクトは、トランザクションデータに不正署名が含まれていたことを示すトランザクションデータを生成して送信する処理とともに、上記の中断処理を行ってもよい。
　（１２）なお、上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（１３）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されてもよい。
　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　（１４）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）　Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもｄよい。
　また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
　また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
　本開示は、制御方法、プログラム及び制御装置に利用でき、例えば患者の意思決定、患者への診断結果を含む医学的ファクトを安全に管理したり共有したり、あらゆる医療処置データを管理したりして事後に検証可能となるシステムの制御方法、プログラム及び制御装置に利用できる。
　１　医療処置管理システム
　１０　患者端末
　１１　患者アドレス
　２０　医師端末
　２１　医師アドレス
　３０　サーバ装置
　３１　サーバアドレス
　３２　医療判断支援コントラクトアドレス
　４０　通信ネットワーク
　１０１、２０１、３０１　通信部
　１０２　センサ情報取得部
　１０３　スマートコントラクト生成部
　１０４、２０３　ブロックチェーン制御部
　１０５、２０４　表示部
　１０６、２０５、３０２　記憶部
　２０２　医師見解生成部
　３０３　ブロックチェーン制御部
　３０４　データベース部
　３０５　ワーキングメモリ

Claims (10)

  1. 　システムにおける制御方法であって、
    　患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化されたスマートコントラクトが分散台帳に格納されており、
    　前記制御方法は、
    　センサから得られる前記患者の生体情報を含む第１トランザクションデータを取得し、
    　前記生体情報に対する前記医師の診断結果に関する情報を含む第２トランザクションデータを取得し、
    　取得した前記第１トランザクションデータ及び前記第２トランザクションデータに含まれる前記生体情報及び前記診断結果に基づき、前記スマートコントラクトを実行させ、
    　前記スマートコントラクトを実行させることで得られた、前記患者に施されるべき医療処置に関する医療提案情報を出力する、
    　制御方法。
  2. 　前記第１トランザクションデータ及び前記第２トランザクションデータを取得する前において、
    　前記患者と前記医師とが合議した結果得た前記医療処置判断に基づき生成した前記スマートコントラクトを含む第３トランザクションデータを取得し、
    　前記第３トランザクションデータを含むブロックを前記分散台帳に格納する、
    　請求項１に記載の制御方法。
  3. 　前記第３トランザクションデータには、前記第３トランザクションデータの真贋性を証明するための署名が含まれている、
    　請求項２に記載の制御方法。
  4. 　前記スマートコントラクトは、前記第１トランザクションデータ及び前記第２トランザクションデータを入力値として、前記医療処置判断を実行するための条件式を含む記述を有するプログラムである、
    　請求項１～３のいずれか１項に記載の制御方法。
  5. 　前記第１トランザクションデータと前記第２トランザクションデータとは、
    　前記スマートコントラクトのアドレスを示すコントラクトアドレスを含む、
    　請求項１～４のいずれか１項に記載の制御方法。
  6. 　さらに、
    　前記医師が前記患者に対して実施した医療処置に関する情報である医療処置結果情報を含む第４トランザクションデータを取得し、
    　前記医療処置結果情報を前記医療提案情報と紐づけて前記分散台帳に格納する、
    　請求項１～５のいずれか１項に記載の制御方法。
  7. 　前記生体情報は、心肺停止を示す情報であり、
    　前記診断結果は外傷なしを示す情報であり、
    　前記医療提案情報は、前記患者に施されるべき医療処置が心肺蘇生術の実施である旨を示す情報である、
    　請求項１～６のいずれか１項に記載の制御方法。
  8. 　前記分散台帳は、ブロックチェーン基盤上に構築される、
    　請求項１～７のいずれか１項に記載の制御方法。
  9. 　センサから得られる患者の生体情報を含む第１トランザクションデータを取得し、
    　前記生体情報に対する医師の診断結果に関する情報を含む第２トランザクションデータを取得し、
    　取得した前記第１トランザクションデータ及び前記第２トランザクションデータに含まれる前記生体情報及び前記診断結果に基づき、前記患者と前記医師とが合議した結果得た医療処置判断を実行可能にプログラム化されたスマートコントラクトであって分散台帳に格納されているスマートコントラクトを実行させ、
    　前記スマートコントラクトを実行させることで得られた、前記患者に施されるべき医療処置に関する医療提案情報を出力する、ことを、
    　コンピュータに実行させるプログラム。
  10. 　プロセッサとメモリと分散台帳とを有する制御装置であって、
    　前記分散台帳には、患者と医師とが合議した結果得た医療処置判断を実行可能にプログラム化されたスマートコントラクトが格納されており、
    　前記プロセッサは、センサから得られる前記患者の生体情報を含む第１トランザクションデータを取得し、
    　前記プロセッサは、前記生体情報に対する前記医師の診断結果に関する情報を含む第２トランザクションデータを取得し、
    　前記プロセッサは、前記メモリを用いて、取得した前記第１トランザクションデータ及び前記第２トランザクションデータに含まれる前記生体情報及び前記診断結果に基づき、前記スマートコントラクトを実行させ、
    　前記プロセッサは、前記スマートコントラクトを実行させることで得られた、前記患者に施されるべき医療処置に関する医療提案情報を出力する、
    　制御装置。
PCT/JP2020/046287 2019-12-27 2020-12-11 制御方法、プログラム及び制御装置 WO2021131794A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202080089167.3A CN114846561A (zh) 2019-12-27 2020-12-11 控制方法、程序、以及控制装置
JP2021567241A JPWO2021131794A1 (ja) 2019-12-27 2020-12-11
EP20906573.9A EP4084015A4 (en) 2019-12-27 2020-12-11 CONTROL METHOD, PROGRAM AND CONTROL DEVICE
US17/842,104 US20220311629A1 (en) 2019-12-27 2022-06-16 Control method, recording medium, and control device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962954225P 2019-12-27 2019-12-27
US62/954,225 2019-12-27

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/842,104 Continuation US20220311629A1 (en) 2019-12-27 2022-06-16 Control method, recording medium, and control device

Publications (1)

Publication Number Publication Date
WO2021131794A1 true WO2021131794A1 (ja) 2021-07-01

Family

ID=76576054

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/046287 WO2021131794A1 (ja) 2019-12-27 2020-12-11 制御方法、プログラム及び制御装置

Country Status (5)

Country Link
US (1) US20220311629A1 (ja)
EP (1) EP4084015A4 (ja)
JP (1) JPWO2021131794A1 (ja)
CN (1) CN114846561A (ja)
WO (1) WO2021131794A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015507282A (ja) 2012-01-09 2015-03-05 マイメディカルレコーズ，インコーポレーテッド 遠隔医療及び健康監視デバイス機能による個人健康記録を管理する方法及びシステム
JP2016516231A (ja) 2013-03-07 2016-06-02 メデッソ ゲーエムベーハーＭｅｄｅｓｓｏ Ｇｍｂｈ 医療意志決定時の支援としての医療提案のスコアを計算する方法
JP2018533103A (ja) * 2015-08-03 2018-11-08 ポキットドク インコーポレイテッド 分散型自律医療経済プラットフォームのためのシステム及び方法
US20190035492A1 (en) * 2015-10-14 2019-01-31 David Alan Finkelstein System and method utilizing facial recognition with online (social) network to access casualty health information in an emergency situation
US20190361917A1 (en) * 2018-05-25 2019-11-28 Bao Tran Smart device
US20190392162A1 (en) * 2018-06-25 2019-12-26 Merck Sharp & Dohme Corp. Dynamic consent enforcement for internet of things

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9457197B2 (en) * 2012-05-08 2016-10-04 Physio-Control, Inc. Utility module system
US20180165416A1 (en) * 2016-12-09 2018-06-14 Cognitive Scale, Inc. Method for Providing Healthcare-Related, Blockchain-Associated Cognitive Insights Using Blockchains
WO2019178524A1 (en) * 2018-03-16 2019-09-19 Zoll Medical Corporation Monitoring physiological status based on bio-vibrational and radio frequency data analysis
US11837344B2 (en) * 2018-06-29 2023-12-05 OutcomeMD, Inc. Systems and methods for securely storing patient information and providing access thereto
CN110504008A (zh) * 2019-08-26 2019-11-26 腾讯科技（深圳）有限公司 一种医疗信息管理方法、系统、计算机设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015507282A (ja) 2012-01-09 2015-03-05 マイメディカルレコーズ，インコーポレーテッド 遠隔医療及び健康監視デバイス機能による個人健康記録を管理する方法及びシステム
JP2016516231A (ja) 2013-03-07 2016-06-02 メデッソ ゲーエムベーハーＭｅｄｅｓｓｏ Ｇｍｂｈ 医療意志決定時の支援としての医療提案のスコアを計算する方法
JP2018533103A (ja) * 2015-08-03 2018-11-08 ポキットドク インコーポレイテッド 分散型自律医療経済プラットフォームのためのシステム及び方法
US20190035492A1 (en) * 2015-10-14 2019-01-31 David Alan Finkelstein System and method utilizing facial recognition with online (social) network to access casualty health information in an emergency situation
US20190361917A1 (en) * 2018-05-25 2019-11-28 Bao Tran Smart device
US20190392162A1 (en) * 2018-06-25 2019-12-26 Merck Sharp & Dohme Corp. Dynamic consent enforcement for internet of things

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HOSHINO, KAZUMASA: "Everyone's life - natural death and dignity death, euthanasia and mercy killing", JOURNAL OF CLINICAL SURGERY, vol. 55, no. 9, 20 September 2000 (2000-09-20), JP , pages 1083 - 1088, XP009536876, ISSN: 0386-9857, DOI: 10.11477/mf.1407904190 *
See also references of EP4084015A4

Also Published As

Publication number Publication date
JPWO2021131794A1 (ja) 2021-07-01
EP4084015A4 (en) 2023-02-08
CN114846561A (zh) 2022-08-02
EP4084015A1 (en) 2022-11-02
US20220311629A1 (en) 2022-09-29

Similar Documents

Publication Publication Date Title
Khang et al. Data-centric AI solutions and emerging technologies in the healthcare ecosystem
CN110462654A (zh) 记录存取和管理
US20060122863A1 (en) Patient management network
KR102237449B1 (ko) 환자 진단 학습 방법, 서버 및 프로그램
Eurlings et al. Telemedicine in heart failure—more than nice to have?
WO2006060806A2 (en) Patient management network
Wilson et al. Mapping the Potential of eHealth: Empowering the Citizen through eHealth Tools and Services. Research Report presented at the eHealth Conference, Cork, Ireland, 5-6 May 2004
Waldfogel Spirituality in medicine
JP2022037803A (ja) 情報処理方法、診断支援装置及びコンピュータプログラム
Rachakonda et al. Sayopillow: a blockchain-enabled, privacy-assured framework for stress detection, prediction and control considering sleeping habits in the iomt
Rhoden et al. Patient satisfaction of telemedicine remote patient monitoring: a systematic review
WO2021131794A1 (ja) 制御方法、プログラム及び制御装置
Davat et al. Patients’ information needs related to a monitoring implant for heart failure: co-designed study based on affect stories
Bae et al. Development of blockchain-based health information exchange platform using hl7 fhir standards: usability test
Liljamo et al. Healthcare professionals’ views on the mutual consistency of the F innish C lassification of N ursing I nterventions and the O ulu P atient C lassification
Kaddoura et al. Blockchain for healthcare and medical systems
KR102429182B1 (ko) 환자의 증상 정보에 따른 선택적 의사 매칭이 가능한 비대면 진료 시스템
KR102429183B1 (ko) 의사의 선택적 진료 수락을 통한 의사-환자 비대면 진료 시스템
Usharani et al. Blockchain Technology Use Cases in Healthcare Management: State-of-the-Art Framework and Performance Evaluation
Allen Institutionalising emergent organisation in health and social care
Pandey et al. Data Modelling and Analytics for the Internet of Medical Things
Kartono et al. HIV/AIDS Literacy Impact Towards the Self-Care Performance of People Live with HIV/AIDS in Indonesia
US8670994B2 (en) Method and system for providing information to physicians
Riaño et al. Mining hospital data to learn SDA* clinical algorithms
Kormiltsyn et al. Formal evaluation of privacy-conflict resolution for integrating personal-and electronic health records in blockchain-based systems

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: 20906573

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021567241

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020906573

Country of ref document: EP

Effective date: 20220727