SS-MIX２の基礎と応用事例のご紹介
2016年11月21日
日本電気株式会社
佐々木 文夫
チュートリアル６ SS-MIX２初級編
目次
0．はじめに
1. SS-MIXとは何か
2. SS-MIXの基礎
3. SS-MIXの応用例
4. 課題と展望
０．はじめに
本日の内容を一言でまとめると
SS-MIX2（あるいはSS-MIX）は
医療施設の診療情報を、標準的な形式で
蓄積するためのルール
である。
１．SS-MIXとは何か
SS-MIXはここから始まった（静岡県版電子カルテ）
H15～H16年度 静岡県の事業として「静岡県版電子カルテ」が開発された。
HISから出力された標準的なデータを蓄積し、各種カルテ部品（紹介状編集
等）へデータを受け渡す仕組みとして「標準化ストレージ」が考案されている。
保健医療分野の情報化にむけてのグランドデザイン（H13.12.26)標準化ストレージの物理構造 （詳細は後述します）
DBを採用せず、安価に導入 できることを目指した。
HL7ファイル仕様はVer.2.4を 採用した。
（その後の経緯）
厚生労働省電子的診療情報交換推進事業
Standardized Structured Medical Information eXchange
標準化ストレージに着目した厚生労働省が、医療機関が標準的な情報を蓄積・交 換することにより、医療の質を高めることを目的としてシステム開発を静岡県に委 託 （医政局 H18年度事業） 正確にはSS-MIXは事業名であり、規格名ではない （規格としてHL7、DICOMを採用している）
SS-MIX２ Ver.0.96
SS-MIX標準化ストレージはHL7 Ver.2.4準拠だったが、JAHIS標準類がVer.2.5に 統一されたため、２つの規格の混在が利用者の混乱を招く可能性があった。 そのため総務省事業や厚生労働省事業の中で、標準化ストレージ仕様を HL7 Ver.2.5準拠に見直した。 この成果をJAMI標準策定・維持管理部会で整備し、H24年度末に SS-MIX2 Ver.0.96 として公開した。 なぜVer.0.96？ 標準用法マスタの公開時にVer.1.0にする予定だった。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の採番理由は４つの仕様書バージョンを統一するため （標準化ストレージ 構成の説明と構築ガイドライン Ver1.0が既存だった） （その後の経緯）標準化ストレージ導入状況
SS-MIX、SS-MIX2導入施設数 996施設（2015年時点 844施設） 内）処方、検体検査まで蓄積 630施設（ 〃 518施設） 2016年3月末時点 SS-MIX普及推進コンソーシアム調べ
２．SS-MIX２の基礎
４種類のストレージが定義されている
標準化ストレージ HL7メッセージなど 標準化された情報 を格納 拡張ストレージ XMLやDOC、 PDF、画像、音声 などを格納 ・患者基本（病名を含む） ・入退院・食事 ・処方・注射 ・検体検査 ・放射線検査 ・内視鏡検査 ・生理検査 • 画像 • 退院時サマリ • 看護記録 • 読影レポート • 紹介状 • 麻酔記録 等々SS-MIX２ではこれらの情報を、どのように
格納、蓄積するかを定めている
トランザクション ストレージ HL7メッセージの Logに相当するデータ インデックス データベース 標準化ストレージ、 拡張ストレージの 検索用インデックスまず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 人事管理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セグメントの３番目のフィールド。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> トリガーイベントコードとメッセージ 型コードの組み合わせで、このメッ セージが何を表すのかがわかる
（改めて）標準化ストレージのフォルダ構造
② ①
③ ④
フォルダの命名規則
①ルートフォルダー
任意の名前でよいが、災害時BCPに利用することを考慮して医療施設IDとする ことを推奨している。 医療施設ID 都道府県番号(２桁)＋機関区分コード(１桁)＋機関コード(６桁)＋チェックデジット(１桁) 施設内に複数の標準化ストレージがある場合は、医療施設IDに識別子を加える②患者IDフォルダー
患者IDによって、フォルダ名は自動的に決定される。③診療日フォルダ
該当の診療情報を作成した(診療行為を行った、もしくは行ったとみなす)日付を、 西暦8桁の数値(YYYYMMDD)で表現する 患者基本・病名・アレルギー等のように、日付の概念がない患者基本情報は 「- (ハイフン)」を用いる。③の診療日としてセットする情報（Ver.1.2で明確にされた）
病院情報システム等の仕様等によっては、上記で定めた方針通りに診療日を設定できないことが 考えられる。この場合は、当該施設の実施方針として、別途、診療日として採用する日付を定義し、 文書等で明確にしておくとともに、例外事項としてのこのルールを遵守すること。 No メッセージ型 メッセージ名 項目 No メッセージ型 メッセージ名 項目 1ADT^A08 患者基本情報の更新 - 19ADT^A25 退院予定の取消 PV2-9(退院予定日) 2ADT^A23 患者基本情報の削除 - 20ADT^A03 退院実施 PV1-45(退院日） 3ADT^A54 担当医の変更 - 21ADT^A13 退院実施の取消 PV1-45(退院日) 4ADT^A55 担当医の取消 - 22ADT^A60 アレルギー情報の登録／更新 -5ADT^A04 外来診察の受付 PV1-44(受付日) 23PPR^ZD1 病名（歴）情報の登録／更新-6ADT^A14 入院予定 PV2-8(入院予定日) 24OMD^O03 食事オーダ ORC-9 (食事のオーダ日) 7ADT^A27 入院予定の取消 PV2-8(入院予定日) 25RDE^011 処方オーダ ORC-9 (処方のオーダ日) 8ADT^A01 入院実施 PV1-44（入院日） 26RAS^O17 処方実施通知 RXA-3(服用した日) 9ADT^A11 入院実施の取消 PV1-44（入院日） 27RDE^011 注射オーダ ORC-9 (注射のオーダ日) 10ADT^A21 外出泊実施 EVN-6(外出泊日) 28RAS^O17 注射実施通知 RXA-3(注射を実施した日) 11ADT^A52 外出泊実施の取消 EVN-6(外出泊日) 29OML^O33 検体検査オーダ ORC-9 (検査のオーダ日) 12ADT^A22 外出泊帰院実施 EVN-6(帰院日) 30OUL^R22 検体検査結果通知 SPM-17(検体を採取した日) 13ADT^A53 外出泊帰院実施の取消 PV２-47(帰院日) 31OMG^O19 放射線検査オーダ ORC-9 (検査のオーダ日) 14ADT^A15 転科・転棟（転室・転床）予定 PV２-8(転科転棟日) 32OMI^Z23 放射線検査の実施通知 OBR-7(検査を実施した日) 15ADT^A26 転科・転棟（転室・転床）予定の取消 PV２-8(転科転棟日) 33OMG^O19 内視鏡検査オーダ ORC-9 (検査のオーダ日) 16ADT^A02 転科・転棟（転室・転床）実施 EVN-6(転科転棟日) 34OMI^Z23 内視鏡検査の実施通知 OBR-7(検査を実施した日) 17ADT^A12 転科・転棟（転室・転床）実施の取消 EVN-6(転科転棟日) 35OMG^O19 生理検査オーダ ORC-9 (検査のオーダ日) 18ADT^A16 退院予定 PV2-9(退院予定日) 36ORU^R01 生理検査結果通知 OBR-7(検査を実施した日)
④データ種別フォルダ命名規則
上記のデータ種別全てを要求しているわけではなく、施設毎に必要とするデータを 出力すればよい。
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^Ｏ11 変更 8 ADT-22 入院実施 ADT^A01 26 OMP-11 処方実施通知 RAS^O17 追加 9 ADT-22 入院実施の取消 ADT^A11 27 OMP-02 注射オーダ RDE^Ｏ11 変更 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 追加
No データ種別 内容 1 REF-01 当該医療施設で作成した「紹介状」 2 INF-01 当該医療施設で作成した「電子診療データ」 3 REF-02 他医療施設より受け取った「紹介状」CDの内容 4 INF-02 他医療施設より受け取った「電子診療」CDの内容 5 PDI-01 他医療施設より受け取ったPDI CDの内容
④データ種別フォルダ命名規則（続き）
自院で作成、または他施設から受領した標準化された情報 上記に該当するHELICS指針（規約）は厚生労働省標準規格として採用されている HS007 患者診療情報提供書及び電子診療データ提供書（患者への情報提供） HS008 診療情報提供書（電子紹介状） HS009 IHE統合プロファイル「可搬型医用画像」およびその運用指針 http://helics.umin.ac.jp/helicsStdList.htmlデータ種別フォルダに格納するコンテンツの命名規則
診療日、データ種別はフォルダ命名規則と同じ 発生日時は YYYYMMDDHHMISSFFF(ミリ秒)で表記する コンディションフラグ 0：無効（論理削除） 1：有効 2：無効（過去履歴） ファイル名に拡張子はつけない 患者ID_診療日_データ種別_オーダNo_発生日時_診療科コード_コンディションフラグコンテンツの実体
標準化ストレージでは１つのHL7メッセージやCDAファイルが、１ファイルに格納される。
CDA：Crinical Document Architecture R.2（ISO/HL7 27932）で定められたXML文書
HL7メッセージの場合は１ファイルは１オーダとする。 ただし病名のみは１患者に対する全ての病名情報を１ファイルで表現する。 メッセージの文字コードセットは「JIS（JIS X 0208）」で格納することとする。 （JIS X 0208付録書のShift-JISではない） HL7メッセージ仕様は以下のドキュメントで定めている。 ・SS-MIX2 標準化ストレージ 仕様書 Ver.1.2c ・SS-MIX2 標準化ストレージ 仕様書 Ver.1.2c_コード表
標準化ストレージ仕様書（抜粋）
フィールドID フィールド名 LEN DT OPT RP # ＪＡＨＩＳ 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 C 1 つの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 定性値を持つ結果の場合、結果が真である確率(結果が特定 のコードとなる確率)。 最 大 デ ー タ 長 デ ー タ 型 Ｒ ・ 必 須 Ｏ ・ オ プ シ Ｃ ・ 選 択 繰 り 返 し コ ー ド テ ー ブ 番 号 ＪＡＨＩＳデータ交換規約との 対比を記述している
22 22
SS-MIX２ 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 に採血検査Ｘを実施せよ。」 これに対して、日時T3 に採血を行い、T4 に検査室で検体を受領し、日時T5 に検 査を実施し、日時T6 に結果報告した。SS-MIX２の実装例
ＨＩＳ側からはSS-MIXヘッダとＨＬ７メッセージを送信する トランザクションストレージと、インデックスデータベースの作成は必須ではない（任意） ＨＩＳ側に実装されたアプリケーションが、直接ストレージサーバに書き込んでもよい。 ＨＬ７メッセージ受信アプリはSS-MIX普及推進コンソーシアムから有償で入手が 可能になる予定。（日本IHE協会 コネクタソンの通信プロトコルを使用）HIS
電 子 カ ル テ オ ー ダ エ ン ト リ Ｈ Ｌ ７ 送 信 ア プ リストレージサーバ
Ｈ Ｌ ７ 受 信 ア プ リ トランザクション ストレージ 標準化ストレージ 拡張ストレージ インデックス データベース SS-MIXヘッダ ＋ HL7メッセージ ＲＤＢSS-MIX２ヘッダについて
HISから送信するメッセージ SS-MIXヘッダには、標準化ストレージのフォルダ 名を決定するための情報が含まれている。 No 項目 内容 1 SS-MIX識別 固定値「#SSMIX」を設定する。 2 バージョン SS-MIXのバージョンを表す。 本仕様においては固定値「2.00」を設定する。 3 医療施設ID 医療施設を一意に識別するID(10桁) ※厚生労働省 特定健診・特定保健 指導 デー タの ファイルイメージ 参考資料5(p7,8)、ならびにJAHIS 基本データセット適用ガイドライン Ver2.1(p4)に基づ き都道府県番号（２桁）＋機関区分コード（１桁）＋機 関コード（６桁）＋チェックデジット（１桁）の計１０桁で 構成されるコードを用いることとする。 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ではヘッダとして分離した １ 電 文トランザクションストレージとは
トランザクションストレージはＨＩＳから送信されたＨＬ７メッセージのログに
相当する。
どのようなケースで使用されるか
・ ＢＣＰ対策として遠隔地バックアップ先にも標準化ストレージを構築する
・ 施設内の標準化ストレージを再構築する（ＨＷ更新やDISK破損など）
トランザクションストレージの構造
トランザクションストレージを保存する運用を行うと、標準化ストレージと
あわせて、データ量が２倍になるので、ＤＩＳＫ容量に注意！
トランザクションストレージ ルートフォルダー トランザクション発生年フォルダー トランザクションデータファイル (TR_YYYYMMDDHHMMSSFFF_nnnnn.DAT)インデックスデータベース
標準化ストレージは患者ＩＤを特定してからデータにアクセスする構造と
なっている。
フォルダ階層を読んでみないと、どんなデータが存在するかわからない。
データ検索を行おうとすると、大量のDISKアクセスが発生する。
インデックスデータベース（リレーショナルＤＢ）を作成しておくことで、
誰の、どんなデータが格納されているかを検索することができる。
解決策インデックスデータベース テーブル例
SS-MIX普及推進コンソーシアムから入手できるＨＬ７メッセージ受信アプリにも SQL Server上にインデックスデータベースを作成する機能が備わっている。
無料版SQL Server（SQL Server Express）を使用する場合は格納データ量の
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) -
拡張ストレージ
標準化されていないレポート、文書、画像などは標準化ストレージではなく
拡張ストレージに格納する。
ここで「標準化されている」とはコンテンツ内容まで構造化され、その規格が国内的、 または国際的に認知されていることを意味する。 .doc、.pdf、.txt などファイル規格は国際標準でも、コンテンツ内容が構造化されて いない場合は拡張フォルダに格納するルールである。 （逆に）標準化ストレージには非標準化ファイルを格納してはならない。拡張ストレージのフォルダ構造
① ② 標準化ストレージと同じ 拡張ストレージ ルートフォルダ 患者ID 先頭３文字 患者ID ４～６文字 患者ID － 診療日 データ種別 コンテンツフォルダ _contents.xml コンテンツ定義ファイル（推奨）[任意] 主文書ファイル（複数可） サブフォルダ（必須ではない） 添付ファイル jpeg画像 XML ③ ①データ種別フォルダ 命名規則
コンテンツフォルダにどのような文書が格納されているかがわかるフォルダ名とする。 表記はHL7 Ver.2.5のCWE型を用いて以下のように定める ②コンテンツ定義ファイル
コンテンツ定義ファイルはコンテンツフォルダに、どのような文書やファイルが、どこに 格納されているかを示すXMLである。 コンテンツ定義ファイルは存在することは必須ではないが、推奨されている。 ローカル文書コード^ローカル文書名＾ローカル文書コード体系＾標準文書コード＾標準文書名＾標準文書コード体系 例１） 経食道超音波検査同意書 L123456＾経食道超音波検査同意書＾＾592840＾同意書＾LN 例２） 読影レポート ＾読影レポート＾＾187484＾画像検査報告書＾LN 施設内コード 施設内名称 標準コード 標準名称 LN：LOINC拡張ストレージ特有の構造
③主文書ファイル 命名規則
標準化ストレージの場合は「オーダNo.」を用いたが、拡張ストレージの
場合、オーダNo.に該当するIDがないことが予測されるため、施設毎に
取り決めたIDを「特定キー」として用いる
拡張ストレージ特有の構造
患者ID_診療日_データ種別_特定キー_発生日時_診療科コード_コンディションフラグセキュリティ、データ管理
標準化ストレージのセキュリティ、データ管理は
ＳＳ-ＭＩＸ２のスコープ外となっています。
施設毎に厚生労働省の医療情報システム
安全管理ガイドラインに沿って、ストレージの
適切な管理を行う必要があります。
３．SS-MIXの応用例
標準化ストレージの可用性
地域医療連携における診療情報レポジトリ
医療情報の継続性の担保
• 異なるベンダ間のシステム更新時の継続的なデータ蓄積
マルチベンダシステム間の情報共有
• 統一的な手法で患者基本情報他を共有可能
システム障害時のバックアップ（BCP対策）
• 過去の診療情報参照手段
データ二次利用
• 複数施設において統一的手法で解析、比較が可能
（事例） PMDA（医薬品医療機器総合機構）による発売後
薬品副作用調査
地域医療連携における診療情報レポジトリ
標準化ストレージ HL7メッセージ など標準化され た情報を格納 拡張ストレージ XMLやDOC、 PDF、画像、音 声などを格納 ・患者基本（病名含 む）・入退院・食事 ・処方・注射 ・検体検査・放射線 検査・内視鏡検査 ・生理検査 退院時サマリ、 看護記録、 読影レポート、 紹介状、 麻酔記録 等 情報提供医療機関 患者 ﾚｼﾞｽﾄﾘ 地域医療連携 センター 情報参照医療機関 ID Linkは標準化ストレージ、 拡張ストレージに対応しています（ご参考）地域医療連携に用いる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は他のコミュニティ（地域医療連携システム）で管理されている患者の診療情報を問い合わせ、取 得するための手段を提供している
マルチベンダシステム間の情報共有
• 標準化ストレージ、拡張ストレージに格納されている情報は、 新たなインターフェイスを開発しなくても受け渡しが可能 • 部門システムを追加導入する際に、導入費用を抑えることができる 電子カルテサーバ 標準化ストレージ （既設） 部門システム （新規購入） アクセス権限を付与す れば、参照が可能 FileMakerからのデータ利用も可能
FileMakerのマクロでフォルダ構造にアクセスが可能
• 画面例• 患者基本情報を取得するためのマクロ例
cmd.exe /c copy ¥ストレージのパス¥ストレージ名¥¥” & Left(ID ; 3 )& “¥¥” & Middle( ID ; 4 ; 3 ) & ” ¥¥“ & ID & “¥-¥ADT-00¥*_1 D:patient_data.txt
システム障害時のバックアップ（BCP対策）
標準化ストレージとビューアがあれば、災害発生で基幹システムが
使用できなくなった場合でも、基本的な診療情報を参照可能
事例① The Geminiプロジェクト
• 全国42国立大学・46大学病院で遠隔バックアップシステムを構築
発災時は自施設のバック アップデータをマウントして、 ネットワーク経由で参照す ることが可能 スマートフォンでも参照が できる事例② 浜松医大様 災害時バックアップシステム（TB5）
全患者のSS-MIX２標準化ストレージと、過去１カ月分の画像データを
可搬型ディスクに格納する。（可搬型ディスクは３０台）
発災時や、ウィルス事故やネットワーク障害で基幹サーバにアクセスができ
ない際に、ノートPCと可搬型ディスクをセットで診療現場に搬送し、
診療を継続可能とする。
電源さえ生きていれば
利用可能。
災害対策訓練時の様子 （丸枠内が可搬型ディスク） データ二次利用
事例 PMDA 医療情報データベース基盤整備事業
• 厚生労働省が選定した、10グループの協力医療機関に保有される電子的な医療情報を 網羅的に収集する「医療情報データベース」を構築し、医薬品等の安全性情報を把握する ために利活用する。（日本版センチネル事業） • 医療情報は「SS-MIX２標準化ストレージとして各医療機関内に保有」されている。各医療 機関にて定められたプロトコルに基づいた検索・分析を行い、その結果を収集する。 • 協力医療機関一覧 東北大学病院 千葉大学医学部附属病院 東京大学医学部附属病院 浜松医科大学医学部附属病院 香川大学医学部附属病院 九州大学病院 佐賀大学医学部附属病院 北里大学・北里研究所附属病院（グループ） ＮＴＴ病院（グループ） 徳洲会病院（グループ）４．課題と展望
SS-MIX、SS-MIX２標準化ストレージを利用するに当たって
留意しておきたいこと
SS-MIX標準化ストレージとSS-MIX２標準化ストレージの混在
同一施設で複数のシステムから標準化ストレージを生成する場合
の問題
利用目的と相互運用性レベル
何が入っているの？
SS-MIX標準化ストレージとSS-MIX２標準化ストレージの混在
標準化ストレージを実装している施設は 2016年3月末で996施設 内、630施設では患者基本情報のみでは なく処方歴、検査結果歴も出力している 地域連携で標準化ストレージを診療情報レポジトリとして利用する場合、地域 内でHL7 Ver.2.4準拠のSS-MIX標準化ストレージと、Ver.2.5準拠のSS-MIX2標 準化ストレージが混在している可能性が高い 連携アプリケーション側で両仕様に対応するか、地域内でどちらかに統一する か、事前の協議が必要になる同一施設で複数のシステムから標準化ストレージを生成する場合の問題
*1 患者基本情報等の 日付管理できない情報は 診療日に「-（ハイフン）」を 設定したフォルダーに 格納するデータ種別（一部抜粋）
処方（OMP-01）や検体検査 結果（OML-01)などは日付毎 にフォルダが分かれるが、患者基本 情報は１フォルダしか存在できない
