52
1 1 SS-MIX2の基礎と応用事例のご紹介 2016年11月21日 日本電気株式会社 佐々木 文夫 チュートリアル6 SS-MIX2初級編

SS-MIX2の基礎と応用事例のご紹介Ÿº礎と応用事例のご紹介.pdf · 1 1 ss-mix2の基礎と応用事例のご紹介 2016年11月21日 日本電気株式会社 佐々木

  • Upload
    others

  • View
    8

  • Download
    0

Embed Size (px)

Citation preview

1 1

SS-MIX2の基礎と応用事例のご紹介

2016年11月21日

日本電気株式会社

佐々木 文夫

チュートリアル6 SS-MIX2初級編

2

目次

0.はじめに

1. SS-MIXとは何か

2. SS-MIXの基礎

3. SS-MIXの応用例

4. 課題と展望

2

3

0.はじめに

本日の内容を一言でまとめると

3

SS-MIX2(あるいはSS-MIX)は

医療施設の診療情報を、標準的な形式で 蓄積するためのルール

である。

4

1.SS-MIXとは何か SS-MIXはここから始まった(静岡県版電子カルテ)

H15~H16年度 静岡県の事業として「静岡県版電子カルテ」が開発された。

HISから出力された標準的なデータを蓄積し、各種カルテ部品(紹介状編集等)へデータを受け渡す仕組みとして「標準化ストレージ」が考案されている。

4

保健医療分野の情報化にむけてのグランドデザイン(H13.12.26) H18年度までに400床以上の病院の6割に電子カルテを導入

5

標準化ストレージの物理構造 (詳細は後述します)

DBを採用せず、安価に導入 できることを目指した。

HL7ファイル仕様はVer.2.4を

採用した。

5

6

(その後の経緯)

厚生労働省電子的診療情報交換推進事業 Standardized Structured Medical Information eXchange

標準化ストレージに着目した厚生労働省が、医療機関が標準的な情報を蓄積・交換することにより、医療の質を高めることを目的としてシステム開発を静岡県に委託 (医政局 H18年度事業)

正確にはSS-MIXは事業名であり、規格名ではない (規格としてHL7、DICOMを採用している)

SS-MIX2 Ver.0.96 SS-MIX標準化ストレージはHL7 Ver.2.4準拠だったが、JAHIS標準類がVer.2.5に

統一されたため、2つの規格の混在が利用者の混乱を招く可能性があった。

そのため総務省事業や厚生労働省事業の中で、標準化ストレージ仕様を HL7 Ver.2.5準拠に見直した。

この成果をJAMI標準策定・維持管理部会で整備し、H24年度末に SS-MIX2 Ver.0.96 として公開した。

なぜVer.0.96? 標準用法マスタの公開時にVer.1.0にする予定だった。 6

7

SS-MIX Ver1.2C 標準化ストレージが普及するにつれてPMDAの医療情報データベース基盤事業

(日本版センチネル)など、データの二次利用を目的とする事例が出てきた。

従来の「情報の表示」ではあまり問題にならなかった、各社間の「HL7表記のゆらぎ」が指摘されたため、HL7表記の明確化を行いH26年12月にVer1.2として公開された。

その後、軽微な修正を行い、本日時点ではVer.1.2Cが最新。 JAMIの下記サイトから規格書を入手できる。 http://www.jami.jp/jamistd/ssmix2.html

SS-MIX2はH28年2月に厚生労働省標準規格として認定されている。

SS-MIX2 標準化ストレージ 仕様書 Ver.1.2c

SS-MIX2 標準化ストレージ 仕様書 Ver.1.2c_コード表

SS-MIX2 標準化ストレージ 構成の説明と構築ガイドライン Ver.1.2c

SS-MIX2 拡張ストレージ構成の説明と構築ガイドライン Ver.1.2c

Ver.1.2の採番理由は4つの仕様書バージョンを統一するため (標準化ストレージ 構成の説明と構築ガイドライン Ver1.0が既存だった)

7

(その後の経緯)

8

標準化ストレージ導入状況

8

SS-MIX、SS-MIX2導入施設数 996施設(2015年時点 844施設) 内)処方、検体検査まで蓄積 630施設( 〃 518施設)

2016年3月末時点 SS-MIX普及推進コンソーシアム調べ

9

9

2.SS-MIX2の基礎

4種類のストレージが定義されている

標準化ストレージ

HL7メッセージなど標準化された情報

を格納

拡張ストレージ

XMLやDOC、 PDF、画像、音声

などを格納

・患者基本(病名を含む) ・入退院・食事 ・処方・注射 ・検体検査 ・放射線検査 ・内視鏡検査 ・生理検査

• 画像 • 退院時サマリ • 看護記録 • 読影レポート • 紹介状 • 麻酔記録 等々

SS-MIX2ではこれらの情報を、どのように 格納、蓄積するかを定めている

