みなさん、こんにちは。開発本部の平木です。 2017 年から、RubyKaigi にスポンサーとして参加していましたが、今年も 朝食スポンサー として協賛することになりました! (去年とおととしの参加レポート) RubyKaigi 2017 にメドレーが Ruby Sponsor として参加しました Lightning Talks Sponsor として RubyKaigi 2018 に参加してきました 会場である、福岡国際会議場内の 1F にあるレストラン ラコンテ さんでビュッフェ形式の朝食を楽しむことができます。 会期中の 4/19~20 日の 8:30 ~ 10:00 で開催しています。当日はメドレーメンバーがご案内する予定になっていますので、ぜひお気軽に話かけてください!目印として、メンバーはメドレーパーカーを着用しています。 メニューは和洋それぞれ用意があり、福岡ならではのメニューも入っていますので、1 日の始まりにぜひおいしい朝食を食べて元気にセッションに臨んでください。 また、スポンサーブース内にもメドレーブースが常設されており、エンジニア 4 人も行く予定となっていますので、ぜひお立ち寄りいただいて、みなさんと交流できればと思います。 それでは、RubyKaigi という大きなイベントでまた皆様にお会いできるのを楽しみにしています!!

こんにちは。CLINICS 事業部の児玉です。 今回は、メドレーが 2018 年 12 月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の FHIR を基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。 FHIR とは FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格である HL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「 次世代の医療情報標準規格 」として世界各国で注目されています。 HL7 は、世界に 30 以上の国際支部を有しており、日本では 1998 年に 日本 HL7 協会 が設立されました。そして、現在流通している HL7 規格には、データ交換に利用される HL7v2 と、医用文書の記述に利用される CDA (Clinical Document Architecture)が存在します。 電子処方箋とは 電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関と調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。 実証事業の背景と概略 2016 年 3 月の法令改正で、処方箋の電子的な交付が可能となり、 運用ガイドライン も策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。 ガイドラインに定められた運用フロー（電子処方せんの運用ガイドラインより転載） 元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替として CDA で記述された静的ファイル を必要とし、記名押印の代替として HPKI を使用した 電子署名 が必要となります。 また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために 電子タイムスタンプ を付与する必要があります。 このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の 1 つであると考えられます。 こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。 実証事業概略 実施目的：電子処方箋の運用の仕組みの検討・実証・考察 実施期間：2019 年 2 月 4 日 - 2019 年 3 月 17 日 実証エリア：東京都港区 協力施設：2 医療機関 / 6 薬局 利用実績：64 件 電子処方箋管理システムの概要 以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHR アプリ」の 4 つのシステムから構成されています。 システム概観 処方箋管理システム 医療機関システム、薬局システム及び PHR アプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。 医療機関システム 診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードは QR コードの活用を想定し、QR コードを印字した紙又は電子データを患者に共有する。 ＊「QR コード」は株式会社デンソーウェーブの登録商標です。 薬局システム 訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。 PHR アプリ 患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。 医療機関システムは、メドレーのクラウド電子カルテ「CLINICS カルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。 処方箋管理システムは、前述の通り FHIR インターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。 HPKI を利用した SSO(Single Sign On)による本人資格確認 と、FHIR インターフェイスを利用した クラウドベースでのデータフロー を実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。 データ設計 FHIR には「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。 FHIR を利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。 例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。 実証事業で使用したリソース リソース 説明 Patient 患者 Practitioner 施術者（処方医／薬剤師） PractitionerRole 施術者役割 Organization 組織（医療機関／調剤薬局） MedicationRequest 投薬要求 MedicationDispense 調剤実施 Coverage 保険 FHIR を使用した所感 FHIR の改版は on-Going で行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急に FHIR のホームページが接続不安定になり困っていたところ、翌日には R4(Release 4)に更新されていたということもありました。 このように、日進月歩の FHIR をプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。 2018 年 12 月 27 日に R4 が Current Version になりました FHIR の利点は、従来の HL7 規格と比較した 実装容易性 にあると考えます。REST(REpresentational State Transfer)のように、Web サービスでは一般的に普及している概念を標準として取り込んでいるため、**実装者は特別な知識を習得する必要がありません。**また、FHIR を実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。 臨床概念モデルとしての観点では、CDA のベースとなっている HL7v3-RIM (Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指した RIM と比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。 また、1:1 のシステム連携におけるデータ交換では、すでに稼働している v2 インターフェイスを、無理して FHIR に置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。 実運用へ向けての課題 FHIR リソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックにマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、 指標となるガイドラインの策定 が必要になります。 また、リソースにマッピングする医薬品や用法のマスターコードについては、 厚生労働省標準マスター の利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、 標準マスター利用の推奨 も併せてガイドラインに明記することが必要です。 ガイドラインは、メドレー 1 社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者に FHIR を利用していただき、 実装方法についての議論 を交わす必要があります。しかし、現時点での日本国内における FHIR の活用事例は、残念ながらほとんど見られません。 次にご紹介するのは、FHIR を使用した簡単なコードのサンプルと、ローカル環境で FHIR Server を簡易的に動かす方法です。実装者の方が FHIR に触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。 FHIR の実装サンプル FHIR を理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境で FHIR Server を起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。） 実行環境 macOS v10.14.3 Ruby v2.5.1 Docker v18.09.2 FHIR Server Docker コンテナで FHIR Server を起動します。簡単に動かせるように、DockerHub に公開されている HAPI-FHIR のコンテナイメージを利用します。 HAPI-FHIR とは、カナダのトロントにある医療研究機関の UHN(University Health Network)が立ち上げたプロジェクトで、FHIR のオープンソースライブラリを提供することを目的に活動しています。 GitHub - jamesagnew/hapi-fhir: 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers - jamesagnew/hapi-fhir github.com hub.docker.com hub.docker.com Docker コンテナイメージの取得 $ docker pull petersonjared/hapi-fhir $ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3 $ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar Docker をインストールするのが面倒な人は、HAPI-FHIR がグローバルに公開している テストサーバー を利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。 FHIR Client FHIR Client は、Ruby で動かします。以下の Gem を利用します。 $ gem install fhir_client $ gem install fhir_models Ruby のコードです。Patient リソースを作成して FHIR Server に登録します。 patient.rb require 'fhir_client' client = FHIR::Client . new ( "https://localhost:8080/baseDstu3" ) FHIR::Model . client = client patient = FHIR::Patient . new # 患者 ID identifier = FHIR::Identifier . new identifier. value = '12345678' patient. identifier = identifier # 患者氏名 human_name = FHIR::HumanName . new human_name. family = 'Kodama' human_name. given = 'Yoshinori' patient. name . push (human_name) # 性別 patient. gender = 'male' patient. create puts patient. id 上記のコードを実行すると、FHIR Server に Patient リソースが登録されます。ここでリソースを一意に特定するリソース ID が採番されます。今回は 19953 が採番されました。（puts patient.id で確認） このリソース ID を利用して、FHIR Server に HTTP リクエストを送ります。 $ curl https://localhost:8080/baseDstu3/Patient/19953 そうすると、先ほど登録したリソースが JSON 形式で取得できます。 { "resourceType" : "Patient" , "id" : "19953" , "meta" : { "versionId" : "1" , "lastUpdated" : "2019-03-21T09:12:44.660+00:00" }, "text" : { "status" : "generated" , "div" : "<div xmlns= \" https://www.w3.org/1999/xhtml \" ><div class= \" hapiHeaderText \" >Yoshinori <b>KODAMA </b></div><table class= \" hapiPropertyTable \" ><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>" }, "identifier" : [ { "value" : "12345678" } ], "name" : [ { "family" : "Kodama" , "given" : [ "Yoshinori" ] } ], "gender" : "male" } もちろん、患者 ID など利用して検索することも可能です。 $ curl https://localhost:8080/baseDstu3/Patient?identifier= 12345678 さいごに 今回の実証事業では、FHIR のインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は 厚生労働省のサイト に公開されていますので、詳細について興味のある方はこちらをご参照ください。 電子処方箋 www.mhlw.go.jp メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。 お知らせ 今回の電子処方箋実証事業の成果と、システム開発に活用した FHIR について共有するイベントを、以下のとおり 4 月 23 日(火)に開催します。お時間ある方はぜひご参加ください。 FHIR Meetup Tokyo #01 @ TECH PLAY SHIBUYA｜IT勉強会・イベントならTECH PLAY［テックプレイ］ 2019/04/23（火）開催 今後の医療ITシステムの核となるであろう技術として「FHIR」にフォーカスし、FHIRの概要、FHIRを活用したテクノロジー製品や事例の紹介、電子処方箋実証事業におけるFHIR活用の事例など、開発者がFHIRを具体的に活用していくためのノウハウを共有していきます。 techplay.jp また、メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。CLINICS 事業部の児玉です。 今回は、メドレーが 2018 年 12 月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の FHIR を基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。 FHIR とは FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格である HL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「 次世代の医療情報標準規格 」として世界各国で注目されています。 HL7 は、世界に 30 以上の国際支部を有しており、日本では 1998 年に 日本 HL7 協会 が設立されました。そして、現在流通している HL7 規格には、データ交換に利用される HL7v2 と、医用文書の記述に利用される CDA (Clinical Document Architecture)が存在します。 電子処方箋とは 電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関と調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。 実証事業の背景と概略 2016 年 3 月の法令改正で、処方箋の電子的な交付が可能となり、 運用ガイドライン も策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。 ガイドラインに定められた運用フロー（電子処方せんの運用ガイドラインより転載） 元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替として CDA で記述された静的ファイル を必要とし、記名押印の代替として HPKI を使用した 電子署名 が必要となります。 また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために 電子タイムスタンプ を付与する必要があります。 このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の 1 つであると考えられます。 こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。 実証事業概略 実施目的：電子処方箋の運用の仕組みの検討・実証・考察 実施期間：2019 年 2 月 4 日 - 2019 年 3 月 17 日 実証エリア：東京都港区 協力施設：2 医療機関 / 6 薬局 利用実績：64 件 電子処方箋管理システムの概要 以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHR アプリ」の 4 つのシステムから構成されています。 システム概観 処方箋管理システム 医療機関システム、薬局システム及び PHR アプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。 医療機関システム 診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードは QR コードの活用を想定し、QR コードを印字した紙又は電子データを患者に共有する。 ＊「QR コード」は株式会社デンソーウェーブの登録商標です。 薬局システム 訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。 PHR アプリ 患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。 医療機関システムは、メドレーのクラウド電子カルテ「CLINICS カルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。 処方箋管理システムは、前述の通り FHIR インターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。 HPKI を利用した SSO(Single Sign On)による本人資格確認 と、FHIR インターフェイスを利用した クラウドベースでのデータフロー を実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。 データ設計 FHIR には「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。 FHIR を利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。 例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。 実証事業で使用したリソース リソース 説明 Patient 患者 Practitioner 施術者（処方医／薬剤師） PractitionerRole 施術者役割 Organization 組織（医療機関／調剤薬局） MedicationRequest 投薬要求 MedicationDispense 調剤実施 Coverage 保険 FHIR を使用した所感 FHIR の改版は on-Going で行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急に FHIR のホームページが接続不安定になり困っていたところ、翌日には R4(Release 4)に更新されていたということもありました。 このように、日進月歩の FHIR をプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。 2018 年 12 月 27 日に R4 が Current Version になりました FHIR の利点は、従来の HL7 規格と比較した 実装容易性 にあると考えます。REST(REpresentational State Transfer)のように、Web サービスでは一般的に普及している概念を標準として取り込んでいるため、**実装者は特別な知識を習得する必要がありません。**また、FHIR を実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。 臨床概念モデルとしての観点では、CDA のベースとなっている HL7v3-RIM (Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指した RIM と比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。 また、1:1 のシステム連携におけるデータ交換では、すでに稼働している v2 インターフェイスを、無理して FHIR に置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。 実運用へ向けての課題 FHIR リソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックにマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、 指標となるガイドラインの策定 が必要になります。 また、リソースにマッピングする医薬品や用法のマスターコードについては、 厚生労働省標準マスター の利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、 標準マスター利用の推奨 も併せてガイドラインに明記することが必要です。 ガイドラインは、メドレー 1 社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者に FHIR を利用していただき、 実装方法についての議論 を交わす必要があります。しかし、現時点での日本国内における FHIR の活用事例は、残念ながらほとんど見られません。 次にご紹介するのは、FHIR を使用した簡単なコードのサンプルと、ローカル環境で FHIR Server を簡易的に動かす方法です。実装者の方が FHIR に触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。 FHIR の実装サンプル FHIR を理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境で FHIR Server を起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。） 実行環境 macOS v10.14.3 Ruby v2.5.1 Docker v18.09.2 FHIR Server Docker コンテナで FHIR Server を起動します。簡単に動かせるように、DockerHub に公開されている HAPI-FHIR のコンテナイメージを利用します。 HAPI-FHIR とは、カナダのトロントにある医療研究機関の UHN(University Health Network)が立ち上げたプロジェクトで、FHIR のオープンソースライブラリを提供することを目的に活動しています。 https://github.com/jamesagnew/hapi-fhir https://hub.docker.com/r/petersonjared/hapi-fhir Docker コンテナイメージの取得 $ docker pull petersonjared/hapi-fhir $ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3 $ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar Docker をインストールするのが面倒な人は、HAPI-FHIR がグローバルに公開している テストサーバー を利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。 FHIR Client FHIR Client は、Ruby で動かします。以下の Gem を利用します。 $ gem install fhir_client $ gem install fhir_models Ruby のコードです。Patient リソースを作成して FHIR Server に登録します。 patient.rb require 'fhir_client' client = FHIR::Client . new ( "https://localhost:8080/baseDstu3" ) FHIR::Model . client = client patient = FHIR::Patient . new # 患者 ID identifier = FHIR::Identifier . new identifier. value = '12345678' patient. identifier = identifier # 患者氏名 human_name = FHIR::HumanName . new human_name. family = 'Kodama' human_name. given = 'Yoshinori' patient. name . push (human_name) # 性別 patient. gender = 'male' patient. create puts patient. id 上記のコードを実行すると、FHIR Server に Patient リソースが登録されます。ここでリソースを一意に特定するリソース ID が採番されます。今回は 19953 が採番されました。（puts patient.id で確認） このリソース ID を利用して、FHIR Server に HTTP リクエストを送ります。 $ curl https://localhost:8080/baseDstu3/Patient/19953 そうすると、先ほど登録したリソースが JSON 形式で取得できます。 { "resourceType" : "Patient" , "id" : "19953" , "meta" : { "versionId" : "1" , "lastUpdated" : "2019-03-21T09:12:44.660+00:00" }, "text" : { "status" : "generated" , "div" : "<div xmlns= \" https://www.w3.org/1999/xhtml \" ><div class= \" hapiHeaderText \" >Yoshinori <b>KODAMA </b></div><table class= \" hapiPropertyTable \" ><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>" }, "identifier" : [ { "value" : "12345678" } ], "name" : [ { "family" : "Kodama" , "given" : [ "Yoshinori" ] } ], "gender" : "male" } もちろん、患者 ID など利用して検索することも可能です。 $ curl https://localhost:8080/baseDstu3/Patient?identifier= 12345678 さいごに 今回の実証事業では、FHIR のインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は 厚生労働省のサイト に公開されていますので、詳細について興味のある方はこちらをご参照ください。 https://www.mhlw.go.jp/stf/denshishohousen.html メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。 お知らせ 今回の電子処方箋実証事業の成果と、システム開発に活用した FHIR について共有するイベントを、以下のとおり 4 月 23 日(火)に開催します。お時間ある方はぜひご参加ください。 https://techplay.jp/event/725549 また、メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 https://www.medley.jp/recruit/creative.html

こんにちは。CLINICS 事業部の児玉です。 今回は、メドレーが 2018 年 12 月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の FHIR を基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。 FHIR とは FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格である HL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「 次世代の医療情報標準規格 」として世界各国で注目されています。 HL7 は、世界に 30 以上の国際支部を有しており、日本では 1998 年に 日本 HL7 協会 が設立されました。そして、現在流通している HL7 規格には、データ交換に利用される HL7v2 と、医用文書の記述に利用される CDA (Clinical Document Architecture)が存在します。 電子処方箋とは 電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関と調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。 実証事業の背景と概略 2016 年 3 月の法令改正で、処方箋の電子的な交付が可能となり、 運用ガイドライン も策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。 ガイドラインに定められた運用フロー（電子処方せんの運用ガイドラインより転載） 元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替として CDA で記述された静的ファイル を必要とし、記名押印の代替として HPKI を使用した 電子署名 が必要となります。 また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために 電子タイムスタンプ を付与する必要があります。 このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の 1 つであると考えられます。 こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。 実証事業概略 実施目的：電子処方箋の運用の仕組みの検討・実証・考察 実施期間：2019 年 2 月 4 日 - 2019 年 3 月 17 日 実証エリア：東京都港区 協力施設：2 医療機関 / 6 薬局 利用実績：64 件 電子処方箋管理システムの概要 以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHR アプリ」の 4 つのシステムから構成されています。 システム概観 処方箋管理システム 医療機関システム、薬局システム及び PHR アプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。 医療機関システム 診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードは QR コードの活用を想定し、QR コードを印字した紙又は電子データを患者に共有する。 ＊「QR コード」は株式会社デンソーウェーブの登録商標です。 薬局システム 訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。 PHR アプリ 患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。 医療機関システムは、メドレーのクラウド電子カルテ「CLINICS カルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。 処方箋管理システムは、前述の通り FHIR インターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。 HPKI を利用した SSO(Single Sign On)による本人資格確認 と、FHIR インターフェイスを利用した クラウドベースでのデータフロー を実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。 データ設計 FHIR には「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。 FHIR を利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。 例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。 実証事業で使用したリソース リソース 説明 Patient 患者 Practitioner 施術者（処方医／薬剤師） PractitionerRole 施術者役割 Organization 組織（医療機関／調剤薬局） MedicationRequest 投薬要求 MedicationDispense 調剤実施 Coverage 保険 FHIR を使用した所感 FHIR の改版は on-Going で行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急に FHIR のホームページが接続不安定になり困っていたところ、翌日には R4(Release 4)に更新されていたということもありました。 このように、日進月歩の FHIR をプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。 2018 年 12 月 27 日に R4 が Current Version になりました FHIR の利点は、従来の HL7 規格と比較した 実装容易性 にあると考えます。REST(REpresentational State Transfer)のように、Web サービスでは一般的に普及している概念を標準として取り込んでいるため、**実装者は特別な知識を習得する必要がありません。**また、FHIR を実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。 臨床概念モデルとしての観点では、CDA のベースとなっている HL7v3-RIM (Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指した RIM と比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。 また、1:1 のシステム連携におけるデータ交換では、すでに稼働している v2 インターフェイスを、無理して FHIR に置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。 実運用へ向けての課題 FHIR リソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックにマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、 指標となるガイドラインの策定 が必要になります。 また、リソースにマッピングする医薬品や用法のマスターコードについては、 厚生労働省標準マスター の利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、 標準マスター利用の推奨 も併せてガイドラインに明記することが必要です。 ガイドラインは、メドレー 1 社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者に FHIR を利用していただき、 実装方法についての議論 を交わす必要があります。しかし、現時点での日本国内における FHIR の活用事例は、残念ながらほとんど見られません。 次にご紹介するのは、FHIR を使用した簡単なコードのサンプルと、ローカル環境で FHIR Server を簡易的に動かす方法です。実装者の方が FHIR に触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。 FHIR の実装サンプル FHIR を理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境で FHIR Server を起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。） 実行環境 macOS v10.14.3 Ruby v2.5.1 Docker v18.09.2 FHIR Server Docker コンテナで FHIR Server を起動します。簡単に動かせるように、DockerHub に公開されている HAPI-FHIR のコンテナイメージを利用します。 HAPI-FHIR とは、カナダのトロントにある医療研究機関の UHN(University Health Network)が立ち上げたプロジェクトで、FHIR のオープンソースライブラリを提供することを目的に活動しています。 GitHub - jamesagnew/hapi-fhir: 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers - jamesagnew/hapi-fhir github.com hub.docker.com hub.docker.com Docker コンテナイメージの取得 $ docker pull petersonjared/hapi-fhir $ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3 $ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar Docker をインストールするのが面倒な人は、HAPI-FHIR がグローバルに公開している テストサーバー を利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。 FHIR Client FHIR Client は、Ruby で動かします。以下の Gem を利用します。 $ gem install fhir_client $ gem install fhir_models Ruby のコードです。Patient リソースを作成して FHIR Server に登録します。 patient.rb require 'fhir_client' client = FHIR::Client . new ( "https://localhost:8080/baseDstu3" ) FHIR::Model . client = client patient = FHIR::Patient . new # 患者 ID identifier = FHIR::Identifier . new identifier. value = '12345678' patient. identifier = identifier # 患者氏名 human_name = FHIR::HumanName . new human_name. family = 'Kodama' human_name. given = 'Yoshinori' patient. name . push (human_name) # 性別 patient. gender = 'male' patient. create puts patient. id 上記のコードを実行すると、FHIR Server に Patient リソースが登録されます。ここでリソースを一意に特定するリソース ID が採番されます。今回は 19953 が採番されました。（puts patient.id で確認） このリソース ID を利用して、FHIR Server に HTTP リクエストを送ります。 $ curl https://localhost:8080/baseDstu3/Patient/19953 そうすると、先ほど登録したリソースが JSON 形式で取得できます。 { "resourceType" : "Patient" , "id" : "19953" , "meta" : { "versionId" : "1" , "lastUpdated" : "2019-03-21T09:12:44.660+00:00" }, "text" : { "status" : "generated" , "div" : "<div xmlns= \" https://www.w3.org/1999/xhtml \" ><div class= \" hapiHeaderText \" >Yoshinori <b>KODAMA </b></div><table class= \" hapiPropertyTable \" ><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>" }, "identifier" : [ { "value" : "12345678" } ], "name" : [ { "family" : "Kodama" , "given" : [ "Yoshinori" ] } ], "gender" : "male" } もちろん、患者 ID など利用して検索することも可能です。 $ curl https://localhost:8080/baseDstu3/Patient?identifier= 12345678 さいごに 今回の実証事業では、FHIR のインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は 厚生労働省のサイト に公開されていますので、詳細について興味のある方はこちらをご参照ください。 電子処方箋 www.mhlw.go.jp メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。 お知らせ 今回の電子処方箋実証事業の成果と、システム開発に活用した FHIR について共有するイベントを、以下のとおり 4 月 23 日(火)に開催します。お時間ある方はぜひご参加ください。 FHIR Meetup Tokyo #01 @ TECH PLAY SHIBUYA｜IT勉強会・イベントならTECH PLAY［テックプレイ］ 2019/04/23（火）開催 今後の医療ITシステムの核となるであろう技術として「FHIR」にフォーカスし、FHIRの概要、FHIRを活用したテクノロジー製品や事例の紹介、電子処方箋実証事業におけるFHIR活用の事例など、開発者がFHIRを具体的に活用していくためのノウハウを共有していきます。 techplay.jp また、メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。CLINICS 事業部の児玉です。 今回は、メドレーが 2018 年 12 月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の FHIR を基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。 FHIR とは FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格である HL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「 次世代の医療情報標準規格 」として世界各国で注目されています。 HL7 は、世界に 30 以上の国際支部を有しており、日本では 1998 年に 日本 HL7 協会 が設立されました。そして、現在流通している HL7 規格には、データ交換に利用される HL7v2 と、医用文書の記述に利用される CDA (Clinical Document Architecture)が存在します。 電子処方箋とは 電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関と調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。 実証事業の背景と概略 2016 年 3 月の法令改正で、処方箋の電子的な交付が可能となり、 運用ガイドライン も策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。 ガイドラインに定められた運用フロー（電子処方せんの運用ガイドラインより転載） 元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替として CDA で記述された静的ファイル を必要とし、記名押印の代替として HPKI を使用した 電子署名 が必要となります。 また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために 電子タイムスタンプ を付与する必要があります。 このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の 1 つであると考えられます。 こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。 実証事業概略 実施目的：電子処方箋の運用の仕組みの検討・実証・考察 実施期間：2019 年 2 月 4 日 - 2019 年 3 月 17 日 実証エリア：東京都港区 協力施設：2 医療機関 / 6 薬局 利用実績：64 件 電子処方箋管理システムの概要 以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHR アプリ」の 4 つのシステムから構成されています。 システム概観 処方箋管理システム 医療機関システム、薬局システム及び PHR アプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。 医療機関システム 診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードは QR コードの活用を想定し、QR コードを印字した紙又は電子データを患者に共有する。 ＊「QR コード」は株式会社デンソーウェーブの登録商標です。 薬局システム 訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。 PHR アプリ 患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。 医療機関システムは、メドレーのクラウド電子カルテ「CLINICS カルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。 処方箋管理システムは、前述の通り FHIR インターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。 HPKI を利用した SSO(Single Sign On)による本人資格確認 と、FHIR インターフェイスを利用した クラウドベースでのデータフロー を実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。 データ設計 FHIR には「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。 FHIR を利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。 例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。 実証事業で使用したリソース リソース 説明 Patient 患者 Practitioner 施術者（処方医／薬剤師） PractitionerRole 施術者役割 Organization 組織（医療機関／調剤薬局） MedicationRequest 投薬要求 MedicationDispense 調剤実施 Coverage 保険 FHIR を使用した所感 FHIR の改版は on-Going で行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急に FHIR のホームページが接続不安定になり困っていたところ、翌日には R4(Release 4)に更新されていたということもありました。 このように、日進月歩の FHIR をプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。 2018 年 12 月 27 日に R4 が Current Version になりました FHIR の利点は、従来の HL7 規格と比較した 実装容易性 にあると考えます。REST(REpresentational State Transfer)のように、Web サービスでは一般的に普及している概念を標準として取り込んでいるため、**実装者は特別な知識を習得する必要がありません。**また、FHIR を実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。 臨床概念モデルとしての観点では、CDA のベースとなっている HL7v3-RIM (Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指した RIM と比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。 また、1:1 のシステム連携におけるデータ交換では、すでに稼働している v2 インターフェイスを、無理して FHIR に置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。 実運用へ向けての課題 FHIR リソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックにマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、 指標となるガイドラインの策定 が必要になります。 また、リソースにマッピングする医薬品や用法のマスターコードについては、 厚生労働省標準マスター の利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、 標準マスター利用の推奨 も併せてガイドラインに明記することが必要です。 ガイドラインは、メドレー 1 社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者に FHIR を利用していただき、 実装方法についての議論 を交わす必要があります。しかし、現時点での日本国内における FHIR の活用事例は、残念ながらほとんど見られません。 次にご紹介するのは、FHIR を使用した簡単なコードのサンプルと、ローカル環境で FHIR Server を簡易的に動かす方法です。実装者の方が FHIR に触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。 FHIR の実装サンプル FHIR を理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境で FHIR Server を起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。） 実行環境 macOS v10.14.3 Ruby v2.5.1 Docker v18.09.2 FHIR Server Docker コンテナで FHIR Server を起動します。簡単に動かせるように、DockerHub に公開されている HAPI-FHIR のコンテナイメージを利用します。 HAPI-FHIR とは、カナダのトロントにある医療研究機関の UHN(University Health Network)が立ち上げたプロジェクトで、FHIR のオープンソースライブラリを提供することを目的に活動しています。 GitHub - jamesagnew/hapi-fhir: 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers - jamesagnew/hapi-fhir github.com hub.docker.com hub.docker.com Docker コンテナイメージの取得 $ docker pull petersonjared/hapi-fhir $ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3 $ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar Docker をインストールするのが面倒な人は、HAPI-FHIR がグローバルに公開している テストサーバー を利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。 FHIR Client FHIR Client は、Ruby で動かします。以下の Gem を利用します。 $ gem install fhir_client $ gem install fhir_models Ruby のコードです。Patient リソースを作成して FHIR Server に登録します。 patient.rb require 'fhir_client' client = FHIR::Client . new ( "https://localhost:8080/baseDstu3" ) FHIR::Model . client = client patient = FHIR::Patient . new # 患者 ID identifier = FHIR::Identifier . new identifier. value = '12345678' patient. identifier = identifier # 患者氏名 human_name = FHIR::HumanName . new human_name. family = 'Kodama' human_name. given = 'Yoshinori' patient. name . push (human_name) # 性別 patient. gender = 'male' patient. create puts patient. id 上記のコードを実行すると、FHIR Server に Patient リソースが登録されます。ここでリソースを一意に特定するリソース ID が採番されます。今回は 19953 が採番されました。（puts patient.id で確認） このリソース ID を利用して、FHIR Server に HTTP リクエストを送ります。 $ curl https://localhost:8080/baseDstu3/Patient/19953 そうすると、先ほど登録したリソースが JSON 形式で取得できます。 { "resourceType" : "Patient" , "id" : "19953" , "meta" : { "versionId" : "1" , "lastUpdated" : "2019-03-21T09:12:44.660+00:00" }, "text" : { "status" : "generated" , "div" : "<div xmlns= \" https://www.w3.org/1999/xhtml \" ><div class= \" hapiHeaderText \" >Yoshinori <b>KODAMA </b></div><table class= \" hapiPropertyTable \" ><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>" }, "identifier" : [ { "value" : "12345678" } ], "name" : [ { "family" : "Kodama" , "given" : [ "Yoshinori" ] } ], "gender" : "male" } もちろん、患者 ID など利用して検索することも可能です。 $ curl https://localhost:8080/baseDstu3/Patient?identifier= 12345678 さいごに 今回の実証事業では、FHIR のインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は 厚生労働省のサイト に公開されていますので、詳細について興味のある方はこちらをご参照ください。 電子処方箋 www.mhlw.go.jp メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。 お知らせ 今回の電子処方箋実証事業の成果と、システム開発に活用した FHIR について共有するイベントを、以下のとおり 4 月 23 日(火)に開催します。お時間ある方はぜひご参加ください。 FHIR Meetup Tokyo #01 @ TECH PLAY SHIBUYA｜IT勉強会・イベントならTECH PLAY［テックプレイ］ 2019/04/23（火）開催 今後の医療ITシステムの核となるであろう技術として「FHIR」にフォーカスし、FHIRの概要、FHIRを活用したテクノロジー製品や事例の紹介、電子処方箋実証事業におけるFHIR活用の事例など、開発者がFHIRを具体的に活用していくためのノウハウを共有していきます。 techplay.jp また、メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。CLINICS 事業部の児玉です。 今回は、メドレーが 2018 年 12 月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の FHIR を基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。 FHIR とは FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格である HL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「 次世代の医療情報標準規格 」として世界各国で注目されています。 HL7 は、世界に 30 以上の国際支部を有しており、日本では 1998 年に 日本 HL7 協会 が設立されました。そして、現在流通している HL7 規格には、データ交換に利用される HL7v2 と、医用文書の記述に利用される CDA (Clinical Document Architecture)が存在します。 電子処方箋とは 電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関と調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。 実証事業の背景と概略 2016 年 3 月の法令改正で、処方箋の電子的な交付が可能となり、 運用ガイドライン も策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。 ガイドラインに定められた運用フロー（電子処方せんの運用ガイドラインより転載） 元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替として CDA で記述された静的ファイル を必要とし、記名押印の代替として HPKI を使用した 電子署名 が必要となります。 また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために 電子タイムスタンプ を付与する必要があります。 このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の 1 つであると考えられます。 こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。 実証事業概略 実施目的：電子処方箋の運用の仕組みの検討・実証・考察 実施期間：2019 年 2 月 4 日 - 2019 年 3 月 17 日 実証エリア：東京都港区 協力施設：2 医療機関 / 6 薬局 利用実績：64 件 電子処方箋管理システムの概要 以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHR アプリ」の 4 つのシステムから構成されています。 システム概観 処方箋管理システム 医療機関システム、薬局システム及び PHR アプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。 医療機関システム 診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードは QR コードの活用を想定し、QR コードを印字した紙又は電子データを患者に共有する。 ＊「QR コード」は株式会社デンソーウェーブの登録商標です。 薬局システム 訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。 PHR アプリ 患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。 医療機関システムは、メドレーのクラウド電子カルテ「CLINICS カルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。 処方箋管理システムは、前述の通り FHIR インターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。 HPKI を利用した SSO(Single Sign On)による本人資格確認 と、FHIR インターフェイスを利用した クラウドベースでのデータフロー を実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。 データ設計 FHIR には「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。 FHIR を利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。 例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。 実証事業で使用したリソース リソース 説明 Patient 患者 Practitioner 施術者（処方医／薬剤師） PractitionerRole 施術者役割 Organization 組織（医療機関／調剤薬局） MedicationRequest 投薬要求 MedicationDispense 調剤実施 Coverage 保険 FHIR を使用した所感 FHIR の改版は on-Going で行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急に FHIR のホームページが接続不安定になり困っていたところ、翌日には R4(Release 4)に更新されていたということもありました。 このように、日進月歩の FHIR をプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。 2018 年 12 月 27 日に R4 が Current Version になりました FHIR の利点は、従来の HL7 規格と比較した 実装容易性 にあると考えます。REST(REpresentational State Transfer)のように、Web サービスでは一般的に普及している概念を標準として取り込んでいるため、**実装者は特別な知識を習得する必要がありません。**また、FHIR を実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。 臨床概念モデルとしての観点では、CDA のベースとなっている HL7v3-RIM (Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指した RIM と比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。 また、1:1 のシステム連携におけるデータ交換では、すでに稼働している v2 インターフェイスを、無理して FHIR に置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。 実運用へ向けての課題 FHIR リソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックにマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、 指標となるガイドラインの策定 が必要になります。 また、リソースにマッピングする医薬品や用法のマスターコードについては、 厚生労働省標準マスター の利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、 標準マスター利用の推奨 も併せてガイドラインに明記することが必要です。 ガイドラインは、メドレー 1 社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者に FHIR を利用していただき、 実装方法についての議論 を交わす必要があります。しかし、現時点での日本国内における FHIR の活用事例は、残念ながらほとんど見られません。 次にご紹介するのは、FHIR を使用した簡単なコードのサンプルと、ローカル環境で FHIR Server を簡易的に動かす方法です。実装者の方が FHIR に触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。 FHIR の実装サンプル FHIR を理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境で FHIR Server を起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。） 実行環境 macOS v10.14.3 Ruby v2.5.1 Docker v18.09.2 FHIR Server Docker コンテナで FHIR Server を起動します。簡単に動かせるように、DockerHub に公開されている HAPI-FHIR のコンテナイメージを利用します。 HAPI-FHIR とは、カナダのトロントにある医療研究機関の UHN(University Health Network)が立ち上げたプロジェクトで、FHIR のオープンソースライブラリを提供することを目的に活動しています。 GitHub - jamesagnew/hapi-fhir: 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers - jamesagnew/hapi-fhir github.com hub.docker.com hub.docker.com Docker コンテナイメージの取得 $ docker pull petersonjared/hapi-fhir $ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3 $ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar Docker をインストールするのが面倒な人は、HAPI-FHIR がグローバルに公開している テストサーバー を利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。 FHIR Client FHIR Client は、Ruby で動かします。以下の Gem を利用します。 $ gem install fhir_client $ gem install fhir_models Ruby のコードです。Patient リソースを作成して FHIR Server に登録します。 patient.rb require 'fhir_client' client = FHIR::Client . new ( "https://localhost:8080/baseDstu3" ) FHIR::Model . client = client patient = FHIR::Patient . new # 患者 ID identifier = FHIR::Identifier . new identifier. value = '12345678' patient. identifier = identifier # 患者氏名 human_name = FHIR::HumanName . new human_name. family = 'Kodama' human_name. given = 'Yoshinori' patient. name . push (human_name) # 性別 patient. gender = 'male' patient. create puts patient. id 上記のコードを実行すると、FHIR Server に Patient リソースが登録されます。ここでリソースを一意に特定するリソース ID が採番されます。今回は 19953 が採番されました。（puts patient.id で確認） このリソース ID を利用して、FHIR Server に HTTP リクエストを送ります。 $ curl https://localhost:8080/baseDstu3/Patient/19953 そうすると、先ほど登録したリソースが JSON 形式で取得できます。 { "resourceType" : "Patient" , "id" : "19953" , "meta" : { "versionId" : "1" , "lastUpdated" : "2019-03-21T09:12:44.660+00:00" }, "text" : { "status" : "generated" , "div" : "<div xmlns= \" https://www.w3.org/1999/xhtml \" ><div class= \" hapiHeaderText \" >Yoshinori <b>KODAMA </b></div><table class= \" hapiPropertyTable \" ><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>" }, "identifier" : [ { "value" : "12345678" } ], "name" : [ { "family" : "Kodama" , "given" : [ "Yoshinori" ] } ], "gender" : "male" } もちろん、患者 ID など利用して検索することも可能です。 $ curl https://localhost:8080/baseDstu3/Patient?identifier= 12345678 さいごに 今回の実証事業では、FHIR のインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は 厚生労働省のサイト に公開されていますので、詳細について興味のある方はこちらをご参照ください。 電子処方箋 www.mhlw.go.jp メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。 お知らせ 今回の電子処方箋実証事業の成果と、システム開発に活用した FHIR について共有するイベントを、以下のとおり 4 月 23 日(火)に開催します。お時間ある方はぜひご参加ください。 FHIR Meetup Tokyo #01 @ TECH PLAY SHIBUYA｜IT勉強会・イベントならTECH PLAY［テックプレイ］ 2019/04/23（火）開催 今後の医療ITシステムの核となるであろう技術として「FHIR」にフォーカスし、FHIRの概要、FHIRを活用したテクノロジー製品や事例の紹介、電子処方箋実証事業におけるFHIR活用の事例など、開発者がFHIRを具体的に活用していくためのノウハウを共有していきます。 techplay.jp また、メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。CLINICS 事業部の児玉です。 今回は、メドレーが 2018 年 12 月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の FHIR を基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。 FHIR とは FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格である HL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「 次世代の医療情報標準規格 」として世界各国で注目されています。 HL7 は、世界に 30 以上の国際支部を有しており、日本では 1998 年に 日本 HL7 協会 が設立されました。そして、現在流通している HL7 規格には、データ交換に利用される HL7v2 と、医用文書の記述に利用される CDA (Clinical Document Architecture)が存在します。 電子処方箋とは 電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関と調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。 実証事業の背景と概略 2016 年 3 月の法令改正で、処方箋の電子的な交付が可能となり、 運用ガイドライン も策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。 ガイドラインに定められた運用フロー（電子処方せんの運用ガイドラインより転載） 元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替として CDA で記述された静的ファイル を必要とし、記名押印の代替として HPKI を使用した 電子署名 が必要となります。 また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために 電子タイムスタンプ を付与する必要があります。 このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の 1 つであると考えられます。 こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。 実証事業概略 実施目的：電子処方箋の運用の仕組みの検討・実証・考察 実施期間：2019 年 2 月 4 日 - 2019 年 3 月 17 日 実証エリア：東京都港区 協力施設：2 医療機関 / 6 薬局 利用実績：64 件 電子処方箋管理システムの概要 以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHR アプリ」の 4 つのシステムから構成されています。 システム概観 処方箋管理システム 医療機関システム、薬局システム及び PHR アプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。 医療機関システム 診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードは QR コードの活用を想定し、QR コードを印字した紙又は電子データを患者に共有する。 ＊「QR コード」は株式会社デンソーウェーブの登録商標です。 薬局システム 訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。 PHR アプリ 患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。 医療機関システムは、メドレーのクラウド電子カルテ「CLINICS カルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。 処方箋管理システムは、前述の通り FHIR インターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。 HPKI を利用した SSO(Single Sign On)による本人資格確認 と、FHIR インターフェイスを利用した クラウドベースでのデータフロー を実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。 データ設計 FHIR には「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。 FHIR を利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。 例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。 実証事業で使用したリソース リソース 説明 Patient 患者 Practitioner 施術者（処方医／薬剤師） PractitionerRole 施術者役割 Organization 組織（医療機関／調剤薬局） MedicationRequest 投薬要求 MedicationDispense 調剤実施 Coverage 保険 FHIR を使用した所感 FHIR の改版は on-Going で行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急に FHIR のホームページが接続不安定になり困っていたところ、翌日には R4(Release 4)に更新されていたということもありました。 このように、日進月歩の FHIR をプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。 2018 年 12 月 27 日に R4 が Current Version になりました FHIR の利点は、従来の HL7 規格と比較した 実装容易性 にあると考えます。REST(REpresentational State Transfer)のように、Web サービスでは一般的に普及している概念を標準として取り込んでいるため、**実装者は特別な知識を習得する必要がありません。**また、FHIR を実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。 臨床概念モデルとしての観点では、CDA のベースとなっている HL7v3-RIM (Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指した RIM と比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。 また、1:1 のシステム連携におけるデータ交換では、すでに稼働している v2 インターフェイスを、無理して FHIR に置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。 実運用へ向けての課題 FHIR リソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックにマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、 指標となるガイドラインの策定 が必要になります。 また、リソースにマッピングする医薬品や用法のマスターコードについては、 厚生労働省標準マスター の利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、 標準マスター利用の推奨 も併せてガイドラインに明記することが必要です。 ガイドラインは、メドレー 1 社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者に FHIR を利用していただき、 実装方法についての議論 を交わす必要があります。しかし、現時点での日本国内における FHIR の活用事例は、残念ながらほとんど見られません。 次にご紹介するのは、FHIR を使用した簡単なコードのサンプルと、ローカル環境で FHIR Server を簡易的に動かす方法です。実装者の方が FHIR に触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。 FHIR の実装サンプル FHIR を理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境で FHIR Server を起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。） 実行環境 macOS v10.14.3 Ruby v2.5.1 Docker v18.09.2 FHIR Server Docker コンテナで FHIR Server を起動します。簡単に動かせるように、DockerHub に公開されている HAPI-FHIR のコンテナイメージを利用します。 HAPI-FHIR とは、カナダのトロントにある医療研究機関の UHN(University Health Network)が立ち上げたプロジェクトで、FHIR のオープンソースライブラリを提供することを目的に活動しています。 GitHub - jamesagnew/hapi-fhir: 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers - jamesagnew/hapi-fhir github.com hub.docker.com hub.docker.com Docker コンテナイメージの取得 $ docker pull petersonjared/hapi-fhir $ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3 $ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar Docker をインストールするのが面倒な人は、HAPI-FHIR がグローバルに公開している テストサーバー を利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。 FHIR Client FHIR Client は、Ruby で動かします。以下の Gem を利用します。 $ gem install fhir_client $ gem install fhir_models Ruby のコードです。Patient リソースを作成して FHIR Server に登録します。 patient.rb require 'fhir_client' client = FHIR::Client . new ( "https://localhost:8080/baseDstu3" ) FHIR::Model . client = client patient = FHIR::Patient . new # 患者 ID identifier = FHIR::Identifier . new identifier. value = '12345678' patient. identifier = identifier # 患者氏名 human_name = FHIR::HumanName . new human_name. family = 'Kodama' human_name. given = 'Yoshinori' patient. name . push (human_name) # 性別 patient. gender = 'male' patient. create puts patient. id 上記のコードを実行すると、FHIR Server に Patient リソースが登録されます。ここでリソースを一意に特定するリソース ID が採番されます。今回は 19953 が採番されました。（puts patient.id で確認） このリソース ID を利用して、FHIR Server に HTTP リクエストを送ります。 $ curl https://localhost:8080/baseDstu3/Patient/19953 そうすると、先ほど登録したリソースが JSON 形式で取得できます。 { "resourceType" : "Patient" , "id" : "19953" , "meta" : { "versionId" : "1" , "lastUpdated" : "2019-03-21T09:12:44.660+00:00" }, "text" : { "status" : "generated" , "div" : "<div xmlns= \" https://www.w3.org/1999/xhtml \" ><div class= \" hapiHeaderText \" >Yoshinori <b>KODAMA </b></div><table class= \" hapiPropertyTable \" ><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>" }, "identifier" : [ { "value" : "12345678" } ], "name" : [ { "family" : "Kodama" , "given" : [ "Yoshinori" ] } ], "gender" : "male" } もちろん、患者 ID など利用して検索することも可能です。 $ curl https://localhost:8080/baseDstu3/Patient?identifier= 12345678 さいごに 今回の実証事業では、FHIR のインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は 厚生労働省のサイト に公開されていますので、詳細について興味のある方はこちらをご参照ください。 電子処方箋 www.mhlw.go.jp メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。 お知らせ 今回の電子処方箋実証事業の成果と、システム開発に活用した FHIR について共有するイベントを、以下のとおり 4 月 23 日(火)に開催します。お時間ある方はぜひご参加ください。 FHIR Meetup Tokyo #01 @ TECH PLAY SHIBUYA｜IT勉強会・イベントならTECH PLAY［テックプレイ］ 2019/04/23（火）開催 今後の医療ITシステムの核となるであろう技術として「FHIR」にフォーカスし、FHIRの概要、FHIRを活用したテクノロジー製品や事例の紹介、電子処方箋実証事業におけるFHIR活用の事例など、開発者がFHIRを具体的に活用していくためのノウハウを共有していきます。 techplay.jp また、メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。CLINICS 事業部の児玉です。 今回は、メドレーが 2018 年 12 月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の FHIR を基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。 FHIR とは FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格である HL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「 次世代の医療情報標準規格 」として世界各国で注目されています。 HL7 は、世界に 30 以上の国際支部を有しており、日本では 1998 年に 日本 HL7 協会 が設立されました。そして、現在流通している HL7 規格には、データ交換に利用される HL7v2 と、医用文書の記述に利用される CDA (Clinical Document Architecture)が存在します。 電子処方箋とは 電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関と調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。 実証事業の背景と概略 2016 年 3 月の法令改正で、処方箋の電子的な交付が可能となり、 運用ガイドライン も策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。 ガイドラインに定められた運用フロー（電子処方せんの運用ガイドラインより転載） 元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替として CDA で記述された静的ファイル を必要とし、記名押印の代替として HPKI を使用した 電子署名 が必要となります。 また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために 電子タイムスタンプ を付与する必要があります。 このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の 1 つであると考えられます。 こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。 実証事業概略 実施目的：電子処方箋の運用の仕組みの検討・実証・考察 実施期間：2019 年 2 月 4 日 - 2019 年 3 月 17 日 実証エリア：東京都港区 協力施設：2 医療機関 / 6 薬局 利用実績：64 件 電子処方箋管理システムの概要 以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHR アプリ」の 4 つのシステムから構成されています。 システム概観 処方箋管理システム 医療機関システム、薬局システム及び PHR アプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。 医療機関システム 診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードは QR コードの活用を想定し、QR コードを印字した紙又は電子データを患者に共有する。 ＊「QR コード」は株式会社デンソーウェーブの登録商標です。 薬局システム 訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。 PHR アプリ 患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。 医療機関システムは、メドレーのクラウド電子カルテ「CLINICS カルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。 処方箋管理システムは、前述の通り FHIR インターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。 HPKI を利用した SSO(Single Sign On)による本人資格確認 と、FHIR インターフェイスを利用した クラウドベースでのデータフロー を実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。 データ設計 FHIR には「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。 FHIR を利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。 例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。 実証事業で使用したリソース リソース 説明 Patient 患者 Practitioner 施術者（処方医／薬剤師） PractitionerRole 施術者役割 Organization 組織（医療機関／調剤薬局） MedicationRequest 投薬要求 MedicationDispense 調剤実施 Coverage 保険 FHIR を使用した所感 FHIR の改版は on-Going で行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急に FHIR のホームページが接続不安定になり困っていたところ、翌日には R4(Release 4)に更新されていたということもありました。 このように、日進月歩の FHIR をプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。 2018 年 12 月 27 日に R4 が Current Version になりました FHIR の利点は、従来の HL7 規格と比較した 実装容易性 にあると考えます。REST(REpresentational State Transfer)のように、Web サービスでは一般的に普及している概念を標準として取り込んでいるため、**実装者は特別な知識を習得する必要がありません。**また、FHIR を実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。 臨床概念モデルとしての観点では、CDA のベースとなっている HL7v3-RIM (Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指した RIM と比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。 また、1:1 のシステム連携におけるデータ交換では、すでに稼働している v2 インターフェイスを、無理して FHIR に置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。 実運用へ向けての課題 FHIR リソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックにマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、 指標となるガイドラインの策定 が必要になります。 また、リソースにマッピングする医薬品や用法のマスターコードについては、 厚生労働省標準マスター の利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、 標準マスター利用の推奨 も併せてガイドラインに明記することが必要です。 ガイドラインは、メドレー 1 社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者に FHIR を利用していただき、 実装方法についての議論 を交わす必要があります。しかし、現時点での日本国内における FHIR の活用事例は、残念ながらほとんど見られません。 次にご紹介するのは、FHIR を使用した簡単なコードのサンプルと、ローカル環境で FHIR Server を簡易的に動かす方法です。実装者の方が FHIR に触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。 FHIR の実装サンプル FHIR を理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境で FHIR Server を起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。） 実行環境 macOS v10.14.3 Ruby v2.5.1 Docker v18.09.2 FHIR Server Docker コンテナで FHIR Server を起動します。簡単に動かせるように、DockerHub に公開されている HAPI-FHIR のコンテナイメージを利用します。 HAPI-FHIR とは、カナダのトロントにある医療研究機関の UHN(University Health Network)が立ち上げたプロジェクトで、FHIR のオープンソースライブラリを提供することを目的に活動しています。 GitHub - jamesagnew/hapi-fhir: 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers - jamesagnew/hapi-fhir github.com hub.docker.com hub.docker.com Docker コンテナイメージの取得 $ docker pull petersonjared/hapi-fhir $ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3 $ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar Docker をインストールするのが面倒な人は、HAPI-FHIR がグローバルに公開している テストサーバー を利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。 FHIR Client FHIR Client は、Ruby で動かします。以下の Gem を利用します。 $ gem install fhir_client $ gem install fhir_models Ruby のコードです。Patient リソースを作成して FHIR Server に登録します。 patient.rb require 'fhir_client' client = FHIR::Client . new ( "https://localhost:8080/baseDstu3" ) FHIR::Model . client = client patient = FHIR::Patient . new # 患者 ID identifier = FHIR::Identifier . new identifier. value = '12345678' patient. identifier = identifier # 患者氏名 human_name = FHIR::HumanName . new human_name. family = 'Kodama' human_name. given = 'Yoshinori' patient. name . push (human_name) # 性別 patient. gender = 'male' patient. create puts patient. id 上記のコードを実行すると、FHIR Server に Patient リソースが登録されます。ここでリソースを一意に特定するリソース ID が採番されます。今回は 19953 が採番されました。（puts patient.id で確認） このリソース ID を利用して、FHIR Server に HTTP リクエストを送ります。 $ curl https://localhost:8080/baseDstu3/Patient/19953 そうすると、先ほど登録したリソースが JSON 形式で取得できます。 { "resourceType" : "Patient" , "id" : "19953" , "meta" : { "versionId" : "1" , "lastUpdated" : "2019-03-21T09:12:44.660+00:00" }, "text" : { "status" : "generated" , "div" : "<div xmlns= \" https://www.w3.org/1999/xhtml \" ><div class= \" hapiHeaderText \" >Yoshinori <b>KODAMA </b></div><table class= \" hapiPropertyTable \" ><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>" }, "identifier" : [ { "value" : "12345678" } ], "name" : [ { "family" : "Kodama" , "given" : [ "Yoshinori" ] } ], "gender" : "male" } もちろん、患者 ID など利用して検索することも可能です。 $ curl https://localhost:8080/baseDstu3/Patient?identifier= 12345678 さいごに 今回の実証事業では、FHIR のインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は 厚生労働省のサイト に公開されていますので、詳細について興味のある方はこちらをご参照ください。 電子処方箋 www.mhlw.go.jp メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。 お知らせ 今回の電子処方箋実証事業の成果と、システム開発に活用した FHIR について共有するイベントを、以下のとおり 4 月 23 日(火)に開催します。お時間ある方はぜひご参加ください。 FHIR Meetup Tokyo #01 @ TECH PLAY SHIBUYA｜IT勉強会・イベントならTECH PLAY［テックプレイ］ 2019/04/23（火）開催 今後の医療ITシステムの核となるであろう技術として「FHIR」にフォーカスし、FHIRの概要、FHIRを活用したテクノロジー製品や事例の紹介、電子処方箋実証事業におけるFHIR活用の事例など、開発者がFHIRを具体的に活用していくためのノウハウを共有していきます。 techplay.jp また、メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。CLINICS 事業部の児玉です。 今回は、メドレーが 2018 年 12 月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の FHIR を基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。 FHIR とは FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格である HL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「 次世代の医療情報標準規格 」として世界各国で注目されています。 HL7 は、世界に 30 以上の国際支部を有しており、日本では 1998 年に 日本 HL7 協会 が設立されました。そして、現在流通している HL7 規格には、データ交換に利用される HL7v2 と、医用文書の記述に利用される CDA (Clinical Document Architecture)が存在します。 電子処方箋とは 電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関と調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。 実証事業の背景と概略 2016 年 3 月の法令改正で、処方箋の電子的な交付が可能となり、 運用ガイドライン も策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。 ガイドラインに定められた運用フロー（電子処方せんの運用ガイドラインより転載） 元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替として CDA で記述された静的ファイル を必要とし、記名押印の代替として HPKI を使用した 電子署名 が必要となります。 また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために 電子タイムスタンプ を付与する必要があります。 このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の 1 つであると考えられます。 こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。 実証事業概略 実施目的：電子処方箋の運用の仕組みの検討・実証・考察 実施期間：2019 年 2 月 4 日 - 2019 年 3 月 17 日 実証エリア：東京都港区 協力施設：2 医療機関 / 6 薬局 利用実績：64 件 電子処方箋管理システムの概要 以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHR アプリ」の 4 つのシステムから構成されています。 システム概観 処方箋管理システム 医療機関システム、薬局システム及び PHR アプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。 医療機関システム 診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードは QR コードの活用を想定し、QR コードを印字した紙又は電子データを患者に共有する。 ＊「QR コード」は株式会社デンソーウェーブの登録商標です。 薬局システム 訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。 PHR アプリ 患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。 医療機関システムは、メドレーのクラウド電子カルテ「CLINICS カルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。 処方箋管理システムは、前述の通り FHIR インターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。 HPKI を利用した SSO(Single Sign On)による本人資格確認 と、FHIR インターフェイスを利用した クラウドベースでのデータフロー を実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。 データ設計 FHIR には「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。 FHIR を利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。 例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。 実証事業で使用したリソース リソース 説明 Patient 患者 Practitioner 施術者（処方医／薬剤師） PractitionerRole 施術者役割 Organization 組織（医療機関／調剤薬局） MedicationRequest 投薬要求 MedicationDispense 調剤実施 Coverage 保険 FHIR を使用した所感 FHIR の改版は on-Going で行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急に FHIR のホームページが接続不安定になり困っていたところ、翌日には R4(Release 4)に更新されていたということもありました。 このように、日進月歩の FHIR をプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。 2018 年 12 月 27 日に R4 が Current Version になりました FHIR の利点は、従来の HL7 規格と比較した 実装容易性 にあると考えます。REST(REpresentational State Transfer)のように、Web サービスでは一般的に普及している概念を標準として取り込んでいるため、**実装者は特別な知識を習得する必要がありません。**また、FHIR を実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。 臨床概念モデルとしての観点では、CDA のベースとなっている HL7v3-RIM (Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指した RIM と比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。 また、1:1 のシステム連携におけるデータ交換では、すでに稼働している v2 インターフェイスを、無理して FHIR に置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。 実運用へ向けての課題 FHIR リソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックにマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、 指標となるガイドラインの策定 が必要になります。 また、リソースにマッピングする医薬品や用法のマスターコードについては、 厚生労働省標準マスター の利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、 標準マスター利用の推奨 も併せてガイドラインに明記することが必要です。 ガイドラインは、メドレー 1 社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者に FHIR を利用していただき、 実装方法についての議論 を交わす必要があります。しかし、現時点での日本国内における FHIR の活用事例は、残念ながらほとんど見られません。 次にご紹介するのは、FHIR を使用した簡単なコードのサンプルと、ローカル環境で FHIR Server を簡易的に動かす方法です。実装者の方が FHIR に触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。 FHIR の実装サンプル FHIR を理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境で FHIR Server を起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。） 実行環境 macOS v10.14.3 Ruby v2.5.1 Docker v18.09.2 FHIR Server Docker コンテナで FHIR Server を起動します。簡単に動かせるように、DockerHub に公開されている HAPI-FHIR のコンテナイメージを利用します。 HAPI-FHIR とは、カナダのトロントにある医療研究機関の UHN(University Health Network)が立ち上げたプロジェクトで、FHIR のオープンソースライブラリを提供することを目的に活動しています。 GitHub - jamesagnew/hapi-fhir: 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers 🔥 HAPI FHIR - Java API for HL7 FHIR Clients and Servers - jamesagnew/hapi-fhir github.com hub.docker.com hub.docker.com Docker コンテナイメージの取得 $ docker pull petersonjared/hapi-fhir $ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3 $ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar Docker をインストールするのが面倒な人は、HAPI-FHIR がグローバルに公開している テストサーバー を利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。 FHIR Client FHIR Client は、Ruby で動かします。以下の Gem を利用します。 $ gem install fhir_client $ gem install fhir_models Ruby のコードです。Patient リソースを作成して FHIR Server に登録します。 patient.rb require 'fhir_client' client = FHIR::Client . new ( "https://localhost:8080/baseDstu3" ) FHIR::Model . client = client patient = FHIR::Patient . new # 患者 ID identifier = FHIR::Identifier . new identifier. value = '12345678' patient. identifier = identifier # 患者氏名 human_name = FHIR::HumanName . new human_name. family = 'Kodama' human_name. given = 'Yoshinori' patient. name . push (human_name) # 性別 patient. gender = 'male' patient. create puts patient. id 上記のコードを実行すると、FHIR Server に Patient リソースが登録されます。ここでリソースを一意に特定するリソース ID が採番されます。今回は 19953 が採番されました。（puts patient.id で確認） このリソース ID を利用して、FHIR Server に HTTP リクエストを送ります。 $ curl https://localhost:8080/baseDstu3/Patient/19953 そうすると、先ほど登録したリソースが JSON 形式で取得できます。 { "resourceType" : "Patient" , "id" : "19953" , "meta" : { "versionId" : "1" , "lastUpdated" : "2019-03-21T09:12:44.660+00:00" }, "text" : { "status" : "generated" , "div" : "<div xmlns= \" https://www.w3.org/1999/xhtml \" ><div class= \" hapiHeaderText \" >Yoshinori <b>KODAMA </b></div><table class= \" hapiPropertyTable \" ><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>" }, "identifier" : [ { "value" : "12345678" } ], "name" : [ { "family" : "Kodama" , "given" : [ "Yoshinori" ] } ], "gender" : "male" } もちろん、患者 ID など利用して検索することも可能です。 $ curl https://localhost:8080/baseDstu3/Patient?identifier= 12345678 さいごに 今回の実証事業では、FHIR のインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は 厚生労働省のサイト に公開されていますので、詳細について興味のある方はこちらをご参照ください。 電子処方箋 www.mhlw.go.jp メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。 お知らせ 今回の電子処方箋実証事業の成果と、システム開発に活用した FHIR について共有するイベントを、以下のとおり 4 月 23 日(火)に開催します。お時間ある方はぜひご参加ください。 FHIR Meetup Tokyo #01 @ TECH PLAY SHIBUYA｜IT勉強会・イベントならTECH PLAY［テックプレイ］ 2019/04/23（火）開催 今後の医療ITシステムの核となるであろう技術として「FHIR」にフォーカスし、FHIRの概要、FHIRを活用したテクノロジー製品や事例の紹介、電子処方箋実証事業におけるFHIR活用の事例など、開発者がFHIRを具体的に活用していくためのノウハウを共有していきます。 techplay.jp また、メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。CLINICS 事業部の児玉です。 今回は、メドレーが 2018 年 12 月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の FHIR を基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。 FHIR とは FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格である HL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「 次世代の医療情報標準規格 」として世界各国で注目されています。 HL7 は、世界に 30 以上の国際支部を有しており、日本では 1998 年に 日本 HL7 協会 が設立されました。そして、現在流通している HL7 規格には、データ交換に利用される HL7v2 と、医用文書の記述に利用される CDA (Clinical Document Architecture)が存在します。 電子処方箋とは 電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関と調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。 実証事業の背景と概略 2016 年 3 月の法令改正で、処方箋の電子的な交付が可能となり、 運用ガイドライン も策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。 ガイドラインに定められた運用フロー（電子処方せんの運用ガイドラインより転載） 元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替として CDA で記述された静的ファイル を必要とし、記名押印の代替として HPKI を使用した 電子署名 が必要となります。 また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために 電子タイムスタンプ を付与する必要があります。 このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の 1 つであると考えられます。 こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。 実証事業概略 実施目的：電子処方箋の運用の仕組みの検討・実証・考察 実施期間：2019 年 2 月 4 日 - 2019 年 3 月 17 日 実証エリア：東京都港区 協力施設：2 医療機関 / 6 薬局 利用実績：64 件 電子処方箋管理システムの概要 以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHR アプリ」の 4 つのシステムから構成されています。 システム概観 処方箋管理システム 医療機関システム、薬局システム及び PHR アプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。 医療機関システム 診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードは QR コードの活用を想定し、QR コードを印字した紙又は電子データを患者に共有する。 ＊「QR コード」は株式会社デンソーウェーブの登録商標です。 薬局システム 訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。 PHR アプリ 患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。 医療機関システムは、メドレーのクラウド電子カルテ「CLINICS カルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。 処方箋管理システムは、前述の通り FHIR インターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。 HPKI を利用した SSO(Single Sign On)による本人資格確認 と、FHIR インターフェイスを利用した クラウドベースでのデータフロー を実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。 データ設計 FHIR には「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。 FHIR を利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。 例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。 実証事業で使用したリソース リソース 説明 Patient 患者 Practitioner 施術者（処方医／薬剤師） PractitionerRole 施術者役割 Organization 組織（医療機関／調剤薬局） MedicationRequest 投薬要求 MedicationDispense 調剤実施 Coverage 保険 FHIR を使用した所感 FHIR の改版は on-Going で行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急に FHIR のホームページが接続不安定になり困っていたところ、翌日には R4(Release 4)に更新されていたということもありました。 このように、日進月歩の FHIR をプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。 2018 年 12 月 27 日に R4 が Current Version になりました FHIR の利点は、従来の HL7 規格と比較した 実装容易性 にあると考えます。REST(REpresentational State Transfer)のように、Web サービスでは一般的に普及している概念を標準として取り込んでいるため、**実装者は特別な知識を習得する必要がありません。**また、FHIR を実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。 臨床概念モデルとしての観点では、CDA のベースとなっている HL7v3-RIM (Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指した RIM と比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。 また、1:1 のシステム連携におけるデータ交換では、すでに稼働している v2 インターフェイスを、無理して FHIR に置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。 実運用へ向けての課題 FHIR リソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックにマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、 指標となるガイドラインの策定 が必要になります。 また、リソースにマッピングする医薬品や用法のマスターコードについては、 厚生労働省標準マスター の利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、 標準マスター利用の推奨 も併せてガイドラインに明記することが必要です。 ガイドラインは、メドレー 1 社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者に FHIR を利用していただき、 実装方法についての議論 を交わす必要があります。しかし、現時点での日本国内における FHIR の活用事例は、残念ながらほとんど見られません。 次にご紹介するのは、FHIR を使用した簡単なコードのサンプルと、ローカル環境で FHIR Server を簡易的に動かす方法です。実装者の方が FHIR に触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。 FHIR の実装サンプル FHIR を理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境で FHIR Server を起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。） 実行環境 macOS v10.14.3 Ruby v2.5.1 Docker v18.09.2 FHIR Server Docker コンテナで FHIR Server を起動します。簡単に動かせるように、DockerHub に公開されている HAPI-FHIR のコンテナイメージを利用します。 HAPI-FHIR とは、カナダのトロントにある医療研究機関の UHN(University Health Network)が立ち上げたプロジェクトで、FHIR のオープンソースライブラリを提供することを目的に活動しています。 https://github.com/jamesagnew/hapi-fhir https://hub.docker.com/r/petersonjared/hapi-fhir Docker コンテナイメージの取得 $ docker pull petersonjared/hapi-fhir $ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3 $ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar Docker をインストールするのが面倒な人は、HAPI-FHIR がグローバルに公開している テストサーバー を利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。 FHIR Client FHIR Client は、Ruby で動かします。以下の Gem を利用します。 $ gem install fhir_client $ gem install fhir_models Ruby のコードです。Patient リソースを作成して FHIR Server に登録します。 patient.rb require 'fhir_client' client = FHIR::Client.new("https://localhost:8080/baseDstu3") FHIR::Model.client = client patient = FHIR::Patient.new # 患者 ID identifier = FHIR::Identifier.new identifier.value = '12345678' patient.identifier = identifier # 患者氏名 human_name = FHIR::HumanName.new human_name.family = 'Kodama' human_name.given = 'Yoshinori' patient.name.push(human_name) # 性別 patient.gender = 'male' patient.create puts patient.id 上記のコードを実行すると、FHIR Server に Patient リソースが登録されます。ここでリソースを一意に特定するリソース ID が採番されます。今回は 19953 が採番されました。（puts patient.id で確認） このリソース ID を利用して、FHIR Server に HTTP リクエストを送ります。 $ curl https://localhost:8080/baseDstu3/Patient/19953 そうすると、先ほど登録したリソースが JSON 形式で取得できます。 { "resourceType": "Patient", "id": "19953", "meta": { "versionId": "1", "lastUpdated": "2019-03-21T09:12:44.660+00:00" }, "text": { "status": "generated", "div": "<div xmlns=\"https://www.w3.org/1999/xhtml\"><div class=\"hapiHeaderText\">Yoshinori <b>KODAMA </b></div><table class=\"hapiPropertyTable\"><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>" }, "identifier": [ { "value": "12345678" } ], "name": [ { "family": "Kodama", "given": ["Yoshinori"] } ], "gender": "male" } もちろん、患者 ID など利用して検索することも可能です。 $ curl https://localhost:8080/baseDstu3/Patient?identifier=12345678 さいごに 今回の実証事業では、FHIR のインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は 厚生労働省のサイト に公開されていますので、詳細について興味のある方はこちらをご参照ください。 https://www.mhlw.go.jp/stf/denshishohousen.html メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。 お知らせ 今回の電子処方箋実証事業の成果と、システム開発に活用した FHIR について共有するイベントを、以下のとおり 4 月 23 日(火)に開催します。お時間ある方はぜひご参加ください。 https://techplay.jp/event/725549 また、メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。 https://www.medley.jp/recruit/creative.html

おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。