医療系システムのためのデータ履歴管理アプローチ - Open Sink, Closed Sink
医療系システムにおけるデータ履歴管理の設計に焦点を当て、ガイドラインや法的要件を満たすデータモデルを提案しています。 特に電子保存の三原則の担保やHL7 FHIRとの接続を考慮しながら、データの過去の状態の正確な復元を可能にするためのRDB設計を検討し、現実的な運用に耐え得る設計を示します。
400万人が利用する会社訪問アプリ
副業(医療系システム開発) / ヘルステックエンジニア
総合病院の医事課にて事務総合職として医事管理業務全般に従事したのち、エンジニアに転職してWebアプリケーション・業務システム開発に携わってきました。
これまでの社会人生活で、医療に関してはユーザーとベンダー双方の立場から、多くの領域や役割から経験を積むことができました。
医療系システムの開発に従事しております。
医療系システム開発に従事していました。
「医療事務 × エンジニア」というこれまでのキャリアを活かし、実装、要件定義、制度調査、基本設計、詳細設計、QA、CS、CX、CREとして、各方面で働いてきました。
元医療事務の現職Webエンジニアとして、メンバーのドメイン理解の深化、DB設計やデザインへの助言、要件調査などに従事しました。
バックエンドのWebエンジニアとして、主にWebフレームワークLaravelを用いた自社サービスのPHPアプリケーションの開発に携わっていました。
社内のエンジニアは、フロントエンド・バックエンドともに未経験者や初心者が過半数を占めており、私自身も未経験者のひとりでした。 こうした事情から、開発陣の環境や文化といったものは十分に整備・醸成されているとは言えず、例えば次のような課題が見られました。 - 開発環境が人によってXAMPPだったりUNIXの仮想マシンだったりまちまち - Gitをmasterブランチ単一で運用し、作業途中であっても各自masterに直にcommitするため、デプロイ時にproduction環境でシンタックスエラーが頻発する - 単体テストを書かない - 同じ基本構造をもつ画面や機能であっても、各メンバーが都度思い思いに新しく実装してしまうためバグが多発する そのため、バックエンドリーダーのサポートのようなポジションになった際に、主に次のような取組みを実施しました。 - フレームワークの機能を活用した、メンバーが開発しやすいような仕組みや機能の実装 - 開発環境としてVagrantを導入(メンバーの練度を考慮するとDockerは敷居が高かったため) - Gitの運用やリリース時のフローを簡易に策定 - プルリクエストによるレビューを開発フローに取り入れる - コーディング規約の整備、開発に有用なプラグインやツールの紹介や啓蒙、導入 - 単体テストは個人の裁量に任せた(敷居が高かったため) - メンバーとの1on1の実施 こうした取組みに対し、定量的な指標による評価や監視はおこなっていなかったものの、一連の活動によってバグの発生の減少が見られたり、課題解消のために取組む機運が芽生えるといった効果は見受けられました。 その一方で、不慣れなプルリクエストの運用により、レビュー待ちのプルリクエストが滞留して開発のボトルネックになるなど、新たな問題も生じました。 新たに発生した課題に対して手を打つ前に私は退職してしまいましたが、これらの活動は短期的には一定の成果をおさめられたと考えています。 しかし長期的な目で見れば、私が組織的な活動としてメンバーを積極的に巻き込まなかったこと、社員の交代が激しい環境であることも手伝ってか、社内に新しい文化を根付かせるための継続的な取組みには繋がらず、一時的なものに留まりました。
急性期~亜急性期のDPC総合病院の医事課にて、事務総合職として診療報酬請求をはじめとする医事管理業務全般に携わっていました。 窓口受付、入院・外来会計、レセプト、査定減・返戻、自費未収金、施設基準、DPCデータ提出、マスタメンテ、労災・自賠責、これらに付随する経理処理など、医事課の担当業務はひととおり経験しました。
医療系システムにおけるデータ履歴管理の設計に焦点を当て、ガイドラインや法的要件を満たすデータモデルを提案しています。 特に電子保存の三原則の担保やHL7 FHIRとの接続を考慮しながら、データの過去の状態の正確な復元を可能にするためのRDB設計を検討し、現実的な運用に耐え得る設計を示します。