VDAT: Data Platform for Health

• 1: Introduction
• 1.1: Use Cases
• 2: Architecture
• 2.1: Deployment
• 3: Applications
• 3.1: IOH
• 3.2: PDF Viewer
• 3.3: Form Filler
• 4: Infrastructure
• 5: Services
• 5.1: Identity Management Service
• 5.2: Vault
• 5.3: Dictionary Service
• 5.4: Collector Service
• 5.4.1: Access Control
• 5.5: Dis Dictionary Service
• 5.6: SMS Service
• 5.6.1: SMS Service (Legacy)
• 6: REST API
• 7: IoH
• 7.1: OMOP CDM
• 7.2: User Attributes

1 - Introduction

VDAT Platform Overview

The VDAT Platform is a comprehensive healthcare data integration and management system designed to facilitate the collection, processing, and analysis of medical data across healthcare institutions. The platform provides a secure, scalable infrastructure for healthcare data interoperability, enabling improved patient care, research, and data-driven decision making.

Core Capabilities

The VDAT Platform offers several key capabilities:

• Data Collection & Integration: Secure collection of healthcare data from various sources including hospitals, clinics, and medical devices
• Identity Management: Robust user identification and authentication with multi-layered encryption
• Access Control: Granular permissions and role-based access to sensitive medical information
• Data Processing: Standardization, transformation, and enrichment of healthcare data
• Analytics & Reporting: Tools for data analysis, visualization, and insights generation
• API Ecosystem: Comprehensive API layer for integration with third-party systems
• Event-Driven Architecture: Real-time data processing and event notifications

Architecture Overview

The VDAT Platform is built on a microservices architecture that emphasizes security, scalability, and interoperability. Each service is responsible for its own authentication and authorization, with support from a centralized Identity Access Management (IAM) system.

Key components include:

• Collector Service: Manages data collection and ingestion processes
• OAuth2 Server: Provides authentication, authorization, and login interfaces
• Patient Medical Records: Offers APIs for accessing healthcare data
• Identity Management Service: Handles multi-layered encryption and user identity management
• Event Store: Supports data collection from various sources, including databases, APIs, and sensors
• SMS Service: Enables sending and receiving SMS messages through preconfigured numbers
• Analysis Service: Provides advanced data analytics capabilities

Use Cases

The VDAT Platform supports numerous healthcare use cases, including:

1. Patient Data Exchange: Secure sharing of patient information between healthcare providers
2. Medical Research: Collection and analysis of anonymized health data for research purposes
3. Remote Patient Monitoring: Integration with medical devices for continuous patient monitoring
4. Public Health Surveillance: Aggregation of health data to identify trends and outbreaks
5. Clinical Decision Support: Data-driven insights to support medical decision making

Getting Started

To learn more about specific components and capabilities of the VDAT Platform, explore the documentation sections:

• Architecture
• Applications
• Services
• Infrastructure

1.1 - Use Cases

Thu thập dữ liệu bệnh nhân đái tháo đường từ Bệnh viện Hùng Vương

1. Service hvmigrateuser được triển khai tại bệnh viện, kết nối với API Gateway của bệnh viện thực hiện đồng bộ dữ liệu hàng giờ.
2. Service hvmigrateuser kết nối đến event store tại VDAT để publish event và fetch event để lấy trạng thái mới nhất khi cần.
3. Service hvmigrateuser kiểm tra trạng thái của bệnh nhân tại hệ thống VDAT và thực hiện đồng bộ khi cần.
4. Service hvconsumer được triển khai tại VDAT, kết nối đến event store tại VDAT fetch các event được lưu trữ trên event store và cung cấp API để truy vấn thông tin mới nhất của bệnh nhân.

