課題
患者、日付、指示、症状経過、実施状況、確認者が分散し、転記・確認・例外処理に手間が生じていました。
Case study / Medical operations
Juveka Orders
医療現場の指示・記録・確認を、患者と日付を軸に整理したWebアプリケーション。約2週間の反復開発で、日常操作、役割別権限、二段階認証、回帰試験、バックアップ・復元、独立公開デモまで構築しました。
約2週間要件整理から公開デモまで
4ロール管理者・医師・看護師・事務
27 / 27UI回帰確認
7 / 7書き込み回帰試験
Project summary
課題・解決・結果を、先に確認できます。
制作期間約2週間の反復開発
担当範囲要件整理・設計・実装・試験・公開・運用設計
技術構成PHP 8系・MariaDB・Nginx・Ubuntu・Python 3
解決
患者と日付を共通軸にし、4つの役割、二段階認証、繰越、締め、監査、バックアップ・復元を一つの運用へ整理しました。
結果
主要UI 27件、書き込み回帰、4アカウントの認証、公開範囲、復元結果を分けて確認し、架空データだけの独立デモを公開しました。
掲載図は画面構成と業務フローを説明する図です。実際の操作画面は公開デモで確認でき、実患者・実職員データは使用していません。
制作事例の概要
医療指示の業務では、患者、日付、指示内容、実施状況、症状経過、確認者が互いに関係します。紙や画面が分かれていると、継続する指示の転記、当日の確認、退院や再入院、過去記録の検索で手間と判断漏れが増えます。
そこで、患者と日付を共通の軸にし、医師、看護師、事務、管理者が必要な範囲だけを扱えるようにしました。単に入力フォームを作るのではなく、翌日繰越、重複防止、状態変化、締め、印刷、監査、復元までを一つの運用として設計しています。
| 制作期間 | 約2週間。要件整理、実装、画面修正、権限調整、回帰試験、TOTP導入、公開デモ構築を反復。 |
|---|---|
| 対象利用者 | 管理者、医師、看護師、事務の4種類。表示だけでなくサーバー側の実行権限も分離。 |
| 主な目的 | 患者別・日付別に指示と経過を探しやすくし、継続指示、確認状況、締め、履歴を一つにつなぐ。 |
| 公開方法 | 既存本番とは別サーバー・別DB・別認証情報で構築した独立デモ。実患者・実職員データは0件。 |
| 完成判定 | 主要機能、認証、回帰試験、バックアップ・復元、公開デモの確認後、開発から運用・保守フェーズへ移行。 |
主な機能
画面数を増やすのではなく、日常業務の頻度と例外の重要度から機能を整理しました。下記は代表機能です。
患者別・日付別入力
患者を選び、当日の指示、症状経過、状態、看護師サインを同じ流れで入力。日付移動時も対象患者を見失いにくくします。
翌日繰越・過去コピー
継続する指示や症状経過を次の日へ引き継ぎます。空欄判定、既存データ、重複を確認してから処理します。
定型文管理
よく使う文章を分類して登録。入力時間を短くし、表現のばらつきを抑えます。
患者管理
入院、退院、再入院、同じ医院側患者IDの再利用など、通常入力以外の状態変化も扱います。
締め・月間表示・印刷
日次の確認から月間の見通し、紙が必要な場面の印刷まで、業務の順序に合わせて配置します。
役割別メニューと権限
管理者、医師、看護師、事務ごとに閲覧範囲と操作を分け、画面表示と実権限を一致させます。
TOTP二段階認証
パスワードに加え、認証アプリの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、復元を別の試験として確認しました。
テストの限界も明記
これらは確認した対象に対する結果であり、全ての環境・全ての操作・法令適合を無条件に保証するものではありません。実運用では、利用組織の規程、端末、ネットワーク、バックアップ保管、障害連絡、保守契約を含めて再確認します。
運用・その他
公開領域の分離設定、バックアップ、復元ツールをWeb公開領域外へ置き、直接アクセスを403で遮断。
バックアップコードとDBを定期保存し、世代と保存場所を分ける。作成成功だけで完了にしない。
復元確認復元後にDB構造、トリガー、関連、HTTP、主要機能を照合し、「戻せる」ことを確認。
独立デモ本番を触らず、別VPSへサニタイズ済みコード、空スキーマ、架空データを構築。
HTTPS・SSHHTTPS、自動更新試験、SSH鍵認証、rootログイン禁止、パスワードSSH禁止を確認。
引き継ぎ配置、実行環境、認証、テスト、復元、安全上の禁止事項を記録。
この制作事例は、特定の医療機関へそのまま導入できる完成パッケージを意味しません。実運用では、業務要件、法令、院内規程、個人情報保護、監査、障害時対応、保守体制を個別に確認する必要があります。
約2週間の開発で得た知見
業務名ではなく「判断」を聞く
「指示を入力する」だけでは設計できません。誰が、どの情報を見て、何を判断し、次の誰へ渡すかを聞くことで必要な状態と権限が分かります。
例外は後回しにしない
退院、再入院、日付変更、重複、締め後など、件数が少なくても誤りの影響が大きい処理は早めに画面とデータで確認します。
回帰試験は修正速度を上げる
一つを直した後、以前の機能を手作業で全て確認するのは困難です。Pythonの自動試験と画面確認を分け、再確認を短くしました。
公開デモも別の製品として扱う
本番のコピーをそのまま公開せず、秘密情報除去、空DB、架空データ、別認証、noindex、Cookie範囲などを設計しました。
他業種へ応用できる部分
患者を「顧客」「案件」「利用者」「銘柄」に、指示を「予約」「工程」「申し送り」「検証条件」に置き換えても、役割、状態、期限、履歴、権限、バックアップという構造は共通します。Juvekaはこの共通部分を再利用し、各現場固有の言葉と例外へ開発時間を使います。