電子カルテ情報共有 導入記
診療情報提供書サンプルの疑問
UUID
診療情報提供書サンプルのオリジナルJSON
https://jpfhir.jp/fhir/clins/output/Bundle-Bundle-CLINS-Referral-NoEntry-Example-01.json.html
には 多数のuuidが記述されています。
そもそもUUIDとは
https://qiita.com/Anveloper/items/96e7f5e8bacbabf0a1ff
UUIDとは、全世界で2つ以上のアイテムが同じ値を持つことがない一意な識別子のこと。
何らかの組織やシステムなどが管理・割り当てを行うわけではなく、誰でもいつでも自由に生成することができるが、他のUUIDと重複することは起きないようになっている。
UUIDをランダムで生成すると、被る可能性が数学的にほぼないです。
ということです。数学的には 「被る可能性」はゼロではないのですが,天文学的に小さい確率になるそうです。
Filemakerでは uuidは Get(UUID)関数で作成できますが, なぜかしら 大文字で出てきます。電子カルテ情報共有では小文字のuuid が要求されますので, Lower関数で変換します。
FHIRで記述する UUIDについて調べても, 明確に解説された ネット記事は見つけられないのですが, 以下の fullUrl に関する記事が 参考になります。
https://jpfhir.jp/fhir/clins/igv1/StructureDefinition-JP-Bundle-CLINS.html
13. Bundle内のentryの識別子（fullUrl）
「Bundle.entry[ ] に繰り返しで格納される個々のリソース・インスタンスは、必ずBundle.entry[ ].fullUrl要素に、uuidをその都度毎回生成して異なる値を設定しなければならない。
1回で送信するひとつのBundleインスタンスの中に同一のuuidが存在してはならない（エラーとなる）。
同じリソースインスタンスを別のBundleリソースにより再送する場合は、前回送信時に使用したuuidをしてもよいが、新たに生成してもよい。
このuuidによるBundle内のentryの識別子(fullUrl)を、前回送信時の特定のentryの内容を受信側に指し示すための識別子として利用することはできない（受信側で保存していない）。」
診療情報提供書に登場する fullUrl の uuidは 同じものがあってはいけません。
その診療情報提供書を再送(コピー)するときは uuid は 新たに生成したものでもよい。
uuidはその診療情報提供書を個別に識別するものではない ( 文書内部だけで意味がある)
ONSに この UUIDについて 質問しました。
「紹介元のuuid は 医療機関， 文書作成者， 発行責任者， などに 同じものが使われていますが，これは，医療機関が 存続する限り， ずっと同じものを使い続けるべきでしょうか？
紹介元医師の uuid も 医師が生きている限り同じものを使うべきですか？
紹介先 医療機関 医師 患者の uuid は発行の都度 任意に付番すればよろしいでしょうか？」
リソース中のUUIDは、一報告単位のBundleリソース中でユニークであればよく、複数のBundleをまたいで（グローバルに）ユニークである必要はございません。
というわけで, uuidは その都度「適当に」記載すればいい, と解釈できます。
しかし, ひとつの診療情報提供書内部の uuidが すべて「適当に」記載されているかというと, そうではありません。意図を持って重複使用されているようです。その重複を目視で調べるのはちょっと面倒です。この診療情報提供書では17この uuidが出現しますが, 3つのサンプルの内 一番大きなJSONでは59のuuidが表記されています。
uuid を調べるソフトをFilemakerで作ってみました。(JSON_UUID1)
route 2 で紹介したサンプルソフトを改変し,機能追加したものです。
A に JSONの uuidを含む行を抽出します。最初から順番にuuidに(番号)を付与します。
B に さらに uuidを抜き出します。
C は 重複番号を調べます。(作業画面)
D は 最終的に重複したuuid番号を表示します。
E は fullUrl 行のみを抽出します。
この診療情報提供書には 17個のuuidが記載されています。種類はDに表示される6種類です。
6個の fullUrl は すべて異なるuuidが振ってあり,これがすべてです。それらが reference, etc に割り振られています。
下記のページの解説(Narrative Content )によると エントリ 1 〜 6 になります。
https://jpfhir.jp/fhir/clins/output/Bundle-Bundle-CLINS-Referral-NoEntry-Example-01.html
16 "fullUrl" : "urn:uuid(1):830ec2d1-67a7-427e-b6fe-ad0eb29da7fb",......エントリ1 ( Resource Composition) 目次
297 "fullUrl" : "urn:uuid(13):0a48a4bf-0d87-4efb-aafd-d45e0842a4dd",......エントリ2 (Resource Patient) 患者
362 "fullUrl" : "urn:uuid(14):3e6a0ba2-d781-4fd7-9de6-e077b690daed",......エントリ3 (Resource Practitioner) 紹介元医師
386 "fullUrl" : "urn:uuid(15):f11535c2-043d-43b6-bf99-b8298ea3c946",......エントリ4 (Resource Practitioner) 紹介先医師
410 "fullUrl" : "urn:uuid(16):8a888471-9781-4fb7-b5c4-b34afcdea638",......エントリ5 (Resource Organization) 紹介元機関
477 "fullUrl" : "urn:uuid(17):a44951be-cdaa-4c53-9e35-6be013da5441",......エントリ6 (Resource Organization) 紹介先機関
この診療情報提供書サンプルの uuid をすべて調べて見ると
uuid(1) fullUrl エントリ1
uuid(2),uuid(3),uuid(4) は <div>,</div> のなかにあります。
author:
•\"Bundle-Bundle-CLINS-Referral-Example-01.html#urn-uuid-3e6a0ba2-d781-4fd7-9de6-e077b690daed\">診療情報提供書作成者PractitionerRoleリソース uuid(2) reference エントリ3
•\"Bundle-Bundle-CLINS-Referral-Example-01.html#urn-uuid-8a888471-9781-4fb7-b5c4-b34afcdea638\">診療情報提供書作成機関Organizationリソース uuid(3) reference エントリ5
title: 診療情報提供書
custodian: \"Bundle-Bundle-CLINS-Referral-Example-01.html#urn-uuid-8a888471-9781-4fb7-b5c4-b34afcdea638\">診療情報提供書交付責任機関Organizationリソース uuid(4) reference エントリ5
uuid(5) reference 患者リソースPatient エントリ2
uuid(6) reference 診療情報提供書作成者Practitionerリソース エントリ3
uuid(7) reference 診療情報提供書作成機関Organizationリソース エントリ5
uuid(8) reference 診療情報提供書交付責任機関Organizationリソース エントリ5
uuid(9) reference 紹介元機関 エントリ5
uuid(10) reference 紹介元医師 エントリ3
uuid(11) reference 紹介先医療機関 エントリ6
uuid(12) reference 紹介先医師 エントリ4
uuid(13) fullUrl エントリ2
uuid(14) fullUrl エントリ3
uuid(15) fullUrl エントリ4
uuid(16) fullUrl エントリ5
uuid(17) fullUrl エントリ6
以上の解析から
このサンプルをひながたとして使うときには, 6個のuuid 被置換コード用意すればいいことが分かります。さらに同じuuid をどこに配置すればいいかも分かります。
この結果を「診療情報提供書XMLサンプルソフト JSON_FHIR_1G 以降」に反映させました。
No. 11
(工事中)
2025.5.24 更新
