---
title: Cloud-based Health Records
tags: fhir-project
---

[DRAFT] Cloud-based Health Record Files Upload and Sharing
===

---

## Table of Contents
[TOC]

---

## 1. Background
Nowadays, people often use **Google Drive** as a **file storage** to store their working or personal data files. A term which describe a centralized location where documents and files are stored and managed is called "**document repository**". In the **healthcare context**, patient **health records** are confidential documents that need to be securely stored and managed. Healthcare facilities typically maintain their own document repositories, such as **VNA server, file server, EHR system**, and etc. The document repositories are often **restricted to internal local networks** to ensure security and compliance with privacy regulations. However, there are scenarios where patient health records may need to be **transferred externally**, either for the patient's own access or for sharing with other healthcare facilities.

Leveraging **cloud-based document repositories** like Google Drive and combining them with **FHIR standards for document registry** can address the challenges associated with secure and interoperable exchange of health records externally. FHIR provides a standardized format for exchanging healthcare data, allowing for seamless integration and interoperability across different healthcare systems and applications. This approach offers benefits such as improved data security, enhanced interoperability, and streamlined workflows for sharing patient health information across organizational boundaries.

---

## 2. Goals
Ensuring data exchange in standardized format among healthcare facilities and also between healthcare facility and patient

---

## 3. Method

### 3.1. The Concept of Storing Health Record in FHIR Standard

<center>

</center>

Leveraging FHIR for health records data management can indeed follow a concept similar to using Google Drive for storing data, but with additional healthcare-specific features and considerations. Here's how the concept might be applied:

----
**3.1.1. Document Repository**
Document Repository describes a centralized location where documents and files are stored and managed.

**Case 1: Health Record stored in File-Based Format**
Using Google Drive as an example of document repository to store a patient health record, as seen below:

The example provided in image above describe a scenario where patient named Victoria was seeking consultation to Dr. James Smith on January 4th, 2024. After the consultation finished, 4 documents are generated for patient, which consist of:
1. Discharge Summary
2. Laboratory Report
3. Radiology Report Expertise
4. Radiology DICOM Image

**Case 2: Health Record stored in Structured Data Format (Recommended)**
In case 2, we use the example of 4 documents mentioned in case 1, and mapping it into FHIR structured data format as seen below:

| File Name | FHIR Resource Mapping |
|-|-|
| Discharge Summary | Condition |
| Laboratory Report | DiagnosticReport resource (for test results), Observation resource (for observations within the report) |
| Radiology Report Expertise | DiagnosticReport resource (for test results), Observation resource (for lesion annotation and finding within the image) |
| Radiology DICOM Image | ImagingStudy (Store image URL, the original DICOM image stored in DICOM server) |

Instead of storing health record in traditional file formats like PDF, these data are stored in a JSON structured data format. This is a recommended way of storing the health record data as this format can be easily integrated into HIS, cloud-based app, wearable device, and other EHR system.

**3.1.2. Document Registry**

A document registry holds document metadata, which can be searched to retrieve appropriate documents stored in XDS repositories. The metadata includes information about each document, the patient, author, creation date, and location of the related files. While Microsoft Excel can be used as a tool for document indexing and organizing information, it may not be the most efficient or scalable solution for managing large volumes of documents in a healthcare setting.

In FHIR Standard, the `DocumentReference` resource is used for indexing and referencing documents. The `DocumentReference` specifications is describe in part 3.2.

**3.1.3. Document Access Control**
Below is the example for sharing files access to other email account in Google Drive.

In FHIR Standard, the `Task` resource is used to capture the patient's permissions and restrictions regarding the use and disclosure of their health information. The `Task` specifications is describe in part 3.2.

### 3.2. Step-by-step Tutorial for Sharing Health Record using FHIR DocumentReference and FHIR Task

:::info
All applications, explanations, and examples that will be discussed will use **http://hapi.fhir.org/baseR4** as the FHIR Server Base URL
:::

#### 3.2.1. FHIR DocumentReference
Some fields in this resource including:

| FHIR variable | Description |
| -------- | -------- |
| DocumentReference.subject | The subject of the document be referenced |
| DocumentReference.date |The date-time the DocumentReference created |
| DocumentReference.author | The author who create the DocumentReference |
| DocumentReference.custodian | The organization that manage the document be referenced |
| DocumentReference.content | The actual document to-be referenced |

:::spoiler JSON Example

