応用情報技術者 2019年 春期 午後 問06
薬剤管理システムの再構築に関する次の記述を読んで、設問1〜4に答えよ。
W病院は、複数の外来診療科をもっており、症状や病状に応じて処方箋を発行している。W病院には院内薬局があり、受診者の多くは院内薬局で薬剤の処方を受ける。
処方箋には期限があり、発行年月日から有効年月日までを、薬剤の処方を受けることのできる期間としている。
W病院では、受診者への医療サービス向上を目的に、薬剤管理システムの再構築を行うことになった。再構築するシステムには、医師の処方箋作成を支援する次のチェック機能を実装する。
・処方箋発行の際、処方しようとしている薬剤と過去6か月以内にW病院で発行した処方箋に記載の薬剤との組合せに対し、薬剤併用チェックを行う。薬剤併用チェックでは、併用を禁止する“併用禁忌”となる薬剤の組合せ、及び併用に注意を要する“併用注意”となる薬剤の組合せに該当しないことを確認する。
・院内調剤で処方することを前提に、処方箋発行時に院内薬局の薬剤に対する在庫チェックを行う。在庫チェックでは、発行した処方箋に記載の薬剤が、院内薬局で有効年月日まで確保されるよう、在庫の保証を行う。
開発に当たり設計した、薬剤管理システムのデータベースのE-R図を図1に示す。なお、“在庫量＿大人1日”、“処方量＿大人1日”とは、“大人1日の分量”を単位とした在庫量、処方量を示す。
このデータベースでは、E-R 図のエンティティ名をテーブル名に、属性名を列名にして、適切なデータ型で表定義した関係データベースによって、データを管理する。
業務処理と操作対象のテーブルを表1に示す。また、テーブルの列に対する処理内容を表2に示す。ここで、表2中の括弧付き数字は、表1中の業務処理の括弧付き数字に対応している。
〔薬剤併用チェック処理〕
薬剤管理システムでは、薬剤併用情報テーブルに“併用禁忌”と“併用注意”となる薬剤の組合せを保持しており、この情報を使い、薬剤併用チェックを行う。
“併用禁忌”と“併用注意”に該当する薬剤の組合せ一覧を出力する SQL を図2に示す。ここで、“:受診者ID”、“:半年前年月日”、“:処方箋ID”は、該当の値を格納する埋込み変数である。また、TO_DATE 関数は、指定された文字型の年月日を DATE 型に変換するユーザ定義関数である。
薬剤の組合せ一覧には、今回の外来受診では処方しない薬剤や院内薬局で処方を受けなかった薬剤の組合せも含まれており、出力内容を医師が確認し、必要に応じて処方する薬剤を見直す。見直しの結果、処方箋明細が 0 件になることもあるが、このような場合には、処方箋の発行は行わない運用とし、処方箋レコードは削除しない。
〔在庫チェック処理〕
在庫チェックでは、“発行した処方箋に記載の薬剤が、院内薬局で有効年月日まで確保されるよう、在庫の保証を行う.”という要件の判定を簡素化するために、処方箋を発行し、有効年月日までに院内薬局で処方する可能性のある薬剤の処方量の合計を、確保量として管理するビューを作成することにした.
ビューを作成するSQLを図3に示す。ここで、CURRENT_DATE 関数は、参照時の日付を DATE 型で返す日時関数である.
在庫チェックで在庫不足が判明した際は、医師は処方する薬剤の見直しや、長期処方を希望する受診者との処方量の調整を行う.
設問1：
図1中のa、bに入れる適切なエンティティ間の関連を解答群の中から選び、記号で答えよ。
解答群ア ●─○（水平直線、両端は線のみで矢印なし）
イ ○─●（水平直線、両端は線のみで矢印なし）
ウ ●─●（水平直線、両端は線のみで矢印なし）
エ ●─○→（右端に右向き矢印）
オ ←○─●（左端に左向き矢印）
カ ●─●→（右端に右向き矢印）
キ ←●─●（左端に左向き矢印）
ク ←──→（両端に左右逆向きの矢印、円なし）
模範解答
a：力
b：ウ
解説
解答の論理構成
-
【問題文】には
“受診者 → 外来受診［ a ］（1対多）”
と明示されており、左側の“受診者”は 1、右側の“外来受診”は多(0 以上)であることが分かります。さらに “→” が付いているので、矢印付き・右向きの 1‐多を示す記号を選びます。解答群で該当するのは “カ ●─●→” です。したがって
a：カ
となります。 -
同じく【問題文】には
“薬剤 → 薬剤在庫［ b ］（1対1）”
とあるため、両エンティティが互いに 1 対 1 で必ず対応することが分かります。矢印の有無は 1 対 1 の場合には不要なので、左右とも実線●で矢印無しの記号を選びます。解答群では “ウ ●─●” が該当します。したがって
b：ウ
となります。 -
以上より最終解答は
a：カ
b：ウ
誤りやすいポイント
- “1対多” という語だけを見て “○─○” を選んでしまうケースが多いですが、【問題文】に “→” が印字されているため矢印付きの選択肢でなければなりません。
- “1対1” と聞くと“●─○”を選ぶ誤り。本問の【問題文】では両エンティティが必須で 1 対 1 なので、左右とも必須 (●) を示す必要があります。
- 矢印の向きは外部キーの所在を示すのではなく、【問題文】に記載された “→” の向きをそのまま採ることに注意。
FAQ
Q: 空の“受診者”レコード（外来受診が一度もない人）は存在し得ますか？
A: はい。“受診者”は病院への初回登録時に作成され、その後の受診有無に依存しません。そのため左側が 0 以上、多側が 1 以上という“1対多”になります。
A: はい。“受診者”は病院への初回登録時に作成され、その後の受診有無に依存しません。そのため左側が 0 以上、多側が 1 以上という“1対多”になります。
Q: “薬剤在庫”が存在しない“薬剤”はあり得ますか？
A: 本システムでは“薬剤”マスタに登録した時点で“薬剤在庫”が必ず 1 行作成され、在庫量は “0 を設定する。(9)” とあります。したがって 1 対 1 の必須関係です。
A: 本システムでは“薬剤”マスタに登録した時点で“薬剤在庫”が必ず 1 行作成され、在庫量は “0 を設定する。(9)” とあります。したがって 1 対 1 の必須関係です。
Q: 矢印はどのような意味がありますか？
A: 本問題では【問題文】に直接 “→” が印字されているため、その向きをそのまま図示する慣例の記号を選びます。一般的には参照方向や主要業務の流れを補足するために用いられます。
A: 本問題では【問題文】に直接 “→” が印字されているため、その向きをそのまま図示する慣例の記号を選びます。一般的には参照方向や主要業務の流れを補足するために用いられます。
関連キーワード: E-R図, カーディナリティ, 1対多, 1対1
設問2：表1と表2について、（1）〜（3）に答えよ。
（1）表1中のc、dに入れる適切なテーブル名を答えよ。
模範解答
c：処方箋明細
d：薬剤在庫
解説
解答の論理構成
-
“チェック結果による見直し”で医師が操作するテーブル
- 【問題文】には「見直しの結果、処方箋明細が 0 件になることもあるが、このような場合には、処方箋の発行は行わない運用とし、処方箋レコードは削除しない。」とあります。
- 表1の該当行は“チェック結果による見直し”で、作成列と更新列の両方が c になっています。見直しで新たな薬剤を追加したり既存明細を修正・削除したりする対象は“処方箋の各行”＝処方箋明細です。
- よって c には “処方箋明細” が入ります。
-
“薬剤の入庫”で院内薬局が更新するテーブル
- 表1の“薬剤の入庫”行において、更新列が d です。入庫（仕入れ）時に増減するのは在庫数量のみで、マスタや明細には影響しません。
- 表2には 薬剤在庫.在庫量＿大人1日 の更新時処理として「値を加える。(11)」と記載されています。番号(11)は表1の“薬剤の入庫”に対応するため、更新対象は 薬剤在庫 であることが確定します。
- よって d には “薬剤在庫” が入ります。
以上により
c：処方箋明細
d：薬剤在庫
c：処方箋明細
d：薬剤在庫
誤りやすいポイント
- “処方箋” と “処方箋明細” を混同しがち
- 見直しで編集するのは行レベルの明細。発行医師コード・有効年月日などヘッダ側は触れない。
- “薬剤” テーブルを更新対象と誤認
- 入庫は数量の増減のみで、薬剤マスタの属性（薬剤名や 1 日分量）は変わらない。
- 表2の番号対応を見落とす
- 「値を加える。(11)」→表1の(11)を確認すると“薬剤の入庫”。番号照合は確実に行う。
FAQ
Q: “チェック結果による見直し”で 処方箋 テーブルを削除しない理由は？
A: 【問題文】に「処方箋レコードは削除しない」とあるとおり、診療履歴の整合性を保つためです。明細 0 件でもヘッダ情報は残して監査証跡を保持します。
A: 【問題文】に「処方箋レコードは削除しない」とあるとおり、診療履歴の整合性を保つためです。明細 0 件でもヘッダ情報は残して監査証跡を保持します。
Q: 入庫時に新規行を作成せず更新だけで良いのか？
A: 薬剤在庫 は薬剤コードごとに 1 行（1 対 1 関係）で管理されるため、数量を「加える」更新操作で対応します。新しい薬剤を初導入する場合は別途“薬剤の発注”で行を作成します。
A: 薬剤在庫 は薬剤コードごとに 1 行（1 対 1 関係）で管理されるため、数量を「加える」更新操作で対応します。新しい薬剤を初導入する場合は別途“薬剤の発注”で行を作成します。
Q: 見直しで明細を削除した場合、在庫チェックは再実行する？
A: はい。処方量が変わるため、在庫チェック処理を再実行して在庫保証を確認します。
A: はい。処方量が変わるため、在庫チェック処理を再実行して在庫保証を確認します。
関連キーワード: ER図, 更新処理, 在庫管理, テーブル設計, 正規化
設問2：表1と表2について、（1）〜（3）に答えよ。
（2）表2中のeに入れる適切な処理内容を、対応する表1中の括弧付き数字を含めて答えよ。
模範解答
e：値を更新する。(3)
解説
解答の論理構成
-
更新対象を特定
表2では列「受診者」「住所」の更新時処理として e が問われています。
更新が起きる業務は、表1の「更新」欄に該当テーブルが記載されている行を探せば分かります。 -
表1の該当業務を確認
表1の“更新”列でテーブル「受診者」を扱う業務は
“受付―受診者情報変更時の修正” のみです。ここには括弧付き数字 “(3)” が付いています。 -
更新内容を導出
受診者情報を変更するので、列「住所」は “値を更新する” ことになります。
したがって e に入るのは
“値を更新する。(3)” です。 -
解答
e：値を更新する。(3)
誤りやすいポイント
- “外来受診の受付” で受診者情報も一緒に更新すると誤解しやすい
→ 表1ではこの業務は “作成” のみで“更新”は行っていない。 - 括弧付き数字を回答に含め忘れる
→ 求められているのは処理内容＋対応番号のセット。 - “受診者” テーブルが複数業務で更新されると想定してしまう
→ 表1を丁寧に確認し、更新欄に“受診者”があるのは(3)だけ。
FAQ
Q: 住所が初めて登録されるタイミングはいつですか？
A: 表2の“作成時”に “住所を設定する。(1)” とあり、これは表1の“外来受診の受付”(1)で作成されます。
A: 表2の“作成時”に “住所を設定する。(1)” とあり、これは表1の“外来受診の受付”(1)で作成されます。
Q: “住所” を誤って入力した場合の修正はどの業務が行いますか？
A: “受付―受診者情報変更時の修正”(3) で行い、処理内容は “値を更新する。(3)” です。
A: “受付―受診者情報変更時の修正”(3) で行い、処理内容は “値を更新する。(3)” です。
Q: 受診者本人が来院せず電話で住所変更を依頼した場合でも同じ処理ですか？
A: はい。業務名称は“受診者情報変更時の修正”(3)であり、窓口か電話かは問いません。
A: はい。業務名称は“受診者情報変更時の修正”(3)であり、窓口か電話かは問いません。
関連キーワード: CRUD, 更新処理, テーブル設計, 業務フロー, データ整合性
設問2：表1と表2について、（1）〜（3）に答えよ。
（3）表2中のfに入れる適切な列名を答えよ。
模範解答
f：処方箋ID
解説
解答の論理構成
- 外来受診レコードの作成時
【表1】の「外来受診の受付」で作成対象に「外来受診」が挙がっています。したがって受付時点で外来受診レコードが生成されます。 - 作成直後の列値
【表2】で外来受診の列［ f ］は「NULL を設定する.(1)(2)」と定義されています。すなわち受付時点では値が決まっていません。 - 医師が処方箋を作成したタイミング
【表1】の「処方箋の作成」で更新対象に「外来受診」が指定されています。医師が処方箋を発行するときに外来受診レコードを更新する唯一の列は「処方箋ID」であると読み取れます。 - 更新内容との整合
【表2】では［ f ］について「値を更新する.(4)」となっており、受付後に医師が設定する列と一致します。 - 外来受診表の定義
【図01】に示された外来受診の属性は
受診者ID, 受診予定日時, 診療科コード, 処方箋ID
の四つです。このうち受付で未確定で後に医師が入力する列は「処方箋ID」のみです。 - 以上より［ f ］に入る列名は「処方箋ID」と決定できます。
誤りやすいポイント
- 「受診予定日時」が更新されると勘違いする
受付後に診療日時が変更されるケースを想定しがちですが、【表2】にその更新は記載されていません。 - 「診療科コード」は受付で確定する
医師の判断で変わり得ると考えがちですが、受付時点で診療科は決め打ちされているため更新対象ではありません。 - 外部キー列は常に非 NULL と思い込む
処方箋ID は外部キーであっても受付時点では NULL 許容と設計されている点に注意が必要です。
FAQ
Q: 外来受診を削除する操作はどの担当が行いますか?
A: 【表1】に削除操作は示されていません。運用上、受診キャンセルは論理削除やフラグ管理で対応する想定です。
A: 【表1】に削除操作は示されていません。運用上、受診キャンセルは論理削除やフラグ管理で対応する想定です。
Q: 処方箋ID を NULL に設定できるのは外部キー制約違反になりませんか?
A: 多くの RDB では外部キー列に NULL が入る場合は参照整合性チェックがスキップされるため、問題なく登録できます。
A: 多くの RDB では外部キー列に NULL が入る場合は参照整合性チェックがスキップされるため、問題なく登録できます。
Q: 処方箋が作成されなかった場合、外来受診の処方箋ID はどうなりますか?
A: 見直しの結果「処方箋明細が 0 件」の場合、医師は処方箋レコードを削除しない運用ですが、外来受診の処方箋ID は更新されず NULL のまま残ります。
A: 見直しの結果「処方箋明細が 0 件」の場合、医師は処方箋レコードを削除しない運用ですが、外来受診の処方箋ID は更新されず NULL のまま残ります。
関連キーワード: 外部キー, NULL, 更新処理, レコード, リレーション
設問3：
図2中のg、hに入れる適切な字句を答えよ。
模範解答
g：UNION 又は UNIONALL
h：EXISTS
解説
解答の論理構成
-
目的の整理
【問題文】では「“併用禁忌”と“併用注意”となる薬剤の組合せ一覧を出力する SQL」を作成し、
– 過去「6か月以内にW病院で発行した処方箋」に記載された薬剤
– 今回作成中の「:処方箋 ID」に記載された薬剤
の双方をチェック対象に含めると記載されています。 -
WITH 句内のgの検討
- 1つ目の SELECT B1.薬剤コード … では“過去6か月”の薬剤コードを取得。
- 2つ目の SELECT C1.薬剤コード … では“今回の処方箋”の薬剤コードを取得。
- 両者を「1つの集合」として扱う必要があります。
- 集合を結合するSQLキーワードは UNION（重複排除）か UNION ALL（重複許容）。
どちらでも「チェック対象薬剤」の要件を満たすため、gには
UNION 又は UNION ALL が入ります。
-
外側SELECTの WHERE 句中のhの検討
- SELECT * FROM 薬剤併用情報 T1 WHERE h (サブクエリ)
- 条件は「T1 の薬剤コード1・薬剤コード2 が、チェック対象薬剤同士の組合せのいずれかに一致する場合」に絞り込みたい。
- サブクエリは SELECT T2.薬剤コード1, T2.薬剤コード2 … と2列を返す相関サブクエリ。
- EXISTS (サブクエリ) を使うと、サブクエリが1行でも返せば真になり、複数列でも問題なく判定できます。
- よって h には EXISTS が入ります。
-
結論
g：UNION 又は UNION ALL
h：EXISTS
誤りやすいポイント
- JOIN と誤解して g に JOIN を入れてしまう。JOIN は横方向の結合であり、集合を縦に連結する要件を満たしません。
- h に IN と書くミス。IN では列数が一致しないためエラーになります（サブクエリが2列を返すため）。
- UNION と UNION ALL の違いを忘れ、重複除去の有無でパフォーマンスが変わる点を見落とす。
- サブクエリで GROUP BY などを使い “存在判定” ではなく “結果取得” を意識してしまい複雑化させる。
FAQ
Q: UNION と UNION ALL のどちらを選ぶべきですか？
A: 業務要件に「重複行を除外する／しない」の規定がなければどちらでも機能面は同じです。重複行が少なくても構わない、速度を優先したい場合は UNION ALL を選ぶ設計が一般的です。
A: 業務要件に「重複行を除外する／しない」の規定がなければどちらでも機能面は同じです。重複行が少なくても構わない、速度を優先したい場合は UNION ALL を選ぶ設計が一般的です。
Q: EXISTS と IN の判定は同じですか？
A: 単一列なら似た動きをしますが、今回のように「2列を返すサブクエリ」では IN は使えません。複数列の一致判定を簡潔に書けるのは EXISTS です。
A: 単一列なら似た動きをしますが、今回のように「2列を返すサブクエリ」では IN は使えません。複数列の一致判定を簡潔に書けるのは EXISTS です。
Q: もしチェック対象薬剤が数千行になる場合、パフォーマンスは大丈夫ですか？
A: EXISTS はサブクエリを行ごとに評価しますが、外部の 薬剤併用情報 が適切に索引（薬剤コード1, 薬剤コード2）されていれば実行計画で効率的に結合されます。大規模データではインデックス設計が重要です。
A: EXISTS はサブクエリを行ごとに評価しますが、外部の 薬剤併用情報 が適切に索引（薬剤コード1, 薬剤コード2）されていれば実行計画で効率的に結合されます。大規模データではインデックス設計が重要です。
関連キーワード: UNION, EXISTS, 相関サブクエリ, 集合演算, パフォーマンス最適化
設問4：
図3中のi〜kに入れる適切な字句を答えよ。
模範解答
i：SUM(T3.処方量_大人1日)
j：>= CURRENT_DATE
k：IS NULL
解説
解答の論理構成
-
目的の再確認
【問題文】には、在庫チェックの要件として
“発行した処方箋に記載の薬剤が、院内薬局で有効年月日まで確保されるよう、在庫の保証を行う.”
とあります。さらに、処方箋発行後「有効年月日までに院内薬局で処方する可能性のある薬剤の処方量の合計」を確保量として管理するビューを作成すると明示されています。
➜ ビューは「まだ有効期限内」かつ「まだ受け渡していない」処方箋明細を対象にし、薬剤ごとに処方量を合計すればよいと分かります。 -
i の導出
ビュー本体 T3 には T2.薬剤コード, T2.処方量＿大人1日 が選ばれています。
複数行を薬剤コードで GROUP BY しているので集計関数が必要です。
合計したい列は “処方量＿大人1日”。
➜ SUM(T3.処方量＿大人1日) が最適です。 -
j の導出
在庫を確保すべき対象は「今日（ビュー参照時）以降も有効な処方箋」です。
したがって 有効年月日 >= CURRENT_DATE が成立するレコードのみを抽出します。 -
k の導出
既に薬が受け渡されている処方箋は在庫を確保する必要がありません。
受け渡しを示す列は “薬剤処方年月日”。未受渡しの場合は作成時に NULL が設定されることが表2の
薬剤処方年月日 … 値を更新する。(8)
から分かります。
➜ 「未受渡し」を表す条件は IS NULL です。 -
以上より
i：SUM(T3.処方量＿大人1日)
j：>= CURRENT_DATE
k：IS NULL
誤りやすいポイント
- 平均や最大値と勘違いして AVG や MAX を選んでしまう。要件は「合計」であるため SUM です。
- 「有効期限が過ぎた処方箋も在庫として確保しておく」と早合点し、<= CURRENT_DATE と逆条件を書いてしまう。
- IS NULL を = NULL と書く構文ミス。SQL では NULL 比較に = は使えません。
FAQ
Q: 処方箋明細が 0 件になった場合でもビューには影響がありますか？
A: ありません。処方箋明細がなければサブクエリに行が生成されず、ビューにも反映されません。
A: ありません。処方箋明細がなければサブクエリに行が生成されず、ビューにも反映されません。
Q: CURRENT_DATE と SYSDATE のどちらを使っても良いですか？
A: 本問題では CURRENT_DATE が図3に明示されているため、同一関数を用いるのが前提です。
A: 本問題では CURRENT_DATE が図3に明示されているため、同一関数を用いるのが前提です。
Q: 薬剤処方年月日 IS NULL 条件を忘れるとどうなりますか？
A: 既に受け渡した分も合計に含まれ、実際より多くの在庫を確保したと誤判定します。
A: 既に受け渡した分も合計に含まれ、実際より多くの在庫を確保したと誤判定します。
関連キーワード: GROUP BY, 集計関数, NULL判定, ビュー定義, 有効期限