トランザクション

ストレージ

HL7メッセージの

Logに相当するデータ

インデックス データベース

標準化ストレージ、 拡張ストレージの 検索用インデックス

10 10

まずHL7(Health Level Seven)とは

SS-MIX2を学ぶためにはHL7の基礎知識が必要です。

HL7はテキスト情報や計測値などの診療情報交換や表記のための標準規約。 1987年から開発が進められ、2009年には ISO/HL7 27931となっている。

米国のHL7 Internationalを中心に標準化活動を推進しており、日本をはじめ、 30以上の国に支部がある。

日本では保健医療福祉情報システム工業会(JAHIS)がHL7 バージョン2.5に 準拠したデータ交換規約を作成している。

HL7 バージョン2.5 規格書の構成

章 内容 章 内容

1 序論 9診療記録/情報管理

(文書管理)

2 コントロール 10 予約

3 患者管理 11 患者紹介

4 オーダ入力 12 患者看護

5 照会 13 臨床検査自動化

6 財務管理 14 アプリケーション管理

7 検査報告 15 人事管理

8 マスターファイル

11 11

HL7メッセージの例(検体検査結果送信)

MSH|^~¥&|||||20071014115956||ORU^R01^ORU_R01|mn768|T|2.5…<cr>

│ │ └→ トリガーイベントコード(R01:検査メッセージの送信)

│ └→ メッセージ型コード(ORU:非要求検査メッセージ送信)

└→ セグメントID(MSH:メッセージヘッダ)

PID :患者識別セグメント

OBR :検査要求セグメント

OBX :検査結果セグメント

OBX||NM|3B035000002327201^GOT^JC10||50|U|6-28 |H||N|F||||LAB<cr>

└ → OBXセグメントの3番目のフィールド。OBX-3と表記される

「|」がフィールドの区切り文字。

MSH|^~¥&|||||20071014115956||ORU^R01^ORU_R01|mn768|T|2.5…<cr> PID|||PID001||OTSUKA^TARO^^^^^L^A~大塚^太郎^^^^^L^I~おおつか^たろう^^^^^L^P||19500523|M <cr> OBR||0523002|123456702^LAB|^生化学肝set^99I01 |||20071011|||||||200710120830|023&血清&JC10| ^佐藤^二郎^^^^^^^L^^^^^I|…<cr> OBX||NM|3B035000002327201^GOT^JC10||50|U|6-28 |H||N|F||||LAB<cr>

トリガーイベントコードとメッセージ型コードの組み合わせで、このメッセージが何を表すのかがわかる

(Encoding Rule Seven:ER7形式)

12 12

(改めて)標準化ストレージのフォルダ構造

13 13

フォルダの命名規則

①ルートフォルダー 任意の名前でよいが、災害時BCPに利用することを考慮して医療施設IDとする

ことを推奨している。

医療施設ID 都道府県番号(2桁)+機関区分コード(1桁)+機関コード(6桁)+チェックデジット(1桁)

施設内に複数の標準化ストレージがある場合は、医療施設IDに識別子を加える

②患者IDフォルダー 患者IDによって、フォルダ名は自動的に決定される。

③診療日フォルダ 該当の診療情報を作成した(診療行為を行った、もしくは行ったとみなす)日付を、

西暦8桁の数値(YYYYMMDD)で表現する

患者基本・病名・アレルギー等のように、日付の概念がない患者基本情報は 「- (ハイフン)」を用いる。

14 14

③の診療日としてセットする情報(Ver.1.2で明確にされた)

病院情報システム等の仕様等によっては、上記で定めた方針通りに診療日を設定できないことが 考えられる。この場合は、当該施設の実施方針として、別途、診療日として採用する日付を定義し、文書等で明確にしておくとともに、例外事項としてのこのルールを遵守すること。

No メッセージ型 メッセージ名 項目 No メッセージ型 メッセージ名 項目

1 ADT^A08 患者基本情報の更新 - 19 ADT^A25 退院予定の取消 PV2-9(退院予定日)

2 ADT^A23 患者基本情報の削除 - 20 ADT^A03 退院実施 PV1-45(退院日)

3 ADT^A54 担当医の変更 - 21 ADT^A13 退院実施の取消 PV1-45(退院日)

4 ADT^A55 担当医の取消 - 22 ADT^A60 アレルギー情報の登録/更新 -

5 ADT^A04 外来診察の受付 PV1-44(受付日) 23 PPR^ZD1 病名(歴)情報の登録/更新 -

6 ADT^A14 入院予定 PV2-8(入院予定日) 24 OMD^O03 食事オーダ ORC-9 (食事のオーダ日)

7 ADT^A27 入院予定の取消 PV2-8(入院予定日) 25 RDE^011 処方オーダ ORC-9 (処方のオーダ日)

8 ADT^A01 入院実施 PV1-44(入院日) 26 RAS^O17 処方実施通知 RXA-3(服用した日)

9 ADT^A11 入院実施の取消 PV1-44(入院日) 27 RDE^011 注射オーダ ORC-9 (注射のオーダ日)

10 ADT^A21 外出泊実施 EVN-6(外出泊日) 28 RAS^O17 注射実施通知 RXA-3(注射を実施した日)

11 ADT^A52 外出泊実施の取消 EVN-6(外出泊日) 29 OML^O33 検体検査オーダ ORC-9 (検査のオーダ日)

12 ADT^A22 外出泊帰院実施 EVN-6(帰院日) 30 OUL^R22 検体検査結果通知 SPM-17(検体を採取した日)

13 ADT^A53 外出泊帰院実施の取消 PV2-47(帰院日) 31 OMG^O19 放射線検査オーダ ORC-9 (検査のオーダ日)

14 ADT^A15 転科・転棟(転室・転床)予定 PV2-8(転科転棟日) 32 OMI^Z23 放射線検査の実施通知 OBR-7(検査を実施した日)

15 ADT^A26 転科・転棟(転室・転床)予定の取消 PV2-8(転科転棟日) 33 OMG^O19 内視鏡検査オーダ ORC-9 (検査のオーダ日)

16 ADT^A02 転科・転棟(転室・転床)実施 EVN-6(転科転棟日) 34 OMI^Z23 内視鏡検査の実施通知 OBR-7(検査を実施した日)

17 ADT^A12 転科・転棟(転室・転床)実施の取消 EVN-6(転科転棟日) 35 OMG^O19 生理検査オーダ ORC-9 (検査のオーダ日)

18 ADT^A16 退院予定 PV2-9(退院予定日) 36 ORU^R01 生理検査結果通知 OBR-7(検査を実施した日)

15 15

④データ種別フォルダ命名規則

上記のデータ種別全てを要求しているわけではなく、施設毎に必要とするデータを 出力すればよい。

No データ種別 名称 HL7メッセージ型 備考 No データ種別 名称 HL7メッセージ型 備考

1 ADT-00 患者基本情報の更新 ADT^A08 19 ADT-51 退院予定の取消 ADT^A25

2 ADT-00 患者基本情報の削除 ADT^A23 20 ADT-52 退院実施 ADT^A03

3 ADT-01 担当医の変更 ADT^A54 21 ADT-52 退院実施の取消 ADT^A13

4 ADT-01 担当医の取消 ADT^A55 22 ADT-61 アレルギー情報の登録/更新 ADT^A60 追加

5 ADT-12 外来診察の受付 ADT^A04 23 PPR-01 病名(歴)情報の登録/更新 PPR^ZD1 追加

6 ADT-21 入院予定 ADT^A14 24 OMD 食事オーダ OMD^O03

7 ADT-21 入院予定の取消 ADT^A27 25 OMP-01 処方オーダ RDE^O11 変更

8 ADT-22 入院実施 ADT^A01 26 OMP-11 処方実施通知 RAS^O17 追加

9 ADT-22 入院実施の取消 ADT^A11 27 OMP-02 注射オーダ RDE^O11 変更

10 ADT-31 外出泊実施 ADT^A21 28 OMP-12 注射実施通知 RAS^O17 追加

11 ADT-31 外出泊実施の取消 ADT^A52 29 OML-01 検体検査オーダ OML^O33

12 ADT-32 外出泊帰院実施 ADT^A22 30 OML-11 検体検査結果通知 OUL^R22 追加

13 ADT-32 外出泊帰院実施の取消 ADT^A53 31 OMG-01 放射線検査オーダ OMG^O19

14 ADT-41 転科・転棟(転室・転床)予定 ADT^A15 32 OMG-11 放射線検査の実施通知 OMI^Z23 追加

15 ADT-41 転科・転棟(転室・転床)予定の取消 ADT^A26 33 OMG-02 内視鏡検査オーダ OMG^O19 追加

16 ADT-42 転科・転棟(転室・転床)実施 ADT^A02 34 OMG-12 内視鏡検査の実施通知 OMI^Z23 追加

17 ADT-42 転科・転棟(転室・転床)実施の取消 ADT^A12 35 OMG-03 生理検査オーダ OMG^O19 追加

18 ADT-51 退院予定 ADT^A16 36 OMG-13 生理検査結果通知 ORU^R01 追加

備考欄の追加、変更はSS-MIX2で見直したもの

16

No データ種別 内容

1 REF-01 当該医療施設で作成した「紹介状」

2 INF-01 当該医療施設で作成した「電子診療データ」

3 REF-02 他医療施設より受け取った「紹介状」CDの内容

4 INF-02 他医療施設より受け取った「電子診療」CDの内容

5 PDI-01 他医療施設より受け取ったPDI CDの内容

16

④データ種別フォルダ命名規則(続き)

自院で作成、または他施設から受領した標準化された情報

上記に該当するHELICS指針(規約)は厚生労働省標準規格として採用されている HS007 患者診療情報提供書及び電子診療データ提供書(患者への情報提供)

HS008 診療情報提供書(電子紹介状)

HS009 IHE統合プロファイル「可搬型医用画像」およびその運用指針

http://helics.umin.ac.jp/helicsStdList.html

17 17

データ種別フォルダに格納するコンテンツの命名規則

診療日、データ種別はフォルダ命名規則と同じ

発生日時は YYYYMMDDHHMISSFFF(ミリ秒)で表記する

コンディションフラグ

0:無効(論理削除)

1:有効

2:無効(過去履歴)

ファイル名に拡張子はつけない

患者ID_診療日_データ種別_オーダNo_発生日時_診療科コード_コンディションフラグ

18 18

(例)検体検査オーダ依頼

19 19

(例)検査結果報告

20 20

コンテンツの実体

標準化ストレージでは1つのHL7メッセージやCDAファイルが、1ファイルに格納される。

CDA:Crinical Document Architecture R.2(ISO/HL7 27932)で定められたXML文書

HL7メッセージの場合は1ファイルは1オーダとする。 ただし病名のみは1患者に対する全ての病名情報を1ファイルで表現する。

メッセージの文字コードセットは「JIS(JIS X 0208)」で格納することとする。 (JIS X 0208付録書のShift-JISではない)

HL7メッセージ仕様は以下のドキュメントで定めている。

・SS-MIX2 標準化ストレージ 仕様書 Ver.1.2c

・SS-MIX2 標準化ストレージ 仕様書 Ver.1.2c_コード表

21 21

標準化ストレージ仕様書(抜粋) フィールドID フィールド名 LEN DT OPT RP # JAHIS SS-MIX2 説明

OBX-0 セグメントID 3 ST R R R セグメントID「OBX」を設定する。

OBX-1 セットID - OBX 4 SI O O Oセグメントの反復が許されるメッセージにおいて、反復を識別する為のメッセージ内でのシーケンス番号。初期値1、増分1。

OBX-2 値型 2 ID C 0125 R R身長・体重・感染症・血液型などの患者身体情報をOBX-5 に記述するために必要なHL7 データ型を設定する。取りうる値は、HL7 表「0125-値型」を参照。

OBX-3 検査項目 250 CWE R R R

[SS-MIX2]身長・体重・感染症・血液型などの患者身体情報を記述するための項目を特定するコードを設定する。JLAC10コードの使用を推奨する。ex)  9N001000000000001^身長^JC10    9N006000000000001^体重^JC10    5H010000009199911^血液型-ABO 式^JC10

OBX-4 検査副ID 20 ST C C C1 つのOBR の下で編成された複数のOBX セグメントが同じ検査項目ID を持つ場合、それぞれのOBX セグメントを識別するのに使う。

OBX-5 結果値 65536 * C Y C C[SS-MIX2]NM 型、ST 型、SN 型、CWE 型などを使用し、身長・体重・感染症・血液型などの患者身体情報を記述する。

OBX-6 単位 250 CWE O O O

[SS-MIX2]NM 型を使用する場合、単位コードを指定する。取りうる値はISO単位を参照し、コーディングシステム名には「ISO+」を格納する。ex)身長:cm^cm^ISO+体重:kg^kg^ISO+

OBX-7 基準値範囲 60 ST O O N検査で有毒物質の量を計測する場合、範囲の上限により毒性限界を表す。

OBX-8 異常フラグ 5 IS O Y 0078 O N結果の正常状態を示すテーブルルックアップ。所見(正常、異常)フラグに用いる。

OBX-9 確率 5 NM O O N定性値を持つ結果の場合、結果が真である確率(結果が特定のコードとなる確率)。

最大デー

タ長

デー

タ型

R・必須

O・オプシ

ョン

C・選択

繰り返し

コー

ドテー

ブル

番号

JAHISデータ交換規約との 対比を記述している

(主に簡略化を目的として)

22 22

SS-MIX2 Ver.0.96での表記のゆらぎ 時刻の定義 「検査を行った日時は、どの日時?」

• オーダ入力日時

• 検査予定日時

• 採血を行った日時

• 検査部へ検体が到着した日時

• 分析機にかけた日時

• 検査結果報告日時

シナリオを例示し、日時の考え方(セットすべき箇所)を明確にした。

T1(オーダ日時) : ORC-9、ORC-15

T2(検査予定日時) : TQ1-7、OBR-7、OBX-14

T3(検体採取日時) : SPM-17、OBX-14

T4(検体受領日時) : SPM-18

T5(検査実施日時) : OBX-19

T6(検査報告日時) : OBR-22

どのセグメント、フィールドに、どの値をセットするか解釈が曖昧さがあった

(例)検体検査 日時T1 に次の内容の検査をオーダした。「日時T2 に採血検査Xを実施せよ。」 これに対して、日時T3 に採血を行い、T4 に検査室で検体を受領し、日時T5 に検査を実施し、日時T6 に結果報告した。

23 23

SS-MIX2の実装例

HIS側からはSS-MIXヘッダとHL7メッセージを送信する

トランザクションストレージと、インデックスデータベースの作成は必須ではない(任意)

HIS側に実装されたアプリケーションが、直接ストレージサーバに書き込んでもよい。

HL7メッセージ受信アプリはSS-MIX普及推進コンソーシアムから有償で入手が 可能になる予定。(日本IHE協会 コネクタソンの通信プロトコルを使用)

HIS

電子カルテ

オーダエントリ

HL7送信アプリ

ストレージサーバ

HL7受信アプリ

トランザクション ストレージ

標準化ストレージ

拡張ストレージ

インデックス データベース

SS-MIXヘッダ +

HL7メッセージ

RDB

24 24

SS-MIX2ヘッダについて

HISから送信するメッセージ

SS-MIXヘッダには、標準化ストレージのフォルダ名を決定するための情報が含まれている。

No 項目 内容1 SS-MIX識別 固定値「#SSMIX」を設定する。

2 バージョンSS-MIXのバージョンを表す。本仕様においては固定値「2.00」を設定する。

3 医療施設ID

医療施設を一意に識別するID(10桁)

※厚生労働省 特定健診・特定保健指導データのファイルイメージ 参考資料5(p7,8)、ならびにJAHIS基本データセット適用ガイドライン Ver2.1(p4)に基づき都道府県番号(2桁)+機関区分コード(1桁)+機関コード(6桁)+チェックデジット(1桁)の計10桁で構成されるコードを用いることとする。

4 患者ID 医療施設内で患者を一意に識別するためのID

5 診療日 西暦8桁の数値(YYYYMMDD)で表現される診療日

6 データ種別処方、臨床検査等、データを区別するための識別文字

7 オーダNo オーダ(医師の指示)を特定するための識別番号

8 処理区分

新規データか削除データかを識別する文字。「INS」:挿入 「DEL」:削除

HL7メッセージが取り消しメッセージまたは削除オーダメッセージを送信する場合は「DEL」を指定する。

9 診療科コード 診療科(入力組織)コード

10トランザクション日時

日時(YYYYMMDDHHMMSSFFFミリ秒)で表現されたメッセージ発生日時

#SS-MIX,… <EOH> SS-MIXヘッダ

MSH|… <EOM> HL7メッセージ

<EOH>:SSMIX2 ヘッダー終了識別コード (0x1E0D)

<EOM>:HL7メッセージ終了識別コード (0x1C0D)

前SS-MIXの仕様ではこの情報は HL7メッセージに埋め込んでいたが、

SS-MIX2ではヘッダとして分離した

1電文

25 25

トランザクションストレージとは

トランザクションストレージはHISから送信されたHL7メッセージのログに 相当する。

どのようなケースで使用されるか ・ BCP対策として遠隔地バックアップ先にも標準化ストレージを構築する ・ 施設内の標準化ストレージを再構築する(HW更新やDISK破損など) トランザクションストレージの構造

トランザクションストレージを保存する運用を行うと、標準化ストレージと あわせて、データ量が2倍になるので、DISK容量に注意!

トランザクションストレージ ルートフォルダー

トランザクション発生年フォルダー

トランザクションデータファイル (TR_YYYYMMDDHHMMSSFFF_nnnnn.DAT)

26 26

インデックスデータベース

標準化ストレージは患者IDを特定してからデータにアクセスする構造と なっている。

フォルダ階層を読んでみないと、どんなデータが存在するかわからない。

データ検索を行おうとすると、大量のDISKアクセスが発生する。

インデックスデータベース(リレーショナルDB)を作成しておくことで、 誰の、どんなデータが格納されているかを検索することができる。

解決策

27 27

インデックスデータベース テーブル例

SS-MIX普及推進コンソーシアムから入手できるHL7メッセージ受信アプリにも

SQL Server上にインデックスデータベースを作成する機能が備わっている。

無料版SQL Server(SQL Server Express)を使用する場合は格納データ量の 上限値に注意する必要がある。(Win2008以前 4GB、Win2008R2以降 10GB)

No 項目(フィールド名) 型(ODBCデータ型) 長さ

1 ボリュームラベル(VolumeLabel) 半角英数可変文字(SQL_VARCHAR) 20

2 医療施設ID(FacilityID) 半角英数固定文字(SQL_CHAR) 10

3 患者ID(PatientID) 半角英数可変文字(SQL_VARCHAR) 15

4 診療日(OrderDate) 半角数可変文字(SQL_VARCHAR) 8

5 データ種別(DataKind) 半角英数可変文字(SQL_VARCHAR) 16

6 オーダNo(OrderNo) 半角数可変文字(SQL_VARCHAR) 22

7 処理区分(ProcessingType) 半角英数可変文字(SQL_VARCHAR) 3

8 診療科コード(EnterOrgCD) 半角英数可変文字(SQL_VARCHAR) 5

9 トランザクション日時(TransactionDatetime) 半角数可変文字(SQL_VARCHAR) 17

10 ファイル出力先ディレクトリ(OutRelDirectory) 半角英数可変文字(SQL_VARCHAR) 180

11 ファイル名(FileName) 半角英数可変文字(SQL_VARCHAR) 80

12 更新日時(UpdateDatetime) タイムスタンプ(SQL_TIMESTAMP) -

28 28

拡張ストレージ

標準化されていないレポート、文書、画像などは標準化ストレージではなく 拡張ストレージに格納する。

ここで「標準化されている」とはコンテンツ内容まで構造化され、その規格が国内的、 または国際的に認知されていることを意味する。

.doc、.pdf、.txt などファイル規格は国際標準でも、コンテンツ内容が構造化されて いない場合は拡張フォルダに格納するルールである。

(逆に)標準化ストレージには非標準化ファイルを格納してはならない。

29 29

拡張ストレージのフォルダ構造

標準化ストレージと同じ拡張ストレージ ルートフォルダ

患者ID 先頭3文字

患者ID 4~6文字

患者ID

診療日

データ種別

コンテンツフォルダ

_contents.xmlコンテンツ定義ファイル(推奨)[任意]

主文書ファイル(複数可)

サブフォルダ(必須ではない)

添付ファイルjpeg画像XMLDOC 等

30 30

①データ種別フォルダ 命名規則

コンテンツフォルダにどのような文書が格納されているかがわかるフォルダ名とする。

表記はHL7 Ver.2.5のCWE型を用いて以下のように定める

②コンテンツ定義ファイル

コンテンツ定義ファイルはコンテンツフォルダに、どのような文書やファイルが、どこに 格納されているかを示すXMLである。

コンテンツ定義ファイルは存在することは必須ではないが、推奨されている。

ローカル文書コード^ローカル文書名^ローカル文書コード体系^標準文書コード^標準文書名^標準文書コード体系

例1) 経食道超音波検査同意書 L123456^経食道超音波検査同意書^^592840^同意書^LN 例2) 読影レポート ^読影レポート^^187484^画像検査報告書^LN

施設内コード 施設内名称 標準コード 標準名称 LN:LOINC

拡張ストレージ特有の構造

31 31

③主文書ファイル 命名規則

標準化ストレージの場合は「オーダNo.」を用いたが、拡張ストレージの場合、オーダNo.に該当するIDがないことが予測されるため、施設毎に取り決めたIDを「特定キー」として用いる

拡張ストレージ特有の構造

患者ID_診療日_データ種別_特定キー_発生日時_診療科コード_コンディションフラグ

32 32

セキュリティ、データ管理

標準化ストレージのセキュリティ、データ管理は SS-MIX2のスコープ外となっています。

施設毎に厚生労働省の医療情報システム

安全管理ガイドラインに沿って、ストレージの 適切な管理を行う必要があります。

33

3.SS-MIXの応用例

標準化ストレージの可用性

地域医療連携における診療情報レポジトリ

医療情報の継続性の担保 • 異なるベンダ間のシステム更新時の継続的なデータ蓄積

マルチベンダシステム間の情報共有 • 統一的な手法で患者基本情報他を共有可能

システム障害時のバックアップ(BCP対策) • 過去の診療情報参照手段

データ二次利用 • 複数施設において統一的手法で解析、比較が可能 (事例) PMDA(医薬品医療機器総合機構)による発売後 薬品副作用調査

33

34

地域医療連携における診療情報レポジトリ

標準化ストレージ

HL7メッセージなど標準化された情報を格納

拡張ストレージ

XMLやDOC、 PDF、画像、音声などを格納

・患者基本(病名含む)・入退院・食事 ・処方・注射 ・検体検査・放射線検査・内視鏡検査 ・生理検査

退院時サマリ、 看護記録、 読影レポート、 紹介状、 麻酔記録 等

情報提供医療機関

患者 レジストリ

地域医療連携 センター

情報参照医療機関

ID Linkは標準化ストレージ、 拡張ストレージに対応しています

34

35 35

地域医療連携に関わるITI統合プロファイル全体像 (JAHIS技術文書 JAHIS IHE-ITIを用いた医療情報連携基盤実装ガイド本編 Ver2.0 より抜粋)

36

(ご参考)地域医療連携に用いるIHE 統合プロファイル

• PIX(Patient Identifier Cross-reference)

• PIXは患者IDの提供、及び、患者IDの問合せ/更新通知を実現するための統合プロファイルである

• 地域医療連携システムに患者を登録したり、患者が連携システムに参加しているかを確認する際に使用する

• PDQ(Patient Demographics Query) • PDQは患者情報サーバに対して、ユーザが指定する検索基準に基づく患者リストを照会し、患者基本情

報を取得するための統合プロファイルである

• 地域連携システムから患者情報を取得するために使用する。患者の検索も可能である

• XDS.b(Cross Enterprise Document Sharing) • XDSは地域連携システムに参加する複数の医療機関の間で、患者の診療記録を文書として共有する

仕組みを提供する

• 各医療機関に存在する診療情報を取得するために使用する

• XDS-i.b(Cross Enterprise Document Sharing for Imaging) • XDSの画像版

• XCA、XCA-i(Cross-Community Access) • XCAは他のコミュニティ(地域医療連携システム)で管理されている患者の診療情報を問い合わせ、取

得するための手段を提供している

• 地域医療連携システム内でPIX、PDQ、XDSが採用されていなくても利用可能

36

37

マルチベンダシステム間の情報共有

• 標準化ストレージ、拡張ストレージに格納されている情報は、 新たなインターフェイスを開発しなくても受け渡しが可能

• 部門システムを追加導入する際に、導入費用を抑えることができる

37

電子カルテサーバ

標準化ストレージ (既設)

部門システム (新規購入)

アクセス権限を付与すれば、参照が可能

38

FileMakerからのデータ利用も可能

FileMakerのマクロでフォルダ構造にアクセスが可能 • 画面例

• 患者基本情報を取得するためのマクロ例

cmd.exe /c copy ¥ストレージのパス¥ストレージ名¥¥” & Left(ID ; 3 )& “¥¥” & Middle( ID ; 4 ; 3 ) & ” ¥¥“ & ID & “¥-¥ADT-00¥*_1 D:patient_data.txt

38

39

システム障害時のバックアップ(BCP対策) 標準化ストレージとビューアがあれば、災害発生で基幹システムが

使用できなくなった場合でも、基本的な診療情報を参照可能

事例① The Geminiプロジェクト

• 全国42国立大学・46大学病院で遠隔バックアップシステムを構築

発災時は自施設のバックアップデータをマウントして、ネットワーク経由で参照することが可能 スマートフォンでも参照ができる

39

40

事例② 浜松医大様 災害時バックアップシステム(TB5)

全患者のSS-MIX2標準化ストレージと、過去1カ月分の画像データを可搬型ディスクに格納する。(可搬型ディスクは30台)

発災時や、ウィルス事故やネットワーク障害で基幹サーバにアクセスができない際に、ノートPCと可搬型ディスクをセットで診療現場に搬送し、 診療を継続可能とする。

電源さえ生きていれば 利用可能。

災害対策訓練時の様子 (丸枠内が可搬型ディスク)

40

41

データ二次利用 事例 PMDA 医療情報データベース基盤整備事業

• 厚生労働省が選定した、10グループの協力医療機関に保有される電子的な医療情報を 網羅的に収集する「医療情報データベース」を構築し、医薬品等の安全性情報を把握するために利活用する。(日本版センチネル事業)

• 医療情報は「SS-MIX2標準化ストレージとして各医療機関内に保有」されている。各医療機関にて定められたプロトコルに基づいた検索・分析を行い、その結果を収集する。

• 協力医療機関一覧 東北大学病院

千葉大学医学部附属病院

東京大学医学部附属病院

浜松医科大学医学部附属病院

香川大学医学部附属病院

九州大学病院

佐賀大学医学部附属病院

北里大学・北里研究所附属病院(グループ)

NTT病院(グループ)

徳洲会病院(グループ)

41

42

4.課題と展望

SS-MIX、SS-MIX2標準化ストレージを利用するに当たって 留意しておきたいこと

SS-MIX標準化ストレージとSS-MIX2標準化ストレージの混在

同一施設で複数のシステムから標準化ストレージを生成する場合 の問題

利用目的と相互運用性レベル

何が入っているの?

42

43

SS-MIX標準化ストレージとSS-MIX2標準化ストレージの混在

標準化ストレージを実装している施設は 2016年3月末で996施設

内、630施設では患者基本情報のみでは なく処方歴、検査結果歴も出力している

地域連携で標準化ストレージを診療情報レポジトリとして利用する場合、地域内でHL7 Ver.2.4準拠のSS-MIX標準化ストレージと、Ver.2.5準拠のSS-MIX2標準化ストレージが混在している可能性が高い

連携アプリケーション側で両仕様に対応するか、地域内でどちらかに統一するか、事前の協議が必要になる

43

44

同一施設で複数のシステムから標準化ストレージを生成する場合の問題

*1 患者基本情報等の 日付管理できない情報は

診療日に「-(ハイフン)」を 設定したフォルダーに

格納する

44

45

データ種別(一部抜粋)

処方(OMP-01)や検体検査 結果(OML-01)などは日付毎 にフォルダが分かれるが、患者基本情報は1フォルダしか存在できない

45

46 46

1施設内の複数システムからHL7メッセージを送る場合の問題

ADT-01レコード

標準化ストレージ

医科システム 歯科システム 患者登録、医科病名登録

歯科病名登録

上書き

ADT-01を更新する可能性があるシステムが複数存在する場合は標準化ストレージを分ける必要がある

47

利用目的と相互運用性レベル 相互運用性(Interoperability)を担保するために何が必要か

1.交換規約の標準化

•交換するデータ項目と属性、記述ルール

例) 氏名 姓名:鈴木 太郎 姓:鈴木 , 名:太郎 生年月日 19600223 S350225 23/02/1960

•交換するためのプロトコル

2.フォーマットの標準化

•画像フォーマット(DICOMフォーマット、JPEG、BMP)

•波形フォーマット(心電図、脳波計)

3.用語・コードの標準化

•コード 例) ALT と GPT この2つは名称は違うが、同じ検査項目

•用語 共通コードが付与されていれば名称が違っても同一と解釈可能

4.データ正規化

例) (+-) と ±、 5100(単位:μg/ml)と 5.1(単位:mg/ml)

47

48

相互運用性レベル

レベル 形態 説明 事例

1 非電子化 人手で運搬が必要。簡便。人が目で見て解釈できる。

紙カルテ、紹介状 X線フィルム

2 電子化 電子的な伝達が可能。意味理解は人が見て判断しなければならない。

PDF テキストメール スキャンデータ

3 構造化 構造化データで、標準に準拠しないコンテンツを含むもの。項目に分離ができるので異なるシステム間で再構成が可能となる。

XML HL7メッセージ

4 電子的解釈可能 構造化データで、標準準拠コンテンツであるもの。異なるシステム間で項目の意味まで解釈が可能

上記+標準コンテンツ(コード等)

5 電子的比較可能 構造化データで、標準準拠コンテンツであり、正規化されたもの。異なる施設やシステム間で項目の比較や計算が可能

上記+標準コンテンツ+正規化

推奨

あってもよい

↑経済産業省 H16~H19 医療情報システムにおける相互運用性実証事業成果より抜粋

地域医療連携に必須

48

今後要求が高まる相互運用性レベル

49

標準化ストレージがあれば、何にでも利用可能! ではない。

利用目的を定めて、求められる相互運用性レベルを満たすことが重要です • 地域連携 レベル3 (レベル4が望ましい)

• 永続的な保管 レベル4

• 有害事象調査 レベル4

• 施設間比較 レベル5

施設間データ比較などを目的とした、高い相互運用性レベルを要求する場合は、導入コストも大きくなる。(データの正規化が必要) 利用目的を明確にして導入することが望ましい。

49

50

何が入っているの? • 標準化ストレージはデータ種別で「何が入っているか」が判別できる。

では、拡張ストレージは?

• 地域連携や医療介護連携では 種々の情報が拡張ストレージに 格納されることが予想される

拡張ストレージにも データ種別はある

データ種別には各施設で 決めた文書コードを格納する

50

51

施設毎に定めた文書コードでは、地域連携においては 「開いてみなければ何が入っているかわからない」 と同義

現在、JAMI標準策定・維持管理部会とJAHISによるSS-MIX2仕様作成会

議で、Loincコードを元に日本において標準的に利用できる文書コードを検討中

です。 (来春 Ver.1.2dとして公開できるよう作業中)

51

大分類 LOINC個別 LOINC(必須) 個別

在宅指導書 34107-3

免疫アレルギ指導書 77430-7

栄養指導書 78451-2

服薬指導書 78601-2

指導書 34895-3

栄養、ナッツ等プリックテストを受けた患者さんへ、気管支ぜんそく学校生活指導管理、歯科特定疾患療養管理説明書、職場復帰支援外来化学療法での治療について、外来化学療法の費用について、抗悪性腫瘍投与について、頭頸部腫瘍動注化学療法について、脳血管撮影について、先天性代謝異常再採血のお願い、不規則抗体の説明、手術・検査等、顔面けいれんの手術を受けられる患者さんへ、手術、図による検査・手術説明、偶然見つかった脳動脈瘤について、診断結果および治療法、病状説明書、上部消化管内視鏡(胃カメラ)を受けられる方に、神経ブロックを受けられる患者様へ~硬膜外ブロック~、輸血・細胞治療部からのお知らせ、主治医意向、ケア実施手順等、学校用アレルギ疾患

検診・健診報告書 53576-5 1か月、4か月、10か月、3歳、3歳児精密、雇用時、乳がん

診断書 70004-7

死亡診断書 64297-5

出生証明書 71230-7

入院証明書

証明書 64299-1 装具装着、給食除去食、受診状況、通院、Medical certificate、身障者等級

52

ご静聴ありがとうございました

52