graph LR
    hvmigrateuser[hvmigrateuser] --> API[API Gateway]
    API --> HV[Hung Vuong Hospital]
    hvmigrateuser --> EventStore[Event Store]
    
    hvconsumer[hvconsumer] --> EventStore
    hvconsumer --> VDAT[VDAT System]
    hvmigrateuser --> VDAT
    VDAT --> EventStore
    
    classDef hospitalNode fill:#f9d5e5,stroke:#333,stroke-width:1px;
    classDef serviceNode fill:#eeeeee,stroke:#333,stroke-width:1px;
    classDef platformNode fill:#d5f9e8,stroke:#333,stroke-width:1px;
    
    class HV,API hospitalNode;
    class hvmigrateuser,hvconsumer serviceNode;
    class EventStore,VDAT platformNode;
    
    subgraph "Hung Vuong Hospital"
        HV
        API
        hvmigrateuser
    end
    
    subgraph "VDAT Platform"
        EventStore
        hvconsumer
        VDAT
    end

2 - Architecture

Kiến trúc hệ thống

Sơ đồ thành phần hệ thống

Hệ thống gồm các dịch vụ chính như:

• Collector Service: cung cấp chức năng quản lý thu thập dữ liệu.
• OAuth2 Server: cung cấp tính năng xác thực, phân quyền, giao diện đăng nhập, v.v..
• Patient Medical Records (TODO: review tên): cung cấp api truy cập dữ liệu nhận từ các đơn vị y tế.

Ngoài ra, còn có các dịch vụ:

• Identity Management Service: dịch vụ hỗ trợ mã hóa nhiều lớp và lưu trữ định danh người dùng
• Encryption Service: dùng để tăng cường lớp mã hóa cho các dịch vụ lưu trữ dữ liệu quan trọng, hoặc cung cấp tính năng mã hóa cho các dịch vụ chưa có tính năng này
• Event Store: hỗ trợ API nhận dữ liệu từ các dịch vụ trong hệ thống hoặc bên ngoài hệ thống như các đơn vị y tế. Dữ liệu có thể được lấy từ các cơ sở dữ liệu, API, cảm biến v.v..
• Error Tracking Service: là một Event Store được dùng để thu thập dữ liệu lỗi từ các dịch vụ
• API Explorer: là dịch vụ cung cấp tài liệu về API nhằm hỗ trợ các bên công tác thứ 3 có thể sử dụng API hệ thống được dễ dàng.
• SMS Service: cung cấp chức năng gửi, nhận tin nhắn từ một số đầu số được cải đặt trước
• Analysis Service: …. ??? (TODO: bổ sung)

Xác thực và phân quyền

Khi triển khai kiến trúc Microservice thông thường sẽ có hai cách hiện thực phân quyền:

• Cách 1: Chia các dịch vụ thành 2 loại (Micro và Edge/Backend-for-Frontend), phân quyền được thực hiện ở các service thuộc loại Edge, các Micro cung cấp API (nội bộ) không yêu cầu xác thực
• Cách 2: Mỗi service (trừ một số service đặc biệt) sẽ tự quản lý phân quyền.

Hệ thống này được hiện thực theo cách 2 - Mỗi service tự phân quyền, do đó cần có IAM để hỗ trợ các service trong việc xác thực người dùng

IAM (Identity Access Management) nắm giữ các định danh của toàn bộ các đối tượng (user, service, command…) cùng với các bộ luật phân quyền chi tiết cho từng loại tài nguyên.

Việc mỗi service phải tự thực hiện việc xác thực, phân quyền sẽ làm tăng chi phí khi xây dựng các service, ngoài các nghiệp vụ chính thì cần thêm lớp middleware để giao tiếp với IAM.

OAuth2

Tài liệu tham khảo

• Xác thực và phân quyền trong Microservices
• Diagrams of All The OpenID Connect Flows

2.1 - Deployment

Tài liệu triển khai hệ thống

Mã nguồn tất cả các dịch vụ được lưu trữ trong các project tại GitLab.com Theo mặc định các dịch vụ sẽ được đóng thành docker image lưu trữ trên GitLab Docker Registry tại mỗi Project để chờ deploy.

Phương thức triển khai

Có nhiều phương thức triển khai các dịch vụ, có thể sử dụng một hoặc nhiều phương thức triển khai tùy theo dịch vụ, một số phương thức cơ bản có thể liệt kê gồm:

• Clone mã nguồn từ Git Repository và build theo hướng dẫn ở từng project, cách này yêu cầu người triển khai phải hiểu cách cách cấu hình build, đóng gói (nếu có), và cấu hình biến môi trường để triển khai dịch vụ
• Sử dụng Docker để triển khai
  • Sử dụng Docker Image đã đóng gói và lưu trữ GitLab Docker Container Registry để triển khai trên các môi trường hay nền tảng hỗ trợ Docker, cách này chỉ cần cấu hình các biến môi trường để triển khai dịch vụ, đây là phương thức triển khai trên môi trường production.
  • Sử dụng Docker Compose cấu hình sẵn (DOING), đây là cách dễ thực hiện nhất, và hướng tới sử dụng cho mục đích demo.

Triển khai trên môi trường cục bộ

Môi trường triển khai này dùng cho mục đích thuyết minh (demo), phát triển (development) do đó hướng tới triển khai đơn giản, nhanh và không yêu cầu tính ổn định và khả năng chịu lỗi' Yêu cầu cần có để triển khai

• 1 máy tính ảo/vật lý
• Docker và Docker Compose được cài đặt sẵn

Triển khai IOH

Để triển khai IOH, thực hiện các bước sau theo thứ tự

1. Mở gói phần mềm đã được cung cấp (gồm mã nguồn và cấu hình triển khai có sẵn)
2. Gọi lệnh docker-compose để chạy
3. Truy cập http://localhost:1000 với tài khoản được đính kèm trong gói phần mềm

Để tùy chỉnh nâng cao, xem tài liệu triển khai ở từng dịch vụ

Quy trình triển khai cho môi trường production

Môi trường production sử dụng một Kubernetes Cluster, gồm ít nhất 3 master (stacked master + etcd) nhầm đảm bảo tính sẵn sàng. Cluster được liên kết với GitLab và sử dụng quy trình triển khai Auto DevOps của GitLab là quy trình mặc định để triển khai dịch vụ. Quy trình này được kích hoạt mỗi khi có thay đổi ở GitLab project, thường là ở nhánh master. Quy trình gồm các giai đoạn sau:

1. Build. Ở giai đoạn này, GitLab sẽ tự động kiểm tra cấu hình Dockerfile và build Docker Image từ Dockerfile trong project xác định
2. Test. Ở giai đoạn này, GitLab sẽ kích hoạt lệnh test tương ứng với một số cấu hình, ngôn ngữ của mã nguồn.
3. Staging. Đây là giai đoạn tùy chọn để triển khai lên môi trường staging được kích hoạt ở một số dịch vụ cần có các bước kiểm tra thêm trước khi đưa ra môi trường production
4. Production. Đây là giai đoạn triển khai dịch vụ lên trên Kubernetes Cluster để người dùng sử dụng. Ở giai đọan này, GitLab sẽ kích hoạt triển khai Helm Chart mặc định là auto-deploy-app để triển khai Docker Image lên Kubernetes cluster kèm một số cấu hình khác như biến môi trường, cấu hình điều hướng từ Ingress, chứng chỉ TLS, Số lượng pod cần triển khai, lớp lưu trữ, v.v…

Sau khi triển khai lên môi trường production thành công, công việc còn lại của Operator là giám sát và điều khiển dịch vụ bằng giao diện điều khiển của Kubernetes.

Sơ đồ triển khai Kubernetes Cluster

Đây là sơ đồ triển khai Kubernetes Cluster với cấu hình High Available (sẵn sàng cao). Mô hình triển khai này nằm tăng tính ổn định của hệ thống, giảm thiểu khả năng tê liệt toàn bộ hệ thống khi một máy vật lý nào đó gặp lỗi hoặc máy vật lý cần tắt để thực hiện các thao tác bảo trì.

Hệ thống trên được triển khai trong mạng nội bộ nằm phía sau tường lửa chỉ mở port 80 và 443 để nhận kết nôi trừ bên ngoài ở địa chỉ IP xác định. Việc nhận request từ bên ngoài sẽ được đảm nhiệm bởi 02 Load Balancer cùng thay phiên nhau lắng nghe dữ liệu từ cổng công khai, 2 load balancer sẽ vận hành cơ chế health checking để kiểm tra trạng thái hiện tại lẫn nhau. Nếu Load Balancer ở chế độ Active gặp trục trặc, thì Load Balancer còn lại đang ở chế độ Passive sẽ chuyển qua chế độ Active để lắng nghe dữ liệu và vận hành thay thế cho Load Balancer gặp trục trặc có thời gian phục hồi.