{
  "resourceType": "DocumentReference",
  "id": "misac.documentreference01",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2022-10-05T12:27:53.267+08:00"
  },
  "status": "current",
  "date": "2022-10-05T12:24:39",
  "author": [
    {
      "reference": "Patient/46179774-1a1e-4ae4-b626-9ff53fa080f4",
      "display": "Will Smith"
    }
  ],
  "authenticator": {
    "reference": "Organization/MIPatientPortal",
    "display": "MI Patient Portal"
  },
  "custodian": {
    "reference": "Organization/MIPatientPortal",
    "display": "MI Patient Portal"
  },
  "content": [
    {
      "attachment": {
        "url": "https://drive.google.com/uc?id=1l2Uxt4pXCETIlCFSuXtsq5TQwuIdWEQY&export=download",
        "title": "BP_1"
      }
    }
  ]
}

:::
<br>

:::info
Click [**here**](https://jeshika106316155.github.io/FHIR_DocumentReference/) for trying out DocumentReference Demo Website
:::

### 3.3. Use-Cases

#### **Use Case 1: Teleradiology Reads and Reporting Scenario**

<u>**Development tutorial**</u>

**Pre-Use Case**
- [Create Hospital Organization Structure](https://hackmd.io/@victoriatjia/fhir-tutorial-en3-1)
- [Create Hospital Location](https://hackmd.io/@victoriatjia/fhir-tutorial-en3-2)
- [Create Doctor Information](https://hackmd.io/@victoriatjia/fhir-tutorial-en3-3)
- [Create Patient Information](https://hackmd.io/@victoriatjia/fhir-tutorial-en3-4)
- Upload DICOM image into Document Repository (any types of document repository works fine, e.g. google drive or FTP server)

**Step 1.** Create FHIR DocumentReference to store image source file (the document repository URL)
**Step 2.** Create FHIR Task to store document authorization/ access control information
**Step 3.** Create FHIR Observation to store annotation and finding as observation result
**Step 4.** Create FHIR DiagnosticReport to record the radiology expertise result
**Step 5.** Create FHIR Document (Bundle) to bundling the data created in step 3 (FHIR Observation) and step 4 (FHIR DiagnosticReport)
**Step 6.** Create FHIR DocumentReference to store the data created in step 5 (Radiology image report)
**Step 7.** Create FHIR Task to store document authorization/ access control information of the DocumentReference created in step 6.

<u>**Demo system tutorial**</u>
We are going to demonstrate the workflow how Hospital A located in Indonesia is using this **Teleradiology Portal** asking for teleradiology service to Hospital B located in Taiwan.

There are 7 users which will involved:
1. Patient
2. Portal Admin
3. IT application admin from Hospital A (shortened as **"Admin A"**)
4. Radiographer from Hospital A (shortened as **"Radiographer A"**)
5. Physician from Hospital A (shortened as **"Doctor A"**)
6. IT application admin from Hospital B (shortened as **"Admin B"**)
7. Radiologists from Hospital B (shortened as **"Radiologist A"**)

There are 2 systems provided:
1. A web-based CMS (Content Management System) which will be used by medical professional sites
a. Organization registration
b. Physician registration
c. Patient registration
3. A Mobile Web-App which operated by patient
a.

Business Workflow:
| No. | Task | PIC | System Name|
| -------- | -------- | -------- | -------- |
| 1 | Register Hospital A and Hospital B | Portal Admin | CMS |
| 2 | Register data of Physician A | Admin A | CMS |
| 3 | Register data of Radiologist B | Admin B | CMS |
| 4 | Register patient data | Patient | Mobile App |
| 5 | Upload DICOM image file and indexing the document| Admin A | CMS |
| 6 | Authorize the image document to Patient and Radiologist B |Admin A |
| 7 | Send Teleradiology request to Hospital B | Physician A | CMS |
| 8 | Search all teleradiology request from Hospital A | Radiologist B | CMS |
| 8 | Select one of the request to create the radiology report | Radiologist B | CMS |
| 9 | Review image and create the diagnostic report (open image, mark annotation, input finding and diagnostic report form) | Hospital IT application admin | CMS-Report Creator Module |
| 10 | Radiologists authorize the radiology expertise report to patient and Hospital A | Radiologist B | CMS-Report Creator System |
| 11 | Radiologists update the request status (FHIR Task) into "finished" | Radiologist B | CMS-Report Creator System |
| 12 | Physician A receive notification patient's radiology report has been created | Radiologist B | CMS-Report Creator System |

---

## References
* [FHIR DocumentReference to index document on Patient Portal](https://hackmd.io/sVFvo8CpSbOz79YtxvLlLQ?both)
* [FHIR DocumentReference DEMO Example](https://hackmd.io/@jeshika/SkbaN8-7o)