Locatorsの翻訳である。OverviewopenEHRのアーキテクチャにはパスのメカニズムが含まれており、これにより最上位構造内のいかなるノードも、"セマンティックな"(すなわちアーキタイプ・ベースの)XPath互換パスを用いて、構造の最上位から特定していくことができる。このようなパスが利用可能であることは、健康情報に対する検索の可能性を根底から変えるものであり、openEHRの主要な特徴的な機構のひとつとなっている。openEHR.技術的には、パスとOBJECT_VERSION_IDのようなバージョン識別子の組合わせによって、LOCATABLE_REFを用いて表現可能な"グローバルに認識可能なノードのリファレンス"といったものが形成される。それは"グローバルに認識可能なノードのロケーター"として知られるDV_EHR_URIとして、可搬性のあるURI形式でも表現可能である。どちらの表現方式でも、あらゆるopenEHRデータ・ノードは、どこからでも参照可能となる。この章では、パスと参照のためのURI形式についての構文とセマンティクスを記述する。下記において、"アーキタイプ・パス"という用語はアーキタイプから抽出されたパスを意味し、"データ・パス"とはデータ中の要素を特定するパスを意味するものとする。両者に形式上の差異はなく、このターミノロジーはそれらがどこで用いられるかを指し示すためだけに使用される。ADL)に記載されたパス文法のスーパーセットとなっている。この文法はXPath表現に容易にマッピングできるよう設計されており、openEHRベースのXMLとともに使用できる。attribute_nameパスは、ツリー中の何らかの先頭ポイントから開始され、パス中に与えられる属性名をたどり、パス中の最後の属性名の値をもつオブジェクトを選択する。先頭ポイントはパスの最初の部分で示され、2つの方法で特定されうる。相対パスは属性名で始まり、先頭ポイントはツリー中のカレント・ポイントである。絶対パスは`/'で始まり、先頭ポイントは構造の最上位である。表記が、パス・パターンを定義するために用いられる。表現から開始され、またはこれを含み、データ中の任意の数のパス・セグメントに相当するパターンとして取り扱われる。先立つパス・セクションがパスの部分にマッチし、`'以降に現れるセクションが後半のセクションにマッチするならば、構造中のいかなる部分においても実際のパスにマッチさせることができる。Expressions概要Overview属性名のみで記述されるパスには、2つの制約事項がある。1番目は、リストや集合等のコンテナを持たない構造中のオブジェクトのロケーションだけしか表現できないことである。openEHRのたいていのデータを含め、あらゆる現実のデータはリストや集合やハッシュ構造を持つのが普通である。コンテナ属性によって兄弟オブジェクトの中から特定のものを参照可能とするために、追加の構文が必要となる。]')で囲んだ述語表現の形式を用いる。expression]パスの一般形式は、それゆえ以下のようになる。...ここでは、述語表現は、リファレンス・モデルにおいてコンテナ型(すなわち1より大きな基数を持つ)であるものとして定義される属性に対してオプションとして使用される。あるコンテナ属性に対して述語表現を使用しない場合は、全コンテナが選択される。述語表現は単一の値を取る属性に対してもしばしば使用されうること、及び、技術的には使用可能(例えば、汎用のパス処理ソフトウェアがこの差異を無視する場合)であっても、必須ではないことに注意せよ。required.基本パスの2番目の制約事項は、特定の値を取る子ノードを持つオブジェクトといった、外部条件に基づくオブジェクトのロケーションを表現できないことである。これに対処するため、述語表現によって当該オブジェクトに関する外部条件に基づくオブジェクトの選択が可能であり、これにはパス、演算子、値及び括弧を含む論理値表現を含めることができる。opneEHRで用いられる述語表現の構文は、述語のためのXPathの構文のサブセットであり、いくつかの省略形が含まれる。値(LOCATABLEから継承したもの)を用いる。省略形式では、たとえば[at0003]といったアーキタイプ・コードを述語として含めることが許される。この省略形は、ランタイム・データに対してアーキタイプ・パスを用いることに相当する。典型的なアーキタイプ派生パスは、以下のようなものである。instance):/data/events[at0003]/data/items[at0025]/value/magnitudeこのパスは、全アプガー評価の内容を構造として持つObservationから、出生後1分のアプガー指数の値を参照するものである。アーキタイプ・パスは、アーキタイプにおいては常に一意なものであるが、ランタイム・データにおいては、コンテナ内での同一のアーキタイプ・ノードの反復使用によって1つ以上の要素に対応できることに注意せよ。値と同様にname値(これもLOCATABLEから継承されたもの)を含めることができる。この表現のための標準XPath形式を、以下に例示する。name/value=`standing']アーキタイプ・ノードの識別子とname値との組合わせはアーキタイプ・データベースにおいてごく一般的であるため、name/value表現についても省略形が利用可能である。それは下記のように、単にコンマの後に値を含めればよい。いったその他の属性の値に基づく述語が使用できる。とこれらの値の組合わせは検索に際してよく用いられる。中のEventを選択する。下記の例では、"その他の細菌性腸管感染症"(ICD10コードA04)という診断(at0002.1)を含むEvaluationが選択されるであろう。Structures最上位構造内のパスは、リファレンス・モデルの関係部分における属性や関数名と厳格に結びついている。述語表現は、これらの構造中のパスにおけるさまざまなポイント、とりわけアーキタイプが「チェーンしている」ポイントにおいて、多数の兄弟関係にあたるものを区別するために必要である。チェーン・ポイントとは、図30に図示されるように、あるアーキタイプが他のアーキタイプを引き継ぐ場所である。COMPOSITION内部におけるチェーン・ポイントは、COMPOSITIONとひとつのSECTION構造との間、そしておそらくは(異なるSECTIONアーキタイプによって強制されて)ひとつのSECTION構造と他のサブSECTION構造との間、さらにはCOMPOSITIONかSECTION構造のいずれかとENTRYとの間に発生する。Item_list等の下位レベルの構造でアーキタイプが用いられる場合には、チェーンはENTRY内部でも生じ得る。チェーン・ポイントは、List<T>のようなコンテナ型に相応している。List<CONTENT_ITEM>として定義され、実データにおいてCOMPOSITIONのコンテンツがSECTION構造のリストであり得るということを意味する。このような兄弟構造を区別するために、述語表現がarchetype_idに基づいて使用されるのである。データ中のあるアーキタイプのルート・ポイント(たとえばSECTION構造の最上位)において、archetype_idはその構造を生成するために用いられたアーキタイプの識別子を保持するが、それはアーキタイプ構造内のあらゆる内部ポイントがアーキタイプのnode_idの値を保持するarchetype_node_id属性を持っていることと同様である。SECTIONとENTRY間のチェーン・ポイントも同様に作用する。単一のSECTION下で多数のENTRYが発生し得ることから、archetype_id述語はこれらを区別するためにも用いられる。archetype_node_idのためにarchetype_id述語表現による同様の簡略表記が用いられる。"xxxxx"]と書く代わりに、[xxxx]と記述できる。instead.以下のパスは、COMPOSITION内で項目を参照する例である。event']/data/items[at0005]他の最上位タイプ内のパスも、同様の一般的なアプローチでたどることができる。必要な属性を階層構造に沿ってたどることで生成される。Uniquenessひとつのアーキタイプ・ノードがデータ中の多数のインスタンスに対応し得るものであるという事実があるために、アーキタイプ・パスは、データ中で一意に識別される項目であるという保証はない。実データ中で一意の項目であるようなパスを構築することは、しばしば必要となる。このことはパス述語においてarchetype_node_ide以外の属性を用いることによって可能となる。以下のOBSERVATIONアーキタイプを例として考察してみよう。{...}}}}}}}}}このアーキタイプから抽出された以下のパスは、収縮期血圧値を参照するものである。magnitude:/data/events[at0006]/data/items[at0004]/value/magnitudeアーキタイプの各ノードの[atnnnn]というコードが、データ中の各ノードで見られるarchetype_node_idとなる。data.さてここで、このアーキタイプを用いて2つの血圧の履歴が記録されているOBSERVATIONインスタンス(ここではdADL形式で表現される)について考察しよう。上記の例において、名前の値はすべてDV_TEXTであるものとして示しているが、実際のopenEHRではDV_CODE_TEXTインスタンスであることが多い。どちらもアーキタイプによって許容される。これは例示のサイズを縮小するためであり、下記に示すパスとなんら異なるものではない。below].上述のアーキタイプ・パスは、記録に含まれる両収縮期血圧のいずれにも適合する。多くの検索場面において、これこそが正に求められるものである。収縮期血圧の各ノードに一意に適合させるためには、パスはarchetype_node_idのみならず他の属性にも基づいて生成されなければならない。上記のケースでは、name属性が一意性を提供する。各イベント(座位及び立位での計測)ごとの収縮期及び拡張期血圧に関する一意性が保証されたパスは、下記の表現によって可能となる。/data/events[2]/data/items[2]/value/magnitudeアーキタイプ・パスに基づいて、さらに表現力のある一意のパスも可能である。これらのパスはそれぞれXPathと等しい以下の形式を持っている。name/value=standing']/data/items[@archetype_node_id=`at0004']/value/magnitude一般規則として、ランタイム・データにおけるひとつまたは複数の他の属性値によって、openEHRデータにおけるいかなるノードでも一意に識別させることができるであろう。値が、兄弟ノードのname値に対して一意であることが要請される。このことは以下の2点に帰着する。一意性が保証されたパスは、(上記のパスの例で示したように)archetype_node_idとname値との組合わせを用いることによって、openEHRデータ中のいかなるデータに対しても常に構築することが可能である。name値は、ひとつまたは複数の属性値のコピーとしてシステマティックに定義することも可能であろう。あるEVENTオブジェクトにおいて、nameはtime属性を文字列としてコピーしたものとすることが明らかに可能である。URIsあらゆるリソースに使用可能なURIとして、直接参照と検索の2つの大きなカテゴリーがある。最初の種類は、通常参照されるべき項目を含むシステムによって生成され、定義された参照情報として他のシステムに渡される。2つ目のものは、要求側のシステムからURI形式によって行われるクエリである。identifier)形式での参照を生成するためには、最上位構造内のパス、EHR内での最上位構造への参照、そしてEHRへの参照という、3つの要素が必要となる。これらは、以下の構文に従って、"ehr"スキーマ空間内でURI形式に組合わされる。EHRのあらゆるオブジェクトは、URIを通じてアドレス可能となる。ehr空間内では、特定のサーバーやホスト等に対するURLスタイルでの参照は、長期間にわたる信頼性が得られないために、用いられない。その代わり、EHR及び/または患者に対する論理的な識別子が用いられ、参照しようとしているリソースのライフタイムにわたってURIが正しく存続することを担保している。EHR内の他の場所で用いられるべく構築されることを実現している。いうURIは、ehr空間内での名前解決のメカニズムが使用できることを意味している。これは、http-、ftp-及びその他のウェル・ノウンURIスキーマに対してそのようなサービスを提供するDNSと同様である。URIの取り扱いには、より伝統的なhttp://スタイルの参照と同じように、アドホックな手段が使用されていたと思われる。以下のサブセクションでは、両方の種類のURIがどのように構築されるかを記述する。Locationehr空間では、EHRに対する直接のロケーターは、患者の識別子やクエリとは明確に区別されるEHR識別子である。通常は要求される対象は'ローカル・システム'内のコピーであり、大多数の場合は、それが実在する唯一のものであると思われる。このケースでは、要求されるEHRは、以下の形式のURIで与えられるような、修飾子のない識別子によって単純に識別できる。form:ehr://1234567/だが、患者のEHRは多数のEHRシステム間でコピーされ同期されるために、与えられたEHR識別子がひとつ以上のロケーションに存在する場合がある。部分コピーが許容されているため、このようなEHRのそれぞれが他と完全に一致するコピーであるという保証はない。それゆえに、EHRのコピーが存在する環境で、どのEHRのインスタンスが要求されているかを正確に識別することを要する場合には、以下の形式のURIで与えられるような体系的な識別子も必要となる。EHRにおける最上位構造を識別するためには、論理的に2つの方法がある。time')の組合わせによるものである。前者は、関係するVERSIONED_OBJECTのuidを用いる方法や、アーキタイプ識別子または名前による方法を含む、いくつかの方法で行うことができる。これによればURIは以下のようになる。time最上位構造を識別する2番目の方法は、正確なバージョン識別子を用いる方法である。version_object_uid::version_tree_id::creating_system_idという形式をとるopenEHR標準のバージョン識別子である。この場合は、URIは以下のようになる。following:ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2ehr://1234567/87284370-2D4B-4e3d-A3F3-F303D2F4F34B::F7C5C7B7-75DB-4b39-9A1E-C0BA9BFDBDEC:21番目のURIは、バージョン識別子が87284370-2D4B-4e3d-A3F3-F303D2F4F34B::rmh.nhs.net:2である、すなわち、net.nhs.rmhとして識別されるEHRにおいて生成され、GUIDで識別されるバージョン付きオブジェクトの2番目の主要バージョンである最上位項目を識別する。2番目も同様であるが、別のGUIDが生成システムを識別するために用いられている。バージョン識別子によるシステムへの言及は、要求されたEHRがそのシステムであることを意味するものではなく、単に探索された最上位オブジェクトがそのシステムで生成されたことを意味することに注意されたい。system.もしバージョン識別子への言及がなければ、常に'latest_trunk_version'であるものと想定される。EHRの最小粒度の項目への参照を構築することができる。idに言及することはない。すべてのopenEHRのドキュメントにおいて、"属性(attribute)"という用語はオブジェクト指向における"オブジェクトのプロパティ"の意味で用いられている。XMLにおけるタグ中に現れる名前の値を意味しない。ここで記述された構文は、XMLインスタンスへの字義通りのマッピングを必ずしも考慮に入れたものではなく、むしろオブジェクト指向のデータ構造への論理的なマッピングが考慮されている。athttp://trac.edgewall.org/。