Kubernetes Cluster được điều khiển bởi các node Master, để tăng tính ổn định ta cần scaling các node Master này lên, các node Master sẽ kết nối với nhau bằng port :6443 của Load Balancer.

Worker node là các node là nhiệm vụ xử lý chính, đây là nơi các service được triển khai vào cluster hoạt động. Tùy theo nhu cầu xử ý mà ta scale các worker node với số lượng phù hợp. Các worker node kết nối với master thông qua port 6443 của Load Balancer

Sơ đồ triển khai các dịch vụ (Deprecated)

TODO: Review

• Sơ đồ thể hiện sự phân luồng dữ liệu dữ liệu đi vào hệ thống gồm loại giao thức và các thành phần tiếp nhận.

• Sơ đồ liệt kê các thành phần khi triển khai hệ thống.

• Các kết nối là 2 CHIỀU (request/response) chiều mũi tên là chiều request từ dịch vụ yêu cầu tài nguyên đến dịch vụ cung cấp tài nguyên, chiều ngược lại là chiều response. sơ đồ KHÔNG sử dụng kết nối 1 chiều.

• Màu:

  • Xanh lá: các thành phần đã được triển khai
  • Vàng: các thành phần đã hiện thực nhưng chưa triển khai
  • Đỏ: Các thành phần chưa hiện thực hoặc đang thiết kế

3 - Applications

Ứng dụng hệ thống

Phần này bao gồm các tài liệu về các ứng dụng và dịch vụ được triển khai trong hệ thống.

3.1 - IOH

IOH - Ứng dụng thu thập dữ liệu

[Tài liệu yêu cầu kỹ thuật (SRS)]({{ < param DocsRepo > }}/products/ioh/srs.md)

Biểu đồ

Cấu hình biểu đồ - Full docs
Cấu hình biểu đồ - Model diagram

Use Case

Tính năng

Các tính năng của IOH phục vụ trong dự án nghiên cứu dữ liệu được chia thành 6 nhóm:

Manage

Design - Các tính năng thiết kế dự án nghiên cứu

• Thiết kế mẫu thu thập
• Thiết kế biểu đồ
• Thiết kế cấu trúc nhận dữ liệu SMS

Collect

• Thu thập dữ liệu qua SMS
• Thu thập dữ liệu qua Web
• Thu thập dữ liệu thông qua ứng dụng Form Filler
• Thu thập dữ liệu từ thiết bị vật lý (?)

Create

• Research Staff tạo dữ liệu bằng IOH
• Người tham gia tự nhập dữ liệu

Process

• (?)

Analyst

• (?)

3.2 - PDF Viewer

PDF Viewer

TODO Bổ sung nội dung cho sản phẩm này

3.3 - Form Filler

Form Filler

Ứng dụng thu thập dữ liệu người dùng bằng biểu mẫu trên Mobile và Web

Sơ đồ hoạt động của ứng dụng Check-in

Giao diện check-in

4 - Infrastructure

Create Kubernetes cluster high available

Infrastructure Documentation

This section provides detailed instructions for setting up and configuring the infrastructure components required for the system deployment.

1. Install Docker runtime click here

2. Setup Cgroup Driver for Docker click here

    sudo mkdir /etc/docker
   
    cat <<EOF | sudo tee /etc/docker/daemon.json
    {
      "exec-opts": ["native.cgroupdriver=systemd"],
      "log-driver": "json-file",
      "log-opts": {
        "max-size": "100m"
      },
      "storage-driver": "overlay2"
    }
    EOF
   
    sudo systemctl enable docker
    sudo systemctl daemon-reload
    sudo systemctl restart docker
   

3. Turn off swap:

   • swapoff -a: Disable swap at current terminal
   • Comment line swap trong /etc/fstab: Auto disable swap every reboot

4. Install kubeadm, kubelet, kubectl: click here

