development guide - mbot-dev/1000_builder GitHub Wiki

4. 開発の手順

4-1. プロジェクトから支給されるもの

• 開発用のAPIサーバー
• バリデージョン チェック用のサーバー
• 本稼働用のAPIサーバー
• アクセス・トークンを取得するための資格情報（Consumer Key と Secret Key）
• 対象となる病院の医療期間ID
• 質問の受付場所（このリポジトリのissue）

4-1.1 資格情報と医療期間ID

• 資格情報 => ベンダー毎に付与、開発と本稼働で同じものを使用
• 医療期間ID => 病院毎に付与

4-2. 方針決定

• API一覧を参考にし、電子カルテからどの情報を千年カルテに送信するかを決定する。

4-3. アクセス権設定

• 病院の方針に基づき、情報の種類（病名、処方、報告書...）毎にアクセス権を設定する。

4-4. プログラミング (API使用ガイドを参照)

• APIのJSONデータを生成できるようにする。
• POST手順を組み込む。
• コンポジジョン単位にUUIDを生成しデータベース等で管理する。（次項の修正と削除で必要）

4-5. バリデーション チェック

• 開発用のAPIサーバーからは生成したMMLが返却される。
• これをバリデーションサーバーを使用して妥当性の検証を行う。

検証が不合格になるケース

• JSON構造が間違っている。
• JSONの属性名が間違っている。
• 必須データが入っていない。
• セットする値が間違っている。

• MMLテーブルの値を使用するケース
• 日数や期間等の指定 PND 形式を使用していない
• 日付と時刻の区切り文字 T が必要

4-6. 送信した診療データ（コンポジション）が修正された場合

• 修正されたデータでコンポジションを再度送信する。
• その際、コンテキストの UUID は修正前のものを使用する。
• HTTPメソッドはPOSTとする。（PUTではない、またURLは同じ）

4-7. 送信した診療データ（コンポジション）を削除する場合

• コンテキストの UUID に削除対象のものを設定する。
• confirmDate は削除した時刻（削除対象のconfirmDateより新しい事）を設定する。
• patient は対象患者。
• creator 削除対象の医師とは異なっていても良い。
• accessRight は不要。
• コンポジションのcontent属性は不要。（content属性自体がないこと）
• RESTのエンドポイントは POST の場合に同じであるが、HTTP メソッドは DELETE とする。

4-8. 開発用のサーバーと本稼働用サーバーの違い

項目	開発用	本稼働用
生成したMML	返却する	返却しない
外部参照ファイル	無視	プロジェクトへ送信
コンポジション修正	修正版MMLを返却	返却しない
コンポジション削除	レスポンス: HTTP statusのみ	同左