JP Core FHIR サンドボックス
FHIRとJP Core Profileの公開サンドボックスサーバーを、https://medplum-jp-core.keta.nyc で今すぐお試しください。
一見手間がかかりそうに見えることこそ、実は最も手間を省いてくれる理由：日本で医療ソフトウェアを開発するすべての人に向けた実践的な入門ガイド
FHIR仕様書を初めて目にする人は、ほぼ皆同じ反応を示します。そして日本では、たいてい思わず口から漏れ出ます。
「なんだこれ」
140種類以上のリソースタイプ。数十もの要素を持つPatient Resourceがあり、そのほとんどは決して値を設定することのないものです。Extensionの上にさらにExtensionが重ねられています。ValueSets、CodeSystems、Profile、Implementation Guide、Conformance Resource（適合性リソース）。そして、現在開いているドキュメントのルールを説明する別のドキュメントを指し示すことだけを目的としたmeta.profileフィールドなどです。一体、これらすべてで何を保存しようというのでしょうか？ 名前と生年月日だけでしょうか？
私はこれまで、多くの優秀なエンジニアたちがこの時点で同じ結論に達するのを見てきました。「これは企業特有の形式的な手続きに過ぎない。もっと良い方法があるはずだ。自分たちで独自のものを作ろう」
私は、この反応が100%妥当であり、100%理解できるということをお伝えしたいのです。
そして約6ヶ月後には「100%間違っていた」と気づくことになります。それはFHIRが素晴らしいからではありません。結局のところ、遅かれ早かれ自分たちで同じものを作る羽目になるからです。
「温泉旅館」の問題
日本のエンジニアたちが、ある種のシステムを指して使う言葉があります。それは「温泉旅館建築（onsen ryokan architecture）」です。はじめは控えめでこぢんまりとした上品な建物だったものが、やがて渡り廊下が伸び、別館が増築され、存在しない階へと続く階段が足され……最終的には、そこで20年間働いているベテランしかその構造を把握できなくなってしまうようなシステムのことです。
日本の厨房にも似たような概念があります。1952年以来、一度も空にされることなく継ぎ足され続けてきた「秘伝のタレ」です。実に美味しい。しかも、その中身に何が入っているのかは誰にもわかりません。
私がこれまでに目にしてきたヘルステック製品は、どれも例外なく患者の診療記録を「温泉旅館」にしてしまっています。そのプロセスは大体こんな感じです。
第1週：patientsテーブル。ID, family_name, given_name, dob, sex。シンプル。美しく洗練されている。最高の気分です。
第3週：ソートや受付用にフリガナが必要だとプロダクト側から要望が入ります。そこで同じ名前に2つ目の表記が必要になりました。family_kanaとgiven_kanaを追加します。すると、「全角と半角どちらで保存するのか」「連携先のレガシーシステムはこちらの指定に関わらず半角カナを送りつけてくるのではないか」といった議論が巻き起こります。
第6週：患者が結婚して改姓しました。しかし、昨年発行された検査結果には旧姓が表示されています。今や名前に有効期間を設定し、どれが現在の名前かを示すフラグが必要になりました。2つのカラム/列だったものが、ひとつの独立したテーブルになります。
第9週：保険。患者の識別子は単一の番号ではないことが判明します。「保険者番号」に「記号」「番号」「枝番」、さらに各種公費負担医療制度の番号、病院独自の「患者ID」、そして普及が進む「マイナ保険証」の照合情報。しかも、同じ人物でも医療機関ごとに識別子が異なるため、今度は「名寄せ」が必要になります。最初のid列は、名前空間（namespace）を持つ複雑な識別子システムへと変貌を遂げました。
第14週：クリニックの医師が、自院の患者として受診しました。usersテーブルとpatientsテーブルの間で、この人物の名前をどちらで管理すべきかについて、2日間も議論が続いています。
第20週：アレルギー。「ペニシリン」という1単語では済みません：誰が記録したか、いつ記録されたか、その信頼度はどの程度か、アレルギーなのか不耐性なのか、医師の観察か家族からの申告か、そして現在も有効（アクティブ）なのか。1つの文字列フィールドが8つに増殖します。
第26週：検査結果。数値だけでは結果とは言えません。数値に加え、単位、基準範囲、JLAC10コード、検体、採取日時（報告日時とは異なります）、依頼医師、そしてステータスが必要です。なぜなら検査結果は修正や訂正が行われ、場合によっては取り消されることもあるからです。
そして、ここが肝心なところです。
26週目になって、一旦立ち止まり、自分が構築したスキーマを見直してみると、Patient.identifier、HumanName.period、AllergyIntolerance.verificationStatus、そしてObservationを独自に考案していたことに気づくのです。
ただし、皆さんが作ったそれらにはドキュメントもテストデータもバリデータもライブラリのサポートもありません。世界中でその仕様を理解できる人間は誰一人おらず、notesという列が、3つの異なる機能によって密かになんでも突っ込む「ごみ箱」として使われています。
医療データは、本質的に、どう足掻いても複雑なものです。「誰が」「いつ」「誰に対して」「どの程度の確信度で」「どのような文脈で」「何を上書きして」「どのコーディング体系で表現したか」といった多角的な属性を本質的に備えているからです。
FHIRは、理想化されたシステムを描いた夢物語ではありません。FHIRとは、皆さんのスキーマが3年後にどのような姿になるかを、同じ過ちを散々経験してきた何百人ものエンジニアたちが事前に書き残してくれた「未来の設計図」なのです。
第1週目に必死で守ろうとした「シンプルさ」は、第26週目の現実の壁を前にして木っ端微塵になります。唯一の問題は、行き着く先の複雑さが、文書化され共有された標準（FHIR）になるのか、それともブラックボックス化した「秘伝のタレ」になるのか、それだけです。
「車輪の再発明」だけでも十分に筋が悪いですが、「少し歪んだ車輪」を再発明してしまうのは、さらに最悪です。
たった5%使うだけで十分
ここが、誰も教えてくれない部分ですが、このブログ記事の中で最も役立つ情報です。
FHIRの恩恵を受けるために、FHIRを完全理解している必要はありません。
誰もが恐れる「学習曲線」とは、完全準拠（フルコンプライアンス）に至るまでの曲線のことです。Profile、Terminology Server、CapabilityStatement、Validation Pipeline、そして一連の「作法」すべてが含まれます。その曲線は確かに存在します。しかし、開発初日からその壁を登り切る必要がある人なんて、ほとんどいません。「完璧に準拠しなければならない」と思い込むことこそが、開発チームが標準規格から完全に離脱してしまう最大の原因なのです。
FHIRの最小限で最も実用的な活用法（Minimum Viable Use）は、これだけです：「患者記録にはどのようなフィールドを含めるべきか」という問いに対する答えとして使うことです。
まずJP CoreのPatient Profile を開いてください。これをチェックリストとして読み進めるのです。そこには、フリガナ表記が必要であること、識別子（Identifier）には定義されたネームスペース（namespace）を持つさまざまな種類があること、「gender」と「性別」は同じ文脈で扱ってはいけないこと、日本の住所には独自の形式があることなどが記載されています。
その後、PostgresやDynamoDB、Railsモデル、あるいはスプレッドシートにて実装すればいいのです。誰も取り締まったりしません。FHIR警察なんて存在しないのですから（残念ながら、あなたのオフィスに標準化警察がガサ入れに踏み込んでくることはありません）。
たった半日の読書と引き換えに得られるのは、世界20カ国にわたるあらゆるエッジケースを経験してきた先人たちが設計したデータモデルです。もし後日、本格的なFHIR APIを公開することになったとしても、フィールド構成がすでに一致しているため、作業の80％は完了しているも同然です。たとえ公開しなかったとしても、自分で一から設計するよりも遥かに優れたスキーマをリリースできたことになります。
「とりあえずビール」という言葉がありますね。今回の場合は、「とりあえず Patient」です。まずは1つのResourceを注文して、様子を見て、必要なら後で追加注文しましょう。
専門用語を分かりやすく解説
FHIRは、実質的な内容に対して専門用語の比率が異常に高く、そのことが実際の難易度以上に、多くの優秀なエンジニアを遠ざけてしまっているように感じます。そこで、難しそうな専門用語の壁をここで取り払ってみましょう。
FHIRサーバーとは、REST APIを備えたJSONドキュメントストアのことです。 これは初心者向けに単純化した説明ではなく、真実そのものです。
GET /Patient/123 を実行すると、JSONドキュメントが返り、POST /Observation を実行すれば新たなレコードが作成されます。
GET /Observation?patient=123&code=http://loinc.org|718-7 はただのクエリ文字列です。
何が画期的かというと、技術そのものではなく、JSONの形式やクエリパラメータの名称がすでに誰かによって決定されているという点です。だからこそ、皆さんが書いたクライアントプログラムは、Epic（米国の電子カルテ）や日本のベンダーのEHRに対しても、さらには自社のサーバーに対しても、コードを1行も書き換えることなくそのまま動作するのです。
専門用語を1つずつ解体してみましょう。
Resourceとは、resourceTypeフィールドを持つJSONドキュメントのことです。Referenceとは、たまたま文字列の形をした外部キー（Foreign Key）のことです：{"reference": "Patient/123"}。Bundleはラッパー付きの配列（Array）です。一度に複数データをまとめて送信することができます。Profileとは、バリデーション（検証）ルールの定義セットです。いわば、医療用語版のJSON Schemaと言えます。Implementation Guide（IG）とは、多数のProfileから自動生成されたドキュメントサイトのことです。JP CoreもIGの一つです。CapabilityStatement/.well-knownのようなもので、システムが対応している機能を機械可読な形式で示すドキュメントです。
そして、SMART on FHIRはOAuth 2.0です。 それ以上でもそれ以下でもありません。本当にそれだけなのです。誰もが独自にスコープ名を定義する代わりに、統一された語彙（各自で勝手に命名するのではなくpatient/Observation.read のような定義）を標準化し、さらに「起動コンテキスト」を足したOAuth 2.0 に過ぎません。これにより、臨床医が EHR 内からアプリを起動した際、アクセストークンには画面に表示されている患者の情報が最初から紐づいた状態で届くのです。もし「Googleでログイン」の連携経験があれば、SMART on FHIRの難しい部分はすでにクリアしています。正直なところ、SMART on FHIRで最も難しいのはその名前です。これは「Substitutable Medical Applications, Reusable Technologies（代替可能な医療アプリケーション、再利用可能な技術）」の略ですが、あまりにも無理やりなバックロニム（後付けの頭字語）なので、それだけで大喜利のネタになるほどです。
専門用語というメッキを剥がしてしまえば、使われている技術スタックはJSON、HTTP、OAuthだけです。どれも皆さんすでに知っているものばかりですよね。
FHIRが新たにもたらしたもの、それは合意です。医療分野のシステム統合において真にコストがかかるのは、技術ではなく、この「合意」を生み出すことなのです。
今すぐこれを行うべき本当の理由：
AIにはあなたの「秘伝のタレ」を読み取れないから
現代のAIと本格的に向き合った経験がある方なら、次に述べる内容にはすでに納得されているでしょう。逆に経験がなければ、どんなブログ記事を読んでも納得することはできないでしょう。
医療は、間違いなくこれらのモデルによって変革されます。それは「いつか遠い未来に」ではなく、この記事を読んでいる皆さん全員の現役時代のうちに起こることです。
これまでスクリーニングの対象にすらならなかったがん患者に対する臨床試験（治験）のマッチング。患者家族が何年もかけ、十数人の専門医をたらい回しにされてようやく病名に辿り着くような希少疾患の診断。日本の「指定難病」問題はまさに「干し草の山から針を探す」ような課題ですが、これこそがAIモデルの最も得意とする分野です。創薬、タンパク質構造、画像診断、敗血症の早期警告。そして医師に「自分の夕べの時間」を取り戻させる自動カルテ作成機能 ――これは「医師の働き方改革」によって医師の労働時間が国家レベルの政策課題となっている日本において、特に大きな意味を持ちます。
しかし、モデルの性能は、そこに読み込ませるデータの質で決まります。ここで標準化をめぐる議論は単なる「思想や理念」から「エンジニアリング上の厳格な制約」へと変化するのです。
患者の病歴に基づいて推論を行うAIシステムは、KENSA_KEKKA_3がHbA1cであることを、その値がIFCC mmol/molではなくNGSPパーセントで保持されていることを、基準値範囲が検査機関ごとに異なることを、そして2019年の検査結果は後に訂正されたものであることまで理解しておく必要があります。もしその知識が、20年前のベンダーによる怪しい列の命名規則や、来年定年退職を迎える情報システム部門のベテラン社員の頭の中にしか存在しないとしたらどうでしょう？あなたの組織内のあらゆる AI プロジェクトは 始めるたびに6 ヶ月間の「発掘調査（考古学）」から着手することになり、次の病院ではまたゼロからやり直す羽目になります。
一方、もしその知識がコード化されたFHIRのObservation Resourceとして格納されていれば、モデルはデータ構造、出所（Provenance）、単位を追加コストゼロで理解でき、病院Aで開発した仕組みをそのまま病院Bへ引き継ぐことができるのです。
もうひとつ、より直接的で、まだ十分に評価されていない大きな効果があります。
それは、来月のスプリントベロシティ（開発速度）にそのまま直結する効果です。
現代のLLMはすでにFHIRを完全にマスターしています。 仕様書、数百ものImplementation Guide（実装ガイド）、HAPI FHIR、Medplum、数千ものオープンソースリポジトリ、長年にわたるZulipコミュニティでの議論――これらすべてが学習データに含まれているからです。Claudeに、「有効なMedicationRequestを生成して」「検索用Bundleをページネーションで取得するクライアントコードを書いて」「HL7 v2のOBXセグメントをObservationにマッピングして」と指示してみてください。すでに100万件もの実例を学習しているため、即座に正確なコードを出力してくれます。
では次に、T_KANJA_MST テーブルに対して、KJ_CD1 から KJ_CD9 までの列を含むコードを記述するよう指示してみてください。絶対に不可能です。AIの学習データには、皆さんの独自スキーマに一致する例がまったく存在せず、今後も決して存在し得ないからです。どのプロンプトにもデータディクショナリ全体を文脈（コンテキスト）として含めなければならず、それでもモデルは推測でコードを書くしかありません。
これは標準規格を導入するための真に新しい論点であり、ほんの3年前には存在しなかった視点です。
標準とは、あらかじめ定義された構成要素（ガンプラのランナーを切り離してそのまま組み上げられるパーツ）です。そしてAIによる生産性向上効果（レバレッジ）は、独自に作った構成要素よりも、こうした共有された構成要素に対して遥かに強力に作用します。
標準Resourceを活用して開発を行っているチームは、独自スキーマを使っているチームには到底得られないほどの圧倒的な生産性向上を実現しています。そして、その差はさらに拡大しています。
「標準化を怠ったこと」から学ぶ130年前の教訓
日本に対して、規格（標準化）の価値について説教する必要などありません。ここはJIS（日本産業規格）、かんばん、ポカヨケ、そして「7分間の奇跡」の国です。新幹線清掃チームは、作業工程のあらゆるインターフェースが秒単位で定義されているため、16両編成の列車をわずか7分で完璧に清掃・リセットすることができます。競争優位性としての標準化は、日本では海外から持ち込まれた輸入品ではなく、むしろこの国の特産品だと言っても過言ではないのです。
だからこそ、この失敗例は極めて示唆に富んでいます。1890年代、東京電灯は50Hzで動作するドイツのAEG社製の発電機を購入しました。一方、大阪は60Hzで動作するアメリカのGE社製の発電機を購入しました。これらはどちらも、それぞれの地域で自らの状況を最適化しようとした人々が、個別に下した極めて合理的で賢明な判断でした。
それ以来、日本の電力網は二分された状態が続いています。2011年の東日本大震災の際、東日本の電力網が喉から手が出るほど電力を必要としていたにもかかわらず、西日本から境界線を越えて送電できたのはわずか数ギガワットにとどまりました。両系統間の周波数変換には、専用の「周波数変換所」を経由しなければならなかったからです。130年が経過した今もなお、まったく妥当と思われた決断の代償を、エンジニアたちは払い続けているのです。
独自に作った医療データモデルは、まさに「周波数変換所」そのものです。
こうしたモデルを1つ構築するたびに、将来のあらゆるシステム連携に対して恒久的な「課税（コスト）」が生じることになります。その代償は、最悪のタイミングで突きつけられます。例えば、緊急事態の渦中や、全国展開の真っ只中、あるいは他社がすでに導入している最新AI機能に、自分たちのシステムだけが接続できないと判明したまさにその瞬間に。
では、「JP Core」とは一体何なのでしょうか？
JP Coreは、米国のUS CoreやオーストラリアのAU Coreに相当する、FHIRにおける日本のナショナルベースプロファイル（標準プロファイル）です。これはFHIR R4（4.0.1）をベースにしており、国際規格のResourceを「日本の患者データ」として実際に機能するように調整したものです。
開発元： JP Core は、日本医療情報学会（JAMI）の NeXEHRS 課題研究会内に設置された「FHIR日本実装検討WG（FHIR Japan Implementation Working Group）」によって開発されました。同ワーキンググループは東京大学の大江和彦教授が議長を務めており、開発資金の一部には政府の助成が充てられています。仕様はjpfhir.jpで公開されており、関連仕様書はstd.jpfhir.jpにインデックス化されています。現在公開されている最新バージョンは1.2.0であり、2026年半ば現在、1.3.0が開発中となっています。
現状のステータスについては、包み隠さずオープンにしておく価値があります。このガイド自体には、日本HL7協会による正式な承認を受けておらず、利用は自己責任で行うものであるという注意書きが記載されています。しかし、これは警告ではなく、“まだ開発の初期段階にある”ことを示すサインとして捉えてください。初期段階だからこそ、私たちのフィードバックや影響力が反映されやすいのです。
なぜJP Coreが必要なのか： 国際標準のFHIRは、日本医療の現実を知りません。例えば、以下のような点について国際仕様は何の定義も持っていないのです。
- フリガナ表記（かな表記）： JP Core では、ISO 21090 の表現
ExtensionであるSYLを使用して、漢字表記の横にフリガナを表示する方法を定義しています。さらに、全国の病院の受付が当然のように求めてくる「フリガナでのソート」を実現するための専用検索パラメータも用意されています。 - 保険識別子： JP Core では、保険者番号（8桁、先頭に0を付加）に記号、番号、枝番を組み合わせた識別子体系や、各種公費負担医療制度向けの体系が定義されています。これはまさに、先ほど取り上げた「第9週の問題」がすでに解決されていることを意味します。
- 日本のコード体系：検査用のJLAC10、医薬品用のYJコードおよびHOT番号、疾患用のMEDIS病名コード、MERIT-9、処置用のSTEM7、さらには歯科や内視鏡検査用の用語集などです。国際仕様ではLOINC、RxNorm、SNOMEDが前提となっていますが、JP Coreはこれらの
Resourceを、日本の現場システムが実際に生成するデータに紐づけしてくれています。 - 日本の住所、日付、およびテキスト： 永遠の議論の的となる「和暦／西暦」の問題も含まれます。FHIRでは単に
ISO 8601形式への準拠が義務付けられているため、西暦から令和への変換は、既存の多くのシステムのように19カ所で別々に処理するのではなく、境界部分でたった一度だけ行うだけで済みます。
これらの Profile は、皆さんが期待する領域を網羅しています。
- 管理（
JP_Patient,JP_Practitioner,JP_Organization,JP_Encounter） - 処方・投薬（
Medication関連） - 診断（
JP_Observation, DiagnosticReport, ImagingStudy, Specimen） - 臨床（
Condition,AllergyIntolerance,Procedure,Immunization）
“JP Coreは主に学術的な取り組みに過ぎない”と聞いたことがあるかもしれません。つい最近までは、その見方は妥当でした。しかし、今はもう違います。その理由は次のセクションでお話ししましょう。
そして、その産業用モデル：JP-CLINS
「電子カルテ情報共有サービス」は、日本の「医療DX」プログラムの一環として、これまで述べてきたすべてを単なる「研究課題」から「具体的な実施期限のあるプロジェクト」へと一気に変貌させる存在です。これは、社会保険診療報酬支払基金が「全国医療情報プラットフォーム」の一環として運営しており、2025年から段階的な運用を開始し、2026年度冬頃を目処に本格運用を開始する予定です。
その範囲は「3文書6情報」です：
- 3つの書類： 診療情報提供書（紹介状）、退院時サマリー、健診結果報告書
- 6つの情報：傷病名、薬剤アレルギー等、その他アレルギー等、感染症、検査 (救急・生活習慣病)、処方情報
これに関するFHIR仕様が、jpfhir.jp/fhir/clinsで公開されているJP-CLINS（CLinical Information Sharing）であり、現在のバージョンはv1.11前後です。アーキテクチャの観点から最も注目すべき点は、JP-CLINSが派生IG（Implementation Guide）であるという点です。これはJP Core v1.1.xを基盤として構築されており、JP_Patient_eCS、 JP_Observation_LabResult_eCS、および5つの情報項目を1つの Bundleとして送信するための JP_Bundle_CLINS といった Profile が追加されています。対象は「2文書5情報」に加え、「患者サマリー」が含まれ、健診結果報告書は別の経路で送信されます。
これこそが、国家標準を機能させるための階層構造であり、しっかりと理解しておく価値のあるポイントです。国際FHIR → JP Core → JP-CLINS → あなたのアプリケーション
それぞれの層は、その上の層に対して制約を加えていく構造になっています。したがって、標準のPatientを学べば、JP_Patientの大部分を理解したことになり、それはそのままJP_Patient_eCSの大部分もすでに理解したことになります。皆さんの知識と学習の成果は毎回リセットされるのではなく、複利のように積み重なっていくのです。
国が進める「電子処方箋」サービスも、まったく同じ基盤の上に構築されています。
そして、アーキテクチャの議論を一瞬で終わらせる“経済的インセンティブ”がついに登場しました。2026年からは、電子カルテ情報共有サービスへの接続に対して“診療報酬の加算”が適用されます。この加算が報酬基準に盛り込まれれば、「標準化は後回しにしよう」という考えは、単なる技術的な見解ではなく、直ちに予算上の項目（優先課題）となるのです。
今後の計画を立てる上で極めて重要な背景情報を、もう一点補足しておきましょう。
日本は決してゼロからスタートするわけではありません。HL7 v2.5メッセージに基づいて構築され、JAMIの下で維持管理されている標準化ストレージ仕様SS-MIX2は、10年以上もの間、国内の多くの病院で導入されており、MID-NETのような二次利用の取り組みを支えています。この導入実績は極めて堅牢であり、この10年間で消えてなくなるようなものではありません。したがって今後数年間にわたるほとんどの日本国内の病院における実用的なアーキテクチャは、基盤にHL7 v2.5とSS-MIX2、エッジ（外部接続部）にFHIR、その間にアダプタを配置した形となるでしょう。「SS-MIX2を撤去して純粋なFHIRに移行すべきだ」と言う人は、日本の病院の電算室に足を踏み入れたことが一度もない人です。
今週、実際に始める方法
6ヶ月間もかけた「検討・評価プロセス」なんてスキップしましょう。ここに、本当に小さな最初の1歩があります。四半期（3ヶ月）単位の計画ではなく、たった半日で終わるステップです。
- まず、1つの
Profileをサッと覗いてみましょう。 JP CoreのPatient Profile を開いて、フィールドがどのように構成されているかを確認するだけで十分です。フリガナがnameにどのように紐づいているか、識別子が独自のシステムURLを伴って保険者番号をどう保持しているか、何が必須で何が任意項目なのか。これは試験勉強ではありません。皆さんがすでに抱えている課題に対する、「誰かが作った解答集」を見ているだけなのです。 - 次に、JP Coreのサンドボックスを開きます。 弊社（Keta）では、medplum-jp-core.keta.nycでサンドボックスを公開しています。「Anonymous Login（匿名ログイン）」をクリックするだけで、JP Coreの
Profileや用語集があらかじめ読み込まれ、日本の患者のサンプルデータが初期設定された使い捨てのMedplumオープンソースFHIRサーバーが利用可能になります。インストールも登録も、Dockerもクレジットカードも一切不要です。URLをブックマークしておけば、明日も同じ環境にそのままアクセスできます。 - そして実際のデータ1件を往復処理してみましょう。 自社システムから患者データ1人分を抽出し、それを
JP_Patientにマッピングして、サンドボックスにPOSTします。サーバー側でProfileに対する検証を実行させ、そのレスポンス（結果）を読み戻します。続いて、1件の検査結果データでもObservationとして同じ手順を行ってみます。この1件のデータ連携で直面した課題こそが、プロジェクト全体の正確な見積もり範囲となります。どんな分厚いスプレッドシートよりも価値のあるこの情報こそが、その日の終わりには手に入るのです。 - アーキテクチャについての議論は、そのステップを終えてから始めましょう。 実際に動作し、検証済みの
Resourceが手元にあれば、稟議書は勝手に書けてしまうようなものなのですから。
Ketaがお手伝いできること
Ketaでは、FHIRや、現在もなお広く活用されているその前身規格HL7 v2といった医療標準規格に基づいて、アプリケーションの設計・開発を行っています。当社は長年にわたり、米国のお客様向けに、EHRおよびEMRの統合、SMART on FHIR アプリ、HL7 v2 インターフェースエンジン、HIPAA準拠のアーキテクチャ、そしてAIによる臨床ワークフローの自動化に取り組んできました。米国はこの分野において日本より数年先行しており、高コストになりがちな失敗を一通り経験済みです。
私たちは現在、その豊富な知見を日本市場へ展開しています。特に先ほど触れた「ハイブリッドな現実」――内部にはSS-MIX2とHL7 v2、境界（外部連携部）にはJP CoreとJP-CLINS、そしてその上で動作するAI――というアーキテクチャに強い関心を寄せています。
「電子カルテ情報共有サービス」の期限対応にお悩みの方、自社のAI製品を日本の電子カルテと連携させたい方、あるいは「FHIRを学ぶ価値があるのか」という議論を社内で交わしている方、ぜひ一度、私たちとお話ししてみませんか？
お気軽にご相談ください。
最後に、この記事からたった1つだけ持ち帰っていただくとしたら：
どのような道を辿ろうとも、皆さんのスキーマは最終的にFHIRと同じくらい複雑なものになります。違いはただ1つ、「その構造を、世界中の他のエンジニアたちが理解できる形にするかどうか」、それを皆さんが選べるということだけなのです。
コメントを残す