【iOS 27】処方箋を撮って送る患者に、受付の項目まで埋めてもらう（薬局・ドラッグストアのアプリ設計）

こんにちは。リテールアプリ共創部で事業企画を担当しているかめだです。

病院や診療所を出たあと処方箋をスマホで撮って薬局に送っておくと、薬局に着く頃には薬の準備が進んでいます。この手続きは、すでに多くの薬局アプリにあります。

今回は、送信前に、患者のiPhone内のAIで処方箋を読み取る設計を考えます。撮って送るところまではもうできているので、送信前の手順と、受け取った薬局側の作業がどう変わるかを書きます。

処方箋を撮って送るアプリで、いま何が起きているか

調剤薬局やドラッグストアのアプリには、処方箋をカメラで撮って薬局に送る機能がすでにあります。患者は必要事項を記入して処方箋を撮影し、薬局は受付から監査までを先に進め、薬ができたら通知します。原本は有効期限（交付日を含めて原則4日）内に持参が必要で、電子処方箋の場合は処方内容（控え）を撮影します。

「薬局を決める、処方せんを撮影して送信、準備完了の連絡、受け取り」という手順を案内しているアプリもあります。ドラッグストアがLINEミニアプリで処方箋送信を提供している例も出てきました。クラスメソッドでも、処方箋をスマホで撮って送るLINEミニアプリの開発を支援した事例があります。

この仕組みの中で、受付の担当者は届いた画像を開き、医療機関名・交付日・患者名を受付の台帳に打ち込み、薬剤名を読んで在庫を確認しています（連絡先や受取希望は、患者がアプリで入力した内容がそのまま届きます）。写真が暗かったりぶれていたりすると、患者に撮り直しを頼むことになります。有効期限が切れた処方箋がそのまま届いてしまうこともあると聞きます。撮って送るところまでは患者の作業で終わっていて、送信後の入力は引き続き薬局側が担当しています。

患者にとっては送って終わりの操作でも、薬局にとってはそこから受付・確認・準備の作業が始まります。

クラウドのAIで読む案が、なぜ薬局アプリで広がらなかったのか？

クラウドのAIでも読み取りはできます。結果を患者の画面に返して確認してもらう画面も作れます。それでも薬局のアプリで広がらないのは、画像の渡し先が増えるからです。

処方箋の画像は医療情報です。患者は「薬局に送る」つもりで撮っています。その画像を外部のAIサービスにも渡す設計にすると、薬局に送る同意とは別に、外部に渡すことの説明と社内の審査が要ります。企画の段階では、この審査で止まりやすいと考えています。

費用も理由になります。処方箋送信は毎日多くの患者が使う機能なので、回数に比例する課金は、無料で配っているアプリでは負担しにくくなります。端末の中で読めば、この呼び出しごとの費用はかかりません。

患者が送る前に内容を確認して直せること自体は、クラウドで読んでも端末内で読んでも、画面の設計次第で実現できます。この記事では、処方箋の画像を渡す先を増やさずに済む端末内での読み取りを前提に、その確認画面を設計します。

電波が弱いという理由は、この業務には当てはまりません。処方箋を撮る場所は自宅や薬局の前が中心で、通信環境そのものが薬局アプリの障害になっている話は聞かないためです。端末内で読む設計を選ぶ理由は、処方箋の画像を薬局以外の送り先に増やさないことです。逆に、対応端末を持つ患者が少ない、試作で確かめた読み取り精度が受付の手間を減らす水準に届かない、確認画面を挟むことで患者の離脱が増える、のどれかに当たるなら、端末内は選ばず、いまの送信の手順を続けます。

患者のiPhoneの中で処方箋を読むと、何が変わるのか？

