Skip to main content

データ交換標準を確認する

学習の目的

この単元を完了すると、次のことができるようになります。

  • 相互運用性における API の役割を説明する。
  • HL7v2 および FHIR R4 標準の目的を説明する。

ますます分散するヘルスケアシステムをシームレスに機能させるためには、EHR でデータを共有する必要があり、そのために相互運用可能なシステムが必要になります。Health Cloud の相互運用可能なシステムではアプリケーションプログラミングインターフェース (API) を利用しています。

相互運用性における API

アプリケーションプログラミングインターフェースは、アプリケーションが互いにやりとりできるようにするコンピューティングインターフェースです。ビジネス機能の標準ビルディングブロックであると考えられている API は、データを安全に公開する再利用可能なユニットです。API では抽象化レイヤーを作成してプログラミングを簡略化し、ソフトウェアシステムの基礎部分の複雑さを見えなくすることができます。API を使用すると、開発者は複雑なソースコードを作成したり、各システムの内部のしくみを理解したりせずに、ソフトウェアシステムを接続できます。簡単に言えば、API はソフトウェアシステムのメッセンジャーです。

データ交換を行うには、この API エンゲージメントレイヤーが必要です。ただし、相互運用性を促進するには、もう少し進んで API を利用する必要があります。継続的に注目され、投資されている領域が 3 つあります。オープン API、オーケストレーションサービス、標準の採用です。それぞれを見ていきましょう。

オープン API

相互運用可能環境では、組織はデータを安全に送信する必要があります。この目的のために、組織はエンタープライズ規模の API 管理システムを構築しなければなりません。たとえば、Salesforce では REST、SOAP、Bulk、Streaming などよく使用される API と、同期または非同期フローをサポートする API 対応の項目がサポートされています。オープン API により、データ交換に使用されるエンドポイントは安全に保たれます。 

オーケストレーションサービス

再利用性も相互運用性を実現するうえで重要な要素です。ポイントツーポイントのインテグレーションから、API を使用してデータ、デバイス、アプリケーションを統合するオーケストレーションサービスによってエンタープライズ規模の再利用性に移行する必要があります。統合されたデータが、ビジネスで所有・管理するアプリケーションで使用できるようになり、エンドユーザーがビジネスに近くなります。

標準の採用

オープン API とオーケストレーションサービスで相互運用性は促進されますが、これには業界標準が採用されている必要があります。Cures Act Rule と Interoperability & Patient Access ルールはどちらも健康データを交換し、患者が自分自身の健康情報にアクセスできるようにするための相互運用性を重視しています。さらに両方とも Health Level 7® (HL7) と Fast Healthcare Interoperability Resources® リリース 4.0.1 (FHIR R4) を、データ交換を可能にする基盤の標準として認めています。Cures Act Rule では United States Core Data for Interoperability (USCDI: 相互運用性のための米国コアデータ) 標準も採用に必須の標準として認めています。HL7、FHIR、および USCDI 標準は共に臨床データと患者データを統合することで相互運用性を促進することを目的としています。確実に標準が採用されると、データインテグレーションの向上や相互運用可能なシステムの増加につながります。

HL7 および FHIR 標準を知る

相互運用性に標準は不可欠です。HL7 と FHIR はヘルスケアアプリケーションが相互の通信に使用する標準です。

Health Level Seven International は、ソフトウェアアプリケーション間で臨床データと管理データを転送するための業界全体の標準を作成する非営利団体です。この団体で 2 つの標準 (HL7 と FHIR) が作成されました。明確化のために、このモジュールでは説明で言及する「HL7」は標準を指します。団体を指す場合は Health Level Seven International を使用します。

HL7 標準

HL7 には独自の用語のセットと、文章を構造化するための特定のルールがあります。さまざまなバージョンもあります。HL7v2 は Health Level Seven International の最もよく使用されている情報交換標準です。HL7 では、再利用可能なセグメントを含むメッセージを使用してシステム間で健康情報を伝えます。HL7 メッセージに定義されていないデータは、z セグメントと呼ばれるローカルで定義されたメッセージセグメント経由で追加でき、標準 HL7 メッセージの任意の場所に配置できます。

ただし、バージョンが異なる HL7 同士では通信できません。病院 A では HL7v2、病院 B では HL7v3 を使用している場合、この 2 つの病院は互いとの通信ができません。HL7v3 と非互換であっても、HL7v2 は非常に柔軟であるため広く使用されています。HL7v2 には HL7v2.1、HL7v2.3 ～ HL7v2.6 まで複数のバージョンがあり、それぞれ後方互換性があります。ただし、HL7v2 バージョンはそれより前の HL7v2 バージョンに対してのみ互換性があることに注意してください。たとえば、HL7v2.4 には HL7v2.3 に対する後方互換性がありますが、HL7v2.3 には HL7v2.6 に対する前方互換性はありません。

