医療系システム・レセコン導入— 取適法確認

1. 導入プロジェクトのフェーズ分割

1-1. 要件定義と基本設計

初動フェーズでは、診療科構成・レセプト運用・既存機器連携の要件を文書化し、成果物として要件定義書を受領します。
この段階の完了を検収対象とするか、本番稼働まで含めた一括契約とするかを契約で決めます。
適用判定は発注コンプライアンスのチェックリストも参照してください。

1-2. カスタマイズと設定

マスター登録・算定ルール・レセプトチェック設定など、現場の業務に合わせた設定作業は工数が読みにくい部分です。
設定項目一覧と完了条件を別紙にし、部分検収の単位を明確にします。

1-3. 本番稼働と並行運用

旧システムとの並行運用期間を設ける場合、並行期間中のサポート範囲・追加費用を契約に書きます。
「とりあえず使える」状態と「検収完了」の境界を現場と合意しておきます。

2. データ移行と検収

2-1. 移行対象データの範囲

患者基本情報・診療履歴・レセプトデータなど、移行対象と移行しないデータを契約に列挙します。
移行漏れが後から判明すると、再移行の追加発注と検収のやり直しが発生します。

2-2. 移行テストと本番切替

テスト環境での移行確認と本番切替日を分け、それぞれの完了条件をチェックリスト化します。
本番切替日を受領日とするか、一定期間の安定稼働後を検収日とするかを事前に決めます。
受領日起算は支払60日ルールの起算点も参照してください。

2-3. 移行不能データの扱い

旧システムの形式都合で移行できない項目がある場合、代替手段と責任分界を書面に残します。
口頭説明だけでは、検収時の「当初説明と違う」争点になります。

3. 保守・サポート契約との関係

3-1. 導入と保守の契約分割

導入プロジェクトと年間保守は別契約に分けると、検収・支払・更新時期が整理しやすくなります。
保守料金を導入費用に含める場合、初年度と次年度以降の境界も明記します。

3-2. 障害対応と追加開発

障害修正は保守範囲、機能追加は別発注と線引きします。
診療報酬改定に伴うマスタ更新など、定期発生する作業の扱いも契約に書いておきます。

3-3. 継続的業務委託の該当性

長期の運用支援が継続的業務委託に該当するかは取引実態次第です。
継続委託の整理は継続的業務委託の定義も参照してください。

4. 書面記載と機密・個人情報

4-1. 記載事項の整備

報酬・納期・検収条件・支払期日など、取適法上の記載事項を発注書面に含めます。
記載事項の型は記載事項のテンプレートをベースにすると漏れが減ります。

4-2. 委託先の再委託

クラウド基盤や外部連携サービスを利用する場合、再委託・第三者提供の範囲を契約に触れます。
医療情報の取扱いに関する社内規程との整合も確認します。

4-4. ベンダー更改・乗換え時のデータ移行

レセコン更改では、旧ベンダーからのデータエクスポートと新ベンダーへのインポートを別発注として扱う設計もあります。
旧契約のデータ提供義務・形式・提供期限を旧ベンダー契約に、受入テスト条件を新ベンダー契約にそれぞれ書きます。
乗換え期間中の二重保守料金の扱いも合意し、台帳上は旧契約行と新契約行を分けて受領日を記録してください。

5. 実務シナリオ

5-1. 多診療科クリニックの段階導入

内科から順次導入し、後から整形外科を追加する場合、診療科ごとに検収・受領日を切るか一括かを決めます。
台帳は診療科単位またはフェーズ単位で分け、支払期日を個別管理します。

5-2. レセプト不具合が本番後に発覚

本番稼働後に算定ミスが見つかった場合、瑕疵対応か追加開発かを契約条項に沿って整理します。
無償修正期間の有無・上限を契約に書いておくと、現場の判断がぶれにくくなります。

5-3. 発注前チェック（医療系システム向け）

フェーズ分割・移行範囲・本番検収条件・保守との境界・再委託・教育実施を書面に含めるか確認します。
ベンダー提案書の機能一覧と、発注書面の給付内容が一致しているかクロスチェックします。

6. 導入フェーズと検収起点の対照表

例えばレセプトチェック設定だけ先行納品する場合、設定完了日と本番切替日で受領日が2つ発生します。
台帳上はフェーズ別の行に分け、支払期日を個別に計算してください。

よくある質問

Q. クラウド型レセコンはライセンス料と導入支援を分けるべきですか

分けると検収と支払の起点が明確になります。
一体契約の場合も、初回導入支援と月額利用料の内訳を書面に残します。

Q. 操作説明だけ未実施で検収できますか

契約上の検収条件次第です。
説明会を検収条件に含めるなら、実施記録がないまま検収完了にしない運用が安全です。

Q. ベンダー担当者が個人事業主の場合は

取引実態と資本金・従業員数により適用判定が変わります。
記載事項・支払期日・書面交付の遵守が求められる場合があります。

Q. オンライン資格確認との連携は別発注ですか

連携設定が導入スコープに含まれるか契約で確認します。
含まれない場合は追加発注として書面化し、台帳に別行で記録します。

Q. 導入遅延時のペナルティは書けますか

契約設計次第ですが、一方的な減額は買いたたき規制との関係で注意が必要です。
遅延の事実・原因・合意した対応を記録に残し、報酬改定は双方の合意で行います。

まとめ

• 要件定義から本番稼働までフェーズを分け、検収単位を明確にする
• データ移行の範囲と完了条件をチェックリスト化する
• 導入と保守・追加開発の境界を契約に書く
• 受領日を台帳に記録し、60日起算の起点を空欄にしない

6. 医療系システム導入の発注前チェックリスト

• フェーズごとの成果物と検収条件を別紙にしたか
• データ移行対象・移行不能項目の扱いを合意したか
• 本番切替日と安定稼働後検収のどちらを起点にするか決めたか
• 保守・障害対応・追加開発の線引きを契約に書いたか
• 操作説明会の回数と検収との関係を明記したか
• 再委託・クラウド利用の範囲を確認したか

キックオフ後に追加された機能要望は、要件定義書の改版と変更依頼書で管理し、無明記の口頭追加を量産フェーズに持ち込まない運用にします。
ベンダー更改時は旧契約のデータ提供期限と新契約の移行テスト完了を台帳上つなぎ、受領日未入力のフェーズがないか月次で確認してください。
診療科追加のたびに設定工数が増える案件では、追加発注書面を診療科単位で起票し、本番稼働日を個別に記録する設計が安全です。

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
医療情報の取扱い・個別の契約内容については専門家にご確認ください。