課題
患者、日付、指示、症状経過、実施状況、確認者が分散し、転記・確認・例外処理に手間が生じていました。
Case study / Medical operations
Juveka Orders
医療現場の指示・記録・確認を、患者と日付を軸に整理したWebアプリです。要件整理済みの構想から、独立した公開デモまでを約2週間で反復開発しました。
公開デモは完全架空データです。ログイン情報は、このポートフォリオを共有した連絡経路で案内されたものをご利用ください。
約2週間要件整理済みの構想から独立デモまで
4種類管理者・医師・看護師・事務
27 / 27UI回帰
10 / 10書き込み回帰
Project summary
課題・解決・結果を、先に確認できます。
制作期間約2週間の反復開発
担当範囲要件整理・設計・実装・試験・公開・運用設計
技術構成PHP 8系・MariaDB（データベース）・Nginx（Webサーバー）・Ubuntu・Python 3
解決
患者と日付を共通軸にし、4つの役割と二段階認証を設定しました。繰越、締め処理、監査、バックアップ・復元も一つの運用へ整理しています。
結果
主要UI 27件、書き込み回帰、4アカウントの認証、公開範囲、復元結果を分けて確認し、架空データだけの独立デモを公開しました。
掲載図は画面構成と業務フローを説明する図です。実際の操作画面は公開デモで確認でき、実患者・実職員データは使用していません。
約3分で確認できる内容
- ログインと二段階認証
- 役割別に変わるメニュー
- 今日の指示と患者別入力
- 患者管理・月間印刷
画面内の患者・職員情報はすべて架空です。公開デモは本番環境・実データと分離しています。
制作事例の概要
医療指示の業務では、患者、日付、指示内容、実施状況、症状経過、確認者が互いに関係します。紙や画面が分かれていると、継続する指示の転記、当日の確認、退院や再入院、過去記録の検索で手間と判断漏れが増えます。
そこで、患者と日付を共通の軸にし、医師、看護師、事務、管理者が必要な範囲だけを扱えるようにしました。単に入力フォームを作るのではなく、翌日繰越、重複防止、状態変化までを扱います。さらに、締め処理・印刷・監査・復元も一つの運用として設計しています。
| 制作期間 | 要件整理済みの構想から、実装、画面修正、権限調整、回帰試験、TOTP導入、独立公開デモまで約2週間。 |
|---|---|
| 対象利用者 | 管理者、医師、看護師、事務の4種類。表示だけでなくサーバー側の実行権限も分離。 |
| 主な目的 | 患者別・日付別に指示と経過を探しやすくし、継続指示と確認状況に加えて、締め処理と履歴まで一つにつなぐ。 |
| 公開方法 | 既存本番とは別サーバー・別DB・別認証情報で構築した独立デモ。実患者・実職員データは0件。 |
| 完成判定 | 主要機能、認証、回帰試験、バックアップ・復元、公開デモの確認後、開発から運用・保守フェーズへ移行。 |
主な機能
画面数を増やすのではなく、日常業務の頻度と例外の重要度から機能を整理しました。下記は代表機能です。
患者別・日付別入力
患者を選び、当日の指示、症状経過、状態、看護師サインを同じ流れで入力。日付移動時も対象患者を見失いにくくします。
翌日繰越・過去コピー
継続する指示や症状経過を次の日へ引き継ぎます。空欄判定、既存データ、重複を確認してから処理します。
定型文管理
よく使う文章を分類して登録。入力時間を短くし、表現のばらつきを抑えます。
患者管理
入院、退院、再入院、同じ医院側患者IDの再利用など、通常入力以外の状態変化も扱います。
締め・月間表示・印刷
日次の確認から月間の見通し、紙が必要な場面の印刷まで、業務の順序に合わせて配置します。
役割別メニューと権限
管理者、医師、看護師、事務ごとに閲覧範囲と操作を分け、画面表示と実権限を一致させます。
TOTP二段階認証（時間で変わる6桁コード）
パスワードに加え、認証アプリの6桁コードを使用。同一時間枠のコード再利用防止も考慮しました。
監査・バックアップ・復元
重要操作の記録、公開領域外バックアップ、復元後のテーブル・関連・トリガー・HTTP確認を行います。
重複・入力検証
同一患者、日付、状態の二重登録や不正日付を、画面だけでなくサーバー側でも確認します。
独立した公開デモ
本番コードを安全にサニタイズし、秘密情報や実データを持ち込まず、架空データを新規作成しました。
役割ごとの考え方
| 役割 | 主な利用場面 | 設計上の注意 |
|---|---|---|
| 医師 | 指示の入力・確認、継続指示の判断 | 入力対象と日付を明確にし、不要な管理操作を見せない。 |
| 看護師 | 指示確認、実施状況、症状経過、サイン | 日常頻度が高いため、患者移動と入力の手数を抑える。 |
| 事務 | 必要な範囲の確認、書類・印刷等 | 医療判断に関わる操作と事務操作を混在させない。 |
| 管理者 | 利用者、設定、締め、監査、バックアップ | 強い権限を通常画面から分離し、重要操作を記録する。 |
| 役割 | 指示確認 | 患者入力 | 管理設定 | 印刷 |
|---|---|---|---|---|
| 管理者 | ○ | ○ | ○ | ○ |
| 医師 | ○ | ○ | 一部 | ○ |
| 看護師 | ○ | 限定 | ― | ○ |
| 事務 | 限定 | ― | ― | ○ |
どのような言語で、どのような仕組みか
Webアプリ本体のサーバー側はPHP 8系、データ保存はMariaDB、Web配信はNginx、OSはUbuntu Linuxです。画面はHTML、CSS、JavaScriptで実装しました。書き込み回帰試験と検査自動化にはPython 3を使用し、本体とテスト基盤を分けています。
仕組みの要点
- 画面からボタンを隠すだけでなく、PHP側で権限を再判定
- 入力値、日付、対象ID、CSRFトークンをサーバー側で検証
- HTTPS、Secure、HttpOnly、SameSite属性でセッションを保護
- TOTP秘密情報を暗号化して保存し、同一時間枠コードの再利用を防止
- 公開ディレクトリと設定・バックアップ・復元ツールを分離
- MariaDBの外部キー、関連データ、トリガーを復元後にも確認
- Python 3で画面遷移、CSRF、追加、更新、重複防止、状態変化を再実行
- 本番、非公開テスト、公開デモを、サーバー・DB・認証情報単位で分離
この構成を全案件へ固定するわけではありません。利用人数、既存環境、予算、保守担当、外部連携、可用性に合わせて、より小さな構成や別の技術を選ぶ場合があります。
開発時に注意した点
1. 現場の言葉とデータ構造を混同しない
利用者には「患者」「指示」「症状経過」「締め」と見せながら、内部ではID、日付、状態、関連を明確に分けます。画面の分かりやすさとデータの一貫性を両立させました。
2. 役割ごとの責任範囲を二重に確認する
メニュー表示の違いだけでは安全とは言えません。URLを直接開いた場合や不正な送信でも操作できないよう、サーバー側の権限判定も確認しました。
3. 日付をまたぐ業務を通常処理と同じにしない
翌日繰越・過去コピー・締め後・退院・再入院では、単純な複製が重複や誤記録につながります。既存データと状態を確認して処理します。
4. 患者IDの再利用と重複を区別する
同じ医院側患者IDが再び現れた場合、新しい人物として重複登録するのではなく、既存患者との関係を確認して再利用できる設計にしました。
5. 医療情報を公開デモへ持ち込まない
実患者・実職員データ、内部パス、DB名、ログ、バックアップ、秘密鍵、TOTP秘密情報を公開デモへ移さず、架空データと別認証情報を作成しました。
6. 変更前へ戻せる状態を作ってから修正する
修正前バックアップ、構文確認、HTTP確認、DB差分、安全マーカーを組み合わせ、失敗時に自動または手動で戻せる手順を残しました。
7. 「成功」の対象を混ぜない
構文が正しい、ページが200、書き込みが成功、権限が正しい、復元できる、という結果は別です。それぞれを分けて記録しました。
8. 完成後は開発を続けすぎない
主要機能と回帰試験が完了した後は、明確な不具合や追加要望がない限り、開発ではなく運用・保守フェーズへ切り替えます。
品質のテスト内容
「ログインできた」「画面が開いた」だけで完成とは判断していません。実行前検査、HTTP、書き込み、権限、UI、認証、DB、復元を別の試験として確認しました。
| 試験 | 対象 | 結果 |
|---|---|---|
| UI回帰 | 9画面×PC・タブレット・スマートフォン相当 | 27 / 27 PASS |
| 書き込み回帰 | 患者追加、重複防止、退院、再入院、競合など | 10 / 10 PASS |
| TOTPログイン | 管理者・医師・看護師・事務 | 4 / 4 PASS |
| 外部公開制御 | 公開ページと重要設定ファイル | 公開200・設定遮断 |
| 復元確認 | DB構造、トリガー、主要HTTP、データ内容 | 照合PASS |
テストの限界も明記
これらは確認した対象に対する結果であり、全ての環境・全ての操作・法令適合を無条件に保証するものではありません。実運用では、利用組織の規程、端末、ネットワーク、バックアップ保管、障害連絡、保守契約を含めて再確認します。 詳細は実運用前の確認事項をご覧ください。
運用・その他
公開領域の分離設定、バックアップ、復元ツールをWeb公開領域外へ置き、直接アクセスを403で遮断。
バックアップコードとDBを定期保存し、世代と保存場所を分ける。作成成功だけで完了にしない。
復元確認復元後にDB構造、トリガー、関連、HTTP、主要機能を照合し、「戻せる」ことを確認。
独立デモ本番を触らず、別VPSへサニタイズ済みコード、空スキーマ、架空データを構築。
HTTPS・SSHHTTPS、自動更新試験、SSH鍵認証、rootログイン禁止、パスワードSSH禁止を確認。
引き継ぎ配置、実行環境、認証、テスト、復元、安全上の禁止事項を記録。
今後の改善候補
- 公開デモの案内をより分かりやすくする
- 重要な回帰試験を追加し、結果の説明を更新する
- 監視・障害連絡・保守範囲を運用条件として明文化する
この制作事例は、特定の医療機関へそのまま導入できる完成パッケージを意味しません。実運用では、業務要件、法令、院内規程、個人情報保護、監査、障害時対応、保守体制を個別に確認する必要があります。
約2週間の開発で得た知見
業務名ではなく「判断」を聞く
「指示を入力する」だけでは設計できません。誰が、どの情報を見て、何を判断し、次の誰へ渡すかを聞くことで必要な状態と権限が分かります。
例外は後回しにしない
退院・再入院・日付変更・重複・締め後など、件数が少なくても誤りの影響が大きい処理は、早めに画面とデータで確認します。
回帰試験は修正速度を上げる
一つを直した後、以前の機能を手作業で全て確認するのは困難です。Pythonの自動試験と画面確認を分け、再確認を短くしました。
公開デモも別の製品として扱う
本番のコピーをそのまま公開せず、秘密情報除去、空DB、架空データ、別認証、noindex、Cookie範囲などを設計しました。
うまくいかなかった修正を本番へ残さない
既存コードの位置を前提にした修正が成立しなかった際は、成功扱いせず自動ロールバックし、原因と再確認範囲を分けて別の方法へ切り替えました。
他業種へ応用できる部分
患者を「顧客」「案件」「利用者」「銘柄」に、指示を「予約」「工程」「申し送り」「検証条件」に置き換えても、役割、状態、期限、履歴、権限、バックアップという構造は共通します。Juvekaはこの共通部分を再利用し、各現場固有の言葉と例外へ開発時間を使います。
実運用前に必要な確認
- 利用組織の規程、法令、ガイドライン
- 端末・ネットワーク・利用者教育
- 監視、障害連絡、復旧、保守の責任分界
- 第三者脆弱性診断の必要性と範囲
- バックアップ保管先と復元訓練
制作事例の試験結果は、確認した範囲の結果です。実運用の安全性や法令適合を無条件に保証するものではありません。