HL7v2 メッセージとはどのようなものでしょうか? サンプルメッセージを見てみましょう。

MSH |^~\& | EPIC | EPICADT | REG | REGADT | 201410011301 | SEC | ADT^A01 | 187 | P | 2 .2 | PID | | 0123456^^^2^ | 0123456 | | JONSON^MARK^^^^ | | 19651225 |M| |B| 123 FAKE ST^^SPRINGFIELD^OR^97878^USA| | (503) 123-4567 | | | M | NON | 403403 | NK1 | | JONSON^ELLE^^^^ |ABC| | (503) 123-4567 | | EC | | | | | | | | | | | | | | | | | | | | | | | | | | | PV1 | | I | 312-B^^ | | | | 02^JONSON^ELLE^^^^ | | | | | | | | | | |

| 2688684 | | | | | | | | | | | | | | | | | | | | | | | | | 201410011301 | | | | | | 0123553

メッセージ内に MSH、PV1、^ などさまざまな短縮語があるのがわかりますか? これらは特定の意味を持つ特殊文字です。

  • MSH は各 HL7 メッセージの開始を示します。
  • PV1 はメッセージが Patient Visit (患者の訪問) イベントに関するものであることを意味します。
  • ADT は、Admit (入院)、Discharge (退院)、Transfer (転院) イベントを示します。
  • | は、メッセージをセグメントに分割する特殊文字です。
  • ^ は、セグメント内の情報を下位部分に分割する特殊文字です。

相互運用可能システムで使用されている標準は HL7 だけではありません。FHIR もあります。

FHIR 標準

Health Level Seven International によって作成された FHIR は、臨床データと管理データを EHR などのソフトウェアアプリケーション間で交換できるようにする API 標準です。Health Level Seven International の最新リリースは FHIR v4.0.1 で、次の理由から非常に人気があり、広く使用されています。

  • FHIR R4 の多くのリソースは規範的段階に達しています。つまり、リソースの開発は完了しており、今後、大幅に変更されることはありません。そのため、FHIR R4 は業界で実装できます。また、安定した状態が保たれると期待できます。
  • FHIR R4 には下位互換性があります。そのため、以前のバージョンの FHIR を使用するシステムと円滑にデータを交換できます。
  • HL7v2 と同様に、FHIR R4 はイベントベースのメッセージングパラダイムをサポートします。一方で HL7v2 とは異なり、REST ドキュメントなどの他のパラダイムや他のサービスモデルもサポートします。
  • HL7 では電子データ交換 (EDI) という複雑なファイル形式を使用するのに対し、FHIR R4 では EDI より簡潔な REST API を使用します。詳細は、Trailhead で「Lightning プラットフォーム API の基本」モジュールの「REST API の使用」を参照してください。

FHIR の基本的なビルディングブロックであるリソースは、保存や健康カルテシステム間での交換が可能なデータが含まれるエンティティです。リソース種別には、臨床、管理、財務があり、それぞれにサブ種別があります。

リソースは次のコンポーネントで構成されます。

  1. 構造化データ型のセット。要素の再利用可能なパターンを含みます。
  2. 識別可能なアドレス (URL)。このアドレスは、どこでアクセスできるかを示す可動位置 URL か、リソースに含まれる固有かつ固定の識別子である正規 URL になります。
  3. メタデータ。技術的コンテキストとワークフローコンテキストをリソースに提供します。ほとんどは省略可能です。
  4. 識別可能な FHIR バージョン。標準はこのバージョンに対して記述されています。この FHIR バージョンが変わると、リソースの内容も変わります。
  5. リソースの概要が含まれる人間が判読可能な部分。

以下は Patient-example-mom リソースの例です。データ型 (id) には人間が判読可能な概要 (mom)、メタデータ (ここでは空)、URL (リンク) があり、識別可能な FHIR バージョン (v4.0.1) を参照しています。

id: mom

meta:

identifier: Social Security number = 444222222

active: true

name: Eve Everywoman (OFFICIAL)

telecom: ph: 555-555-2003(WORK)

gender: female

birthDate: 31/05/1973

address: 2222 Home Street (HOME)

managingOrganization: Organization/hl7

Links

-

Other

Type

*

RelatedPerson/newborn-mom

seealso

次の単元では、FHIR R4 に従った Health Cloud 臨床データモデルについて説明します。

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む