みなさん、こんにちは。開発本部の平木です。
2017年から、RubyKaigiにスポンサーとして参加していましたが、今年も朝食スポンサーとして協賛することになりました!
(去年とおととしの参加レポート)
会場である、福岡国際会議場内の1Fにあるレストラン ラコンテさんでビュッフェ形式の朝食を楽しむことができます。
会期中の4/19~20日の8:30 ~ 10:00で開催しています。当日はメドレーメンバーがご案内する予定になっていますので、ぜひお気軽に話かけてください!目印として、メンバーはメドレーパーカーを着用しています。
メニューは和洋それぞれ用意があり、福岡ならではのメニューも入っていますので、1日の始まりにぜひおいしい朝食を食べて元気にセッションに臨んでください。
また、スポンサーブース内にもメドレーブースが常設されており、エンジニア4人も行く予定となっていますので、ぜひお立ち寄りいただいて、みなさんと交流できればと思います。
それでは、RubyKaigiという大きなイベントでまた皆様にお会いできるのを楽しみにしています!!
こんにちは。CLINICS事業部の児玉です。
今回は、メドレーが2018年12月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格の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つであると考えられます。
こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関と調剤薬局を使用したフィールド実験を実施しました。
実証事業概略
以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHRアプリ」の4つのシステムから構成されています。
処方箋管理システム
医療機関システム、薬局システム及びPHRアプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。
医療機関システム
診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードはQRコードの活用を想定し、QRコードを印字した紙又は電子データを患者に共有する。
薬局システム
訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。
PHRアプリ
患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。
医療機関システムは、メドレーのクラウド電子カルテ「CLINICSカルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。
処方箋管理システムは、前述の通りFHIRインターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。
HPKIを利用したSSO(Single Sign On)による本人資格確認と、FHIRインターフェイスを利用したクラウドベースでのデータフローを実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。
FHIRには「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。
FHIRを利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。
例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。
実証事業で使用したリソース
| リソース | 説明 |
|---|---|
| Patient | 患者 |
| Practitioner | 施術者（処方医／薬剤師） |
| PractitionerRole | 施術者役割 |
| Organization | 組織（医療機関／調剤薬局） |
| MedicationRequest | 投薬要求 |
| MedicationDispense | 調剤実施 |
| Coverage | 保険 |
FHIRの改版はon-Goingで行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急にFHIRのホームページが接続不安定になり困っていたところ、翌日にはR4(Release 4)に更新されていたということもありました。
このように、日進月歩のFHIRをプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。
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 Serverを起動して、リソースを登録する簡単なプログラムを書いてみました。（オープンソースの恩恵を最大限に享受しています。）
DockerコンテナでFHIR Serverを起動します。簡単に動かせるように、DockerHubに公開されているHAPI-FHIRのコンテナイメージを利用します。
HAPI-FHIRとは、カナダのトロントにある医療研究機関のUHN(University Health Network)が立ち上げたプロジェクトで、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は、Rubyで動かします。以下のGemを利用します。
$ gem install fhir_client $ gem install fhir_models
Rubyのコードです。Patientリソースを作成してFHIR Serverに登録します。
patient.rb
require 'fhir_client' client = FHIR::Client.new("http://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 http://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=\"http://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 http://localhost:8080/baseDstu3/Patient?identifier=12345678
今回の実証事業では、FHIRのインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は厚生労働省のサイトに公開されていますので、詳細について興味のある方はこちらをご参照ください。
メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。
今回の電子処方箋実証事業の成果と、システム開発に活用したFHIRについて共有するイベントを、以下のとおり4月23日(火)に開催します。お時間ある方はぜひご参加ください。
また、メドレーでは医療業界に存在する課題にITを駆使して取り組んでいきたいメンバーを、デザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。
おはこんばんちは、開発本部エンジニアの大岡です。
先日、TechLunchという社内勉強会で「フロントエンジニアがUI設計〜実装で考えていること」という内容で発表しました。UI設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。
UI設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独でUI設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。
とその前に、他人とUIについて話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。
自分が他の人にUIデザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。
— Yukari Shingyouchi / 手描きノート (@singularity8888) 2018年12月2日
私の中では、これ系の言葉は、
初心者：使いがち
中級者：ほぼ使わない
上級者：たまに使ってる
みたいな印象があります。 pic.twitter.com/O2URgRCVHe
これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。今回何ヶ所か使っていますが実際UIについて話すときは使わないように心がけています。
デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。
など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。
など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。
手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめるように努力してます。
「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。
それらを踏まえ、すでに実装済みのUIで似たようなものがあれば似たように作ります。理由としては既にユーザが学習済みのUIのため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。
似たようなUIがなく新たに作らなければならないときは以下を意識しています。
などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑
細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。
など細かいことを言い出したらキリがないですが、こんなこと意識してます。
いろいろと書きましたがUI設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを
とした場合に、このサイクルをリリースまでに多く回すことによってより多くの気づきが得られるからです。基本的には一回作ってうまくいくことは希かと思っているからです。
ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。
フロントエンドのUIやパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。
初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し一人でも多くの人に触ってもらい気付ける回数を増やすことは大事なことだと思っています。
あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。
▼メドレーで働くクリエイターたちのストーリーはこちら
こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQueryのPartitioned tableについて発表しましたので、その話について書きたいと思います。
ある案件でユーザーの操作ログを扱う必要があり、データ保管先にBigQueryを利用しようと考えていました。その際に、「以前はβ版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。
ユーザーの行動/操作ログの確認についてはAPIサーバーのアクセスログで、ある程度その目的を果たすことができていました。
しかし、APIのアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。
ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しくPartitioned tableに保存することにしました。
また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。
まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQueryではいくつかの実現方法があります。
前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列としてDATE型またはTIMESTAMP型を指定することで利用することができます。
こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。
注意点として公式ドキュメントにもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシーSQLを利用することができないため、標準SQLを利用する必要があります。
分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。
そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。
今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。
そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUIのテーブル情報の詳細タブから確認できます）
前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。
とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。
まずは試しに 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はより適した用途のように思いますので、こちらも今後検証していきたいと思います。
こんにちは。開発本部エンジニアの平木です。
去る2019/02/23(土)に開催されたJAWS-UG（AWS User Group – Japan）主催の全国規模での交流イベントであるJAWS DAYS 2019にメドレーがランチサポーターとして協賛させていただきましたので、当日の様子などをお伝えしていきます。
自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場のTOC五反田メッセはイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国からAWSユーザが集まるイベントの規模の大きさが伺えました。
公式発表で1,900人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。
セッションもバラエティに富んだラインナップで見たいものが若干カブってしまっていた位で、大変有意義なものでした。
またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、JAWS-UG公式Twitterに負けず劣らず、アマゾンウェブサービス公式Twitterでイベントの様子をTweetしていたのは、さすがだなと思わされました。
さて、そんな活気に包まれていたJAWS DAYS 2019での弊社のスポンサーとしての取り組みについてですが、今回はランチサポーターとして協賛させていただきました。
まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。
パンフレットを置かせていただいていたのは、会場内で2番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。
そして、ランチサポーターとしてランチセッションで弊社の田中がAWSマネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウと題したセッションでお話させていただきました。
メドレーで運営しているサービスであるCLINICSカルテをAWSを使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWSの各サービスをどのように使っているか?というお話をさせていただきました。
詳細としては
といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。
イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました!
メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽にお問い合わせいただければと思います。
食べて飲んで寛いで、プロダクトや組織への思いなどお酒を交えつつ談笑し、夜遅くまで楽しい時間を過ごしました。