5. Setup HA Proxy Click here

     global
       log /dev/log local0
       log /dev/log local1 notice
       chroot /var/lib/haproxy
       stats timeout 30s
       user haproxy
       group haproxy
       daemon
   
     defaults
       log global
       option tcplog
       mode http
       #option httplog
       option dontlognull
       timeout connect 10s
       timeout client 30s
       timeout server 30s
   
     # list server is configure in nginx controller externalIPs
     listen lets-encrypt-http-resolver2
       bind *:80
       mode http
       maxconn 8
       stats uri /haproxy?stats
       balance roundrobin
       server v127 192.168.0.127:80 check fall 3 rise 2 check-send-proxy inter 10s send-proxy
   
     # list server is configure in nginx controller externalIPs
     listen k8s-nginx-ingress
       bind *:443
       mode tcp
       maxconn 10000
       timeout tunnel 600s
       balance roundrobin
       option tcp-check
       server v127 192.168.0.127:443 check fall 3 rise 2 check-send-proxy inter 10s send-proxy
   
     # list server  master node
     listen k8s-api-server
       bind *:7443
       mode tcp
       timeout connect 5s
       timeout client 24h
       timeout server 24h
       server v117 192.168.0.117:6443 check fall 3 rise 2
       server v118 192.168.0.118:6443 check fall 3 rise 2
       server v119 192.168.0.119:6443 check fall 3 rise 2
   

6. Setup Keepalived Click here

   • Check Network Interface: ens160 or br0 or eth0

       ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
         inet 192.168.0.117  netmask 255.255.255.0  broadcast 192.168.0.255
         inet6 fe80::20c:29ff:fe6a:941c  prefixlen 64  scopeid 0x20<link>
         ether 00:0c:29:6a:94:1c  txqueuelen 1000  (Ethernet)
         RX packets 1157858  bytes 430863324 (430.8 MB)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 1036082  bytes 186847619 (186.8 MB)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     

   • Setup MASTER and BACKUP, check priority

       global_defs {
         enable_script_security
         script_user root root #USER
         router_id lb01
       }
       vrrp_script chk_haproxy {
         script "/usr/bin/killall -0 haproxy"
         interval 2
         weight 2
       }
       vrrp_instance VI_1 {
         virtual_router_id 52
         advert_int 1
         priority 100 # MASTER > BACKUP: 100 > 99 > 98
         state MASTER # MASTER OR BACKUP
         interface ens160 # NETWORK INTERFACE
         unicast_src_ip 192.168.0.117 # The IP address of this machine
         unicast_peer {
           192.168.0.118 # IP address of peer
           192.168.0.119 # IP address of peer
         }
         virtual_ipaddress {
           192.168.0.200 dev ens160 # THe virual address
         }
         authentication {
             auth_type PASS
             auth_pass 1111
         }
         track_script {
           chk_haproxy
         }
       }
     

7. Verify Keepalived

   • Check ip address 192.168.0.200: ip a s

     ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
       link/ether 00:0c:29:6a:94:1c brd ff:ff:ff:ff:ff:ff
       inet 192.168.0.117/24 brd 192.168.0.255 scope global ens160
         valid_lft forever preferred_lft forever
       inet 192.168.0.200/32 scope global ens160
         valid_lft forever preferred_lft forever
       inet6 fe80::20c:29ff:fe6a:941c/64 scope link 
         valid_lft forever preferred_lft forever
   

   • Stop HA Proxy and check ip with other machine
   • Check log keepalived: journalctl -u keepalived.service -f

8. Create high available cluster

   • First master

     #"LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
     # Add option --pod-network-cidr=10.244.0.0/16 for install Plannel CNI network
     # https://github.com/flannel-io/flannel/blob/master/Documentation/kubernetes.md
     sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --control-plane-endpoint "192.168.0.200:7443" --upload-certs
     

   • Master join:

     kubeadm join 192.168.0.200:7443 --token ${token} \
         --discovery-token-ca-cert-hash ${token-ca-cert} \
         --control-plane --certificate-key ${certificate}
     

   • Worker join:

     kubeadm join 192.168.0.200:7443 --token ${token} \
         --discovery-token-ca-cert-hash ${token-ca-cert} \
     

   • Setup local kube config

     mkdir -p $HOME/.kube
     sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
     sudo chown $(id -u):$(id -g) $HOME/.kube/config
     

9. Apply CNI Plugin

   • Flannel: (Rook Ceph required)

   kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
   

   • Weave

   kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
   

10. Update primary HA Proxxy: (Optional)

    listen k8s-new-api-server
        bind *:8443
        mode tcp
        timeout connect 5s
        timeout client 24h
        timeout server 24h
        server p200 192.168.0.200:7443 check fall 3 rise 2 # NEW HAPROXY
    

11. Renew certificate when public cluster click here

      #UPDATE CERTIFICATE WITH EACH MASTER
      rm /etc/kubernetes/pki/apiserver.*
    
      kubeadm init phase certs apiserver --apiserver-advertise-address 192.168.0.200 --apiserver-cert-extra-sans 115.79.213.25
    
      kubeadm certs renew admin.conf
    

12. Install Rook Ceph click here

    • Clone source

      git clone --single-branch --branch v1.6.7 https://github.com/rook/rook.git
    

    • Deploy the Rook Operator

      cd cluster/examples/kubernetes/ceph
      kubectl create -f crds.yaml -f common.yaml -f operator.yaml
    
      # verify the rook-ceph-operator is in the `Running` state before proceeding
      kubectl -n rook-ceph get pod
    

    • Create a Rook Ceph Cluster

      kubectl create -f cluster.yaml
    

13. Intergrate Gitlab Kubernetes (Optional) click here

14. Install Helm Click here

    curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -
    sudo apt-get install apt-transport-https --yes
    echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
    sudo apt-get update
    sudo apt-get install helm -y
    

15. Install Cert-Manager Click here

    • Install Helm
    • Create namespace

    kubectl create namespace cert-manager
    

    • Add the Jetstack Helm repository

    helm repo add jetstack https://charts.jetstack.io
    helm repo update
    

    • Install Cert Manager

    helm -n cert-manager install cert-manager jetstack/cert-manager --set ingressShim.defaultIssuerName=letsencrypt-prod --set ingressShim.defaultIssuerKind=ClusterIssuer --set installCRDs=true --version v1.4.0
    

    • Create Cluster Issuer

    # cluster-issuer-staging.yaml
    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: letsencrypt-staging
    spec:
      acme:
        email: master@vdatlab.com
        server: https://acme-staging-v02.api.letsencrypt.org/directory
        privateKeySecretRef:
          name: letsencrypt-staging
        solvers:
        - http01:
            ingress:
              class: nginx
    

    kubectl apply -f cluster-issuer-staging.yaml
    

    • Check Cluster Issuer

    kubectl get clusterissuers.cert-manager.io | grep True
    

5 - Services

Ecosystem

Tài liệu về các dịch vụ trong hệ sinh thái của hệ thống gồm các dịch vụ của nhóm phát triển và các dịch vụ mã nguồn mở.

5.1 - Identity Management Service

Identity Management Service

Dịch vụ lưu trữ mã hóa và quản lý định đanh người dùng

Tài liệu triển khai dịch vụ IdM

xem tại https://gitlab.com/n13t/idm/-/blob/master/DEVELOPMENT.md

Bảo mật

Mã hóa dữ liệu người dùng

Mô tả cách thức mã hóa dữ liệu người dùng

• PLAINTEXT - dữ liệu người dùng
• DATA_KEY - khóa riêng cho mỗi trường dữ liệu
• USER_KEY - khóa riêng cho mỗi người dùng
• SERVICE_KEY - khóa của dịch vụ (đặt bởi người triển khai)
• MASTER_KEY - khóa chung cho tất cả dữ liệu được lưu trữ bởi dịch vụ KMS

1. encrypt(PLAINTEXT, DATA_KEY) = CPT1 (thực hiện tại server)
2. encrypt(CPT1, USER_KEY) = CPT2 (thực hiện tại server)
3. encrypt(CPT2, SERVICE_KEY) = CPT3 (thực hiện tại server)
4. encrypt(CPT3, MASTER_KEY) = CPT4 (thực hiện tại KMS, MASTER_KEY là bí mật)
5. Lưu trữ CPT4

Thực hiện ngược lại các bước trên để giải mã dữ liệu

Tài liệu tham khảo

• 12 best practices for user account, authorization and password management

5.2 - Vault

Vault

Yêu cầu

• Nhận và mã hóa dữ liệu
• Quản lý keyring, key, key version
• Hỗ trợ tính năng key rotation

Giải pháp

Sử dụng Vault của HashiCorp

Tham khảo

• Vault

5.3 - Dictionary Service

5.4 - Collector Service

Collector Service - Dịch vụ thu thập dữ liệu

{ { < svg “content/docs/services/collector/img/overview.svg” > } } TODO: mo ta

Tính năng

1. Thu thập dữ liệu, dịch vụ hỗ trợ các phương thức thu thập dữ liệu sau
   1. Hỗ trợ API thu thập dữ liệu, phương pháp này hỗ trợ thu thập dữ liệu thông qua internet với bộ API được quy định sẵn.
   2. Hỗ trợ thu thập dữ liệu bằng tin nhắn SMS
2. Hỗ trợ các tính năng quản lý dự án thu thập dữ liệu:
   1. Quản lý biểu mẫu thu thập dữ liệu
   2. Quản lý người tham gia và người nhập liệu theo nhóm
3. Hỗ trợ nhắc nhở nhập liệu bằng SMS

Thu thập dữ liệu bằng tin nhắn SMS

Phương pháp này hỗ trợ người dùng nhập dữ liệu từ tin nhắn SMS

• Yêu cầu

  • Một header nhắn tin phải được quy định trước
  • Số điện thoại của người dùng phải tồn tại trong cơ sơ dữ liệu của hệ thống

• Cơ chế hoạt động

{{ < svg “content/docs/services/collector/img/sms_parser.svg” > }}

Triển khai

Sơ đồ triển khai

Collector Service cần có các thành phần sau khi triển để hoạt động đầy đủ chức năng:

1. PostgreSQL: là thành phần quan trọng nhất, dùng để lưu trữ mọi dữ liệu của dịch vụ
2. Identity Management Service: dùng để lưu trữ định danh người dùng (hiện chưa hỗ trợ)
3. SMS Service: dùng để nhắc nhở nhập dữ liệu và nhận dữ liệu từ SMS
4. Analysis Service: dùng để ??? (TODO: bổ sung)

Mở rộng (scaling)

Application Deployment Model: Stateless

Tăng số lượng node để tăng khả năng chịu tài và độ ổn định của dịch vụ

Access Control Policies

5.4.1 - Access Control

Best Practices[1]

Scope the Organization Name

A rule of thumb is to prefix resource names with a domain that represents the organization creating the software.

• KHÔNG DÙNG: <some-id>
• DÙNG: <organizaion-id>:<some-id>

Scope Actions, Resources and Subjects

It is wise to scope actions, resources, and subjects in order to prevent name collisions:

• KHÔNG DÙNG: myorg.com:<subject-id>, myorg.com:<resource-id>, myorg.com:<action-id>
• DÙNG: myorg.com:subjects:<subject-id>, myorg.com:resources:<resource-id>, myorg.com:actions:<action-id>
• DÙNG: subjects:myorg.com:<subject-id>, resources:myorg.com:<resource-id>, actions:myorg.com:<action-id>

Multi-Tenant Systems

Multi-tenant systems typically have resources which should not be access by other tenants in the system. This can be achieved by adding the tenant id to the URN:

Do: resources:myorg.com:tenants:<tenant-id>:<resource-id> In some environments, it is common to have organizations and projects belonging to those organizations. Here, the following URN semantics can be used:

Do: resources:myorg.com:organizations:<organization-id>:projects:<project-id>:<resource-id>

Hiện thực

Subject

Users

Các thuộc tính dùng để phân quyền của Users

{
    id: string
    role: string // role của service là admin hoặc user
}

Resources

Dịch vụ Collector gồm có các loại resource sau:

• Project

{
    id: string
}

• ProjectUserGroup

{
    id: string
    ProjectId: string
}

• Form

{
    id: string
}

• Section

{
    id: string
}

• FormSection (section thuộc một form cụ thể)

{
    id: string
    FormId: string
}

Chính sách truy cập

Gồm có 3 loại chính sách:

• Chính sách hệ thống (áp dụng trên mức hệ thống - Ưu tiên cao nhất)
• Chính sách dịch vụ (áp dụng tại dịch vụ - Ưu tiên cao)
• Chính sách dự án (áp dụng trong dự án, được PROJECT OWNER quy định để phù hợp với nghiệp vụ của mình)

Chính sách hệ thống (#TODO dẫn nguồn)

Chính sách dịch vụ

Là các chính sách áp dụng trong Collector Service:

1. PROJECT OWNER có toàn quyền trong dự án của mình

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == r.obj.Owner

1. RESEARCHER có quyền XEM{Thông tin dự án, thành viên trong dự án}

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub.role == reseacher

1. RESEARCHER có quyền XEM, THÊM dữ liệu

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub.role == reseacher

Tài liệu tham khảo

[1] ORY Access Control Policies

5.5 - Dis Dictionary Service

5.6 - SMS Service

SMS Service

SMS Service có chức năng quản lý GSM Modem và cung cấp API hỗ trợ các hệ thống khác trong hệ thống thực hiện các chức năng như gửi, nhận tin nhắn SMS một cách thuận tiện nhất.

Tính năng

• Giám sát trạng thái các modem bằng dashboard
• Gửi tin nhắn SMS (gửi từng tin hoặc hàng loạt). Hỗ trợ các dạng tin nhắn 7bit, 16bit; encode UTF-8
• Nhận tin nhắn và lưu trữ tin nhắn.

Tổng quan

{{ < svg “content/docs/services/sms/img/component.svg” > }}

Để gửi tin nhắn các clients (là một server hay service khác, hoặc ứng dụng bất kỳ có kết nối đến SMS Service) gọi phương thức SendSms() đến SMS Service. Phần còn lại SMSS sẽ tự động thực hiện gọi SMS Gateway thông qua HTTP request để yêu cầu GSM Modem thực hiện lệnh AT gửi tin nhắn. SMS Service sẽ trả kết quả cho client khi hoàn thành việc gửi tin nhắn. Kết thúc gửi tin nhắn.

Phiên bản trước (legacy)

5.6.1 - SMS Service (Legacy)

SMS Service (Legacy)

Đây là phiên bản đầu tiên của SMS Service nhằm hỗ trợ chức năng gửi và nhận tin nhắn. Phiên bản viết hoàn toàn bằng Node.js và dùng thư viện node-serialport để giao tiếp với GSM modem. Các luồng quản lý logic và sử lý hàng đợi tin nhắn được hiện thực dựa trên ý tưởng từ thư viện modem

{{ < svg “content/docs/services/sms/img/legacy.svg” > }}

6 - REST API

REST API

Identity Service

Collector Service API v2

SMS Service

7 - IoH

Introduction

Architecture

7.1 - OMOP CDM

OMOP CDM

Overview

IoH adaption

7.2 - User Attributes

Quy ước User Attribute theo URN

Cú pháp chung:

urn :[oave]:[Tên theo quy định của VDAT]|Các tùy chỉnh cấu hình ứng với tổ chức

Bảng quy ước chuẩn chung

Danh mục tổ chức

Danh mục tính năng (feature)

Cú pháp dành cho Bệnh viện Hùng Vương (Khoa sản bệnh)

urn : oave :bvhv-ksb: project :[projectId]: group :[groupId]: feature : pi-attribute

hoặc

urn : oave :bvhv-ksb: project :[projectId]: group :[groupId]: feature : researcher -attribute

hoặc

urn : oave :bvhv-ksb: project :[projectId]: group :[groupId]: feature : participant-attribute

Cú pháp danh cho quy trình VVHA

urn : oave :vvha: project :[projectId]: group :[groupId]: feature :invation

hoặc

urn : oave :vvha: project :[projectId]: group :[groupId]: feature :examination

hoặc

urn : oave :vvha: project :[projectId]: group :[groupId]: feature :archives

hoặc

urn : oave :vvha: project :[projectId]: group :[groupId]: feature :transfer