iOS 27で加わったのは、写真をそのまま渡す仕組み（Attachment で画像をプロンプトに添付する（Foundation Models の画像入力））と、文字を読み取る標準のOCRツール（AI にツールを持たせる（OCRTool・バーコード・端末内検索））です。この2つを組み合わせると、処方箋の画像から患者名・医療機関名・交付日・薬剤名の候補を受付の項目に振り分け、下書きにするところまで、患者の端末の中だけで終えられます。受取希望や連絡先は書類には書いてないので、これまでどおり患者が入力します。

読み取れなかった項目は、無理に埋めずに空欄のままにしておきます。処方箋1枚と項目の定義を渡す想定です。画像の大きさで処理の時間が変わるので、想定する画像で実測します。

薬剤名の読み取りは候補を出すところまでで、調剤の判断には使いません。対応端末を持たない患者は、これまでどおり写真を送り、項目は自分の手で打つ手順のままです。対応端末の患者には確認画面を挟み、非対応の患者には今の手順を残します。この2通りを用意します。

患者の年齢層は幅が広く、使っている端末もまちまちです。対応端末を持つ患者にとっても、確認画面が複雑では使われません。読み取れた項目を並べて見せ、直すか送るかだけを選んでもらう画面にします。高齢の患者にとって、項目を一から自分で埋めるより、すでに埋まっている項目を見て直すほうが負担が軽いかは、試行で確かめる仮説です。

対応端末・費用などの共通の前提は、iPhoneの中でAIが動くと、どの業界の何が変わるのか（Apple Intelligence 業界別活用マップ） の「どの業務にも共通する前提」にまとめています。

確認画面で、患者に確認させる項目とさせない項目

送る前の確認画面を用意します。撮った処方箋の写真と、読み取った患者名・医療機関名・交付日、患者が入力する受取希望・連絡先を1画面に並べ、患者は写真と見比べて違っている項目があればその場で直して、「この内容で送る」を押します。薬剤名の候補は、この画面では患者に確認させません。未確認のまま送れる項目として扱い、薬局側で薬剤師が原本と照合します。患者が判断できる受付情報だけ埋めてもらい、判断できない項目は空欄のまま送れるようにしておきます。AIが出した候補は下書きで、受付情報を確定するのは患者本人です。

写真の四隅が入っていない、あるいはぶれていると判断できる場合は、送る前に「四隅が入っていない」「ぶれている」と表示し、撮り直しを促します。薬局に届いてから撮り直しを依頼するより、この段階で気づいたほうが患者にとっても早く済みます。撮り直しの依頼は薬局側の受付業務も中断させるので、送信前に減らします。

有効期限の注意も、この確認画面に含めます。処方箋には使用期間の欄があります。交付日と使用期間の欄をそれぞれ読み取り、どちらかが読み取れなければ期限は表示しません。期限が過ぎているかどうかの判定は、読み取った日付をもとにアプリ側の日付計算で行い、AIには任せません。日付の計算は決まった規則で答えが一つに決まる処理で、AIに任せる理由がないからです。

薬局側の受付画面では、患者から届いた画像と項目を並べて表示します。薬剤名が未確認のまま届いた段階でも、在庫の有無や取り寄せが要るかの確認は始められます。一方、調剤の準備、薬袋の印字、監査は、原本と照合した後に限ります。調剤の誤りは患者の安全に関わるため、この順番は変えません。薬剤師や受付担当者が原本と照合し、内容を確定するのはこれまでどおりです。受付担当者から見ると、画像だけが届いていた今までと比べて、確認に使える情報が増えます。

処理を患者の端末の中で完結させることも決めておきます。処方箋の画像は医療情報であり、Appleのサーバー側にある大きいモデルに渡す設計にはしません。処方箋から受付項目を読み取るという仕事は、端末内で処理を完結できる作業だと考えています。渡す情報も、その処方箋1枚と項目の定義だけに絞り、患者の他の処方履歴や購入履歴までは渡さない設計にしておきます。

電子処方箋の場合は、処方内容の控えを撮影して送る手順がすでにあります。この控えの撮影も、同じ確認画面で扱えば、紙の処方箋と電子処方箋とで別々の画面を用意せずに済みます。控えの様式は紙の処方箋と違う部分もあるため、読み取る項目の定義は共通にしつつ、様式ごとの読み取り精度は別々に確かめておく必要があります。

1薬局、対応端末の患者だけで始める

最初から全患者を対象にする必要はありません。対応端末（iPhone 15 Pro/Pro Max か iPhone 16 以降）を持ち、Apple Intelligence をオンにしている患者の送信から始めます。アプリは端末を見て、対応端末で Apple Intelligence が使える状態なら確認画面を、そうでなければいまの送信画面を出します。

試作は、自社の開発部門か開発会社に、撮る、下書きにする、患者が確認して送る、という最小の画面だけを頼みます。

数えるものは、送信数を分母にして、受付の打ち直し率・再送依頼率・患者の修正率を数えます。あわせて受付の所要時間も測ります。期間を決めて、導入前後を比べます。

この表は試す前に埋めておきます。結果を見てから基準を決めると、結果に合わせた基準になります。

必要なのは、すでにある処方箋送信アプリ、読ませる項目の定義、お手本になる処方箋数十枚（匿名化したもの）、そして薬局側の受付画面の改修です。

最初の対象は1薬局に絞ります。受付項目の打ち直しがどれだけ減ったかを、まず1か所で確かめてから対象を広げます。処方箋の書式は医療機関ごとに違うため、その薬局によく来る医療機関の書式を中心にお手本をそろえておくと、確認しやすくなります。

よくある質問

読み取った薬剤名で、調剤の準備を始めてよいですか。

始めてよいのは在庫の確認や準備の前倒しまでで、調剤そのものは原本を見た薬剤師が確定します。読み取った薬剤名を調剤の指示として扱う設計にはしません。

電子処方箋が広がれば、この仕組みは要らなくなりますか。

電子処方箋には引換番号で受け取る導線が別にあります。紙の処方箋が残っている間は、撮って送る手順自体がなくならないため、この設計も引き続き必要だと考えています。控えの撮影を同じ確認画面で扱えば、紙と電子のどちらの患者も同じ画面で済みます。

対応していないiPhoneやAndroidの患者は、どうなりますか。

これまでと同じ手順になります。アプリ側で端末を見て、対応端末なら確認画面、非対応ならいまの手順に分けるだけです。患者からすると、対応端末かどうかで操作の手間が変わるだけで、送り先やその後の受付の扱いは変わりません。

処方箋の画像は、どこに送られますか。

送られる先は薬局です。項目を読み取る処理は患者のiPhoneの中で終わり、Appleのサーバー側には送らない設計にします。薬局に届くのは、これまでどおりの画像と、患者が確認した項目です。

参考

• アイン薬局グループ「処方せんを送る」 https://www.ainj.co.jp/column/send_rx/
• お薬の窓口 アプリ紹介ページ https://www.kusurinomadoguchi.com/lp/app/01
• ダイヤモンド・リテイルメディア「ドラッグストアがLINEミニアプリで処方箋送信を提供」 https://diamond-rm.net/flash_news/118223/
• クラスメソッド公開事例「LINEミニアプリから『どこでも処方せん送信』」 https://classmethod.jp/cases/tomods/
• 厚生労働省「処方箋の使用期間について」 https://www.mhlw.go.jp/stf/newpage_32041.html

では、おつかめ！

--

クラスメソッドでは、既存スマホアプリをFlutterでiOS/Android同時に作り直し、バックエンドはAWSで再構築する「AI駆動アプリリニューアル」を提供しています。現行アプリの仕様読み解きから設計・実装まで生成AIを組み込んだ開発プロセスで進めるため、レガシー化したアプリのリニューアルを短い期間で作り直します。
サービス詳細・お問い合わせはこちら