# MedChain: Efficient Healthcare Data Sharing via Blockchain
## 4 Healthcare Data Sharing
### Session Management  
After the information of the data is added into the blockchain service and the directory service, a patient can grant access to his/her healthcare data to a requester through a session. The complete data sharing process is shown in Figure 6.  
* _Step 1-2_. As per request, the patient selects the data from his/her inventory for sharing, creates a session with the selected data descriptions and the \(PK_{req}\), encrypts them with \(SK_{pat}\), generates the session digest to maintain session integrity, creates an \(Event_{SC}\), and sends it to the blockchain service. The blockchain service adds the \(Event_{SC}\) to a new block together with other received events, and appends the block to the end of the blockchain. Then, it sends back the \(SID\) (i.e., the event hash of \(Event_{SC}\)) to the patient. * _Step 3-4_. The patient then creates a session in the directory service with the received \(SID\), and notifies the requester and the healthcare provider of the session by sending them the \(SID\). He/she uses \(K_{sec}\) to encrypt the content of the session and then \(PK_{req}\) to encrypt the session key. * _Step 5-6_. With the \(SID\), the requester can find and access the session. After decrypting the session key (\(K_{sec}\)) with his/her \(SK_{req}\) and the session with the \(K_{sec}\), the requester learns the actual location of the shared data and sends the request to the healthcare provider for data access. * _Step 7-8_. On receiving the data access request, the healthcare provider checks the session state in the directory service. If the session exists, it then verifies the request, including the message signature and the range of the requested. If they are all valid, the healthcare provider returns the data to the requester. In data transmission, a secure channel can be established through asymmetric encryption on the data with \(PK_{req}\). * _Step 9_. The requester, after receiving and decrypting the data with \(SK_{req}\), verifies the data integrity by downloading the data digests from the blockchain service. If the data is valid, then he/she can  
Figure 5: Process of new healthcare data generation. access the data. If the data is invalid due to, for example, data loss/corruption during storage or transmission, an alert will be triggered, which is out of the scope of this paper. A patient can revoke the access of a requester by closing the session. Session removal is implemented by removing the session in the directory service to prevent the requester from future access and to recycle storage space. For each data stream in a session, a patient can determine the data access range by specifying the start time (_st_) and end time (_et_) of the shared segment. In a patient-centric sharing scheme, a healthcare provider will only return the chunks within the range to a requester. Let \(st_{c}\) and \(et_{c}\) be the data collection start time and time of a chunk \(c\). The chunks allowed to access are \([c\,\mathit{l}\,\mathit{s}_{c}\geq\mathit{st}\wedge\mathit{et}_{c}\leq\mathit{et}]\). In a user interface design, we plan to align the pace of time selection with the pace of chunk file generation to avoid time specifying in the middle of a chunk. For instance, if the chunks of a stream are generated per hour, then \(\mathit{st}\) and \(\mathit{et}\) will be varied by hour and from the start time of the first chunk. Note that the above process is flexible at several places. First, a patient can leave the session open for future access by the same doctor, if subsequent consultations are needed or the data is used for medical research. Then, the end time of a data stream in a session can be left empty to enable the doctor to track the patient's condition as long as needed. If the end time is empty, the sharing scheme will not restrict a requester from accessing any chunk of the stream from the specified start time. If both the start time and the end time are empty, no chunk access restriction will be imposed to the requester.