見出し画像

🚀Web3医療DAppを開発する!🚀

皆さんこんにちは!!

今回は、スマートコントラクトを利用して患者の医療データを管理するアプリを開発するアプリの作成に挑んでみましたのでその過程等をまとめていきます!
UNCHAINというWeb3エンジニアコミュニティに参加させていただいているのですが、一定条件を満たすとUNCHAIN STARとなることができます。

その一定条件というのが、UNCHAIN STAR試験に合格するというものです!

開発したアプリの概要

今回挑戦した試験の概要は下のサイトをご覧ください!

また、vercel上にアプリを公開しておりますので、まずアプリに触れてみたい!という方は下のURLからアクセスしてください!

ざっくりと説明すると患者と医者の間でやり取りするカルテ情報の管理と治療費と支払い、医師の登録を可能とするWeb3アプリとなっています!画面は4画面存在して下記の通りとなっています。

  1. Connect Wallet画面

  2. Home画面

  3. Regist画面

  4. DoctorInfo画面

実際に患者と医者の間でこのアプリを使用した時の想定のやり取りをフロー図に起こしたものがありますのでそちらも貼り付けます。

想定フロー図

デプロイしたスマートコントラクトですがgoreliとmunbaiの2つのネットワークにデプロイしました。内容については差異はないのでお好みの方をEtherScanかPolygonScanでご確認ください。

  1. Goerli版

    0x177acf501eF7d2b090d94fd3bd2BE773736598E1

  1. Munbai版

  0x83f15ccdD1278908dF5bC646E903afE2f342deC1

簡単な機能一覧等の説明

それでは機能等の解説になります。
今回のアプリを作成するにあたり、一番核となるMedicalDataコントラクトに実装した機能一覧をまとめます。

機能一覧表

また、コントラクトに実装した変数とメソッドの概要も表にまとめましたので記載いたします。
名前と更新日時、血液データという少ないデータだからこその実装かもしれませんがベース部分はこの考え方で良いと考えています。

変数一覧

メソッド一覧

医療データという大切なデータを取り扱うスマートコントラクトですのでテストコードもしっかりと書きました!! かなり長くなってしまうのでコードの掲載は割愛させていただきますが、正常系はもちろんのこと、医者の権限を持つアドレスからの呼び出ししか許さないメソッドを患者のアドレスから呼び出そうとした時にエラーが発生するかなど、異常系のテストシナリオも記載しています。

テストの結果は下記の通りです!


Using network 'development'.


Compiling your contracts...
===========================
> Compiling ./contracts/MedicalData.sol
> Artifacts written to /var/folders/0c/vbkwk57s4lb21y1ts4ndr9zh0000gn/T/test--2339-yBPTyliYIpnH
> Compiled successfully using:
   - solc: 0.8.0+commit.c7dfd78e.Emscripten.clang



  Contract: MedicalData Contract tests!!
    initialization
      ✓ confirm owner address
      ✓ confirm doctor's address (40ms)
      ✓ confirm doctor's name (116ms)
    get doctor info tests
      ✓ get doctor info
    add a new doctor
      ✓ confirm doctor's address and name (231ms)
      ✓ Should revert when contract is called from invalid address (421ms)
    approve method tests
      ✓ approve (99ms)
      ✓ chageStatus (60ms)
      ✓ should revert when contract is called from invalid role address (135ms)
      ✓ should revert when contract is called from invalid role address (47ms)
    claim approve method tests
      ✓ require approvement (88ms)
      ✓ should revert when contract is called from invalid role address (48ms)
    create a new medical data!!
      ✓ create (289ms)
      ✓ should revert when contract is called from invalid role address
      ✓ get patient's medical data (318ms)
      ✓ should revert when contract is called from invalid role address (367ms)
      ✓ should revert when contract is called from invalid role address (143ms)
    update a medical data!!
      ✓ edit (589ms)
      ✓ should revert when contract is called from invalid role address (420ms)
    delete a medical data!!
      ✓ delete (528ms)
      ✓ should revert when contract is called from invalid role address (305ms)
    test for paying Treatment costs!!
value: 10000000000000000
contractBalance: 20000000000000000
      ✓ pay !! (393ms)
value: 10000000000000000
      ✓ should revert when contract is called from invalid role address (57ms)
value: 10000000000000000
contractBalance: 20000000000000000
      ✓ should revert when contract is called from invalid role address (172ms)


  24 passing (12s)

画面の説明

次に各画面の説明になります。
画面のコンポーネント自体はベースとなるindex.jsとApp.jsを除いて大きく4つの画面用のコンポーネントで構成されていますが権限により表示を切り替えるなどしています!

1. Connect Wallet 画面

ウォレットで接続する前の画面
右上のボタンから接続する。

2. Home 画面

この画面は接続したウォレットのアドレスによって描画される内容が変化します。

Home 画面 パターン 1

Home 画面 パターン 2

Home 画面 パターン 3

Home 画面 パターン 4

Home 画面 パターン 5

Home 画面 パターン 6

3. Regist 画面

この画面は管理者権限専用の画面で新規に医者を登録することができる画面になります。
管理者以外がアクセスすると入力フォーム等は描画されません。

Regist 画面 管理者の場合

Regist 画面 管理者以外の場合

4. DoctorInfo 画面

この画面も患者と医者で画面表記が変化します。
医者の場合は自分のアドレスと名前が表示されます。
患者の場合は、このコントラクトに登録されている医者の情報と承認権限を付与するボタン・剥奪するボタンが描画されます。(医者から承認権限を要求されている場合にはその旨のメッセージも表示されます。)

DoctorInfo 画面 医者の場合

DoctorInfo 画面 患者の場合

最後に

残課題としては、医療データというプライベートデータを以下にしてオンチェーン上で安全に管理するかということです。皆から過去のブロックデータを全て確認できるというパブリックブロックチェーンを使っているからこその課題なのですが、ここが最も難しい点だと考えています。

暗号化されたデータであってもブロックに一度登録してしまうと過去に遡って参照できてしまうので、鍵の情報が漏洩したり、暗号アルゴリズムが解読されたりするとアウトなので、やはりデータ本体はオフチェーンのほうが良さそうです。そしたらそのデータをどこに管理するの??という課題が出てくるわけで難しいですね笑。

EUで進めているというデジタルIDウォレットの仕組みが気になるところではありますが、SBTや Lit Protocol等を使ってアクセスコントロールをうまく制御できれば面白そうなアプリが出来そうです!!引き続きアプリを改良していきたいと思います!

読んでいただきありがとうございました!!

この記事が気に入ったらサポートをしてみませんか?