この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
導入
0.1 一般
この文書は、ウィーン協定を通じて CEN と ISO が共同で発行した 5 部構成の標準シリーズの一部です。このドキュメントでは、このシリーズの他の部分への依存関係が適用されるwhere 明示的に述べられています。
0.2 序文
この文書は、EHR_EXTRACT, ARCHETYPE, または EHR_AUDIT_LOG_EXTRACT を要求および提供できるインターフェースを定義します。
この文書の範囲は、次のいくつかの目的を達成するために慎重に検討されています。
- 13606 コンテキストに固有のインターフェイスを指定し、他の規格や仕様の範囲となる可能性のあるより一般的な健康情報通信インターフェイスを含めないこと。
- HISA 標準シリーズ (ISO 12967 のすべての部分) と互換性のある方法でインターフェイスを指定する。
- 個々のベンダーや eHealth プログラムによって採用される可能性のある幅広いエンジニアリングの観点をサポートするために、インターフェイスを計算の観点として指定する。 (ISO 13606-1, ISO 13606-2, および ISO 13606-4 は対応する情報の観点を定義し、ISO 18308 は対応する企業の観点を定義することに注意してください)
- Java, Visual Basic, dotnet, SOAP, ebXML などの一般的に使用されるエンジニアリング言語内の標準インターフェイスの特殊化として簡単に実装できるように、これらのインターフェイスを構築する。
- 合同 SDO イニシアチブおよび評議会を通じて、たとえば HL7 バージョン 3 でこれらのインターフェイスを実装する方法をより具体的に定義するエンジニアリング ビューポイント実装ガイドの作成に取り組みます。これらのガイドは、標準文書よりも頻繁に (実装経験を反映するために) 保守および更新できるようにするために、ISO 13606-5 とは別に発行されます。
- EHR コミュニケーションは、通常は全国的なヘルスケア コミュニケーション インフラストラクチャ内で実装され、患者人口統計レジストリ、プロバイダー レジストリ、認証と認可のポリシーとサービスなど、他の多くの補完的で必要なサービスへの一般化されたアプローチが定義されることを認識する。したがって、これらは ISO 13606-5 の正式な範囲の一部ではありませんが、想定され必要な補完サービスとして参照されます。
- ISO/TS 22600 シリーズ (PMAC) 互換アーキテクチャまたは同等のアーキテクチャがセキュリティ サービスの管理に使用されることを要求し、この文書でこれらのサービスと重複したり競合したりしないこと。
- リクエストに応答する際にプロバイダーによって EHR データが保留されているかどうかを明らかにする必要を回避することで、患者のプライバシーの保護をさらにサポートします。
- 各インターフェイスと用語セットをローカルで拡張して、追加の要件制約が適用される可能性がある EHR 通信の特殊な状況に対応できるようにします。
この文書は、ISO 13606-1, ISO 13606-2, および ISO 13606-4 で定義されたアーティファクトを要求および提供できる一連のインターフェイスを定義します。
- a) ISO 13606-1 は、EHR_EXTRACT (治療対象の EHR の一部またはすべて) の参照モデルを定義します。
- b) ISO 13606-2 は ARCHETYPE の情報モデルを定義し、オプションでアーキタイプ定義言語を使用して表現されるシリアル化された形式を定義します。
- c) ISO 13606-4 は、EHR の一部またはすべてに関する監査ログ アクティビティ履歴を伝達するための EHR_AUDIT_LOG_EXTRACT を定義します。
(ISO 13606-3 は、直接インターフェイスが不要な用語リストと参照アーキタイプを定義します。ISO 13606-4 は、直接インターフェイスも必要としないアクセス ポリシー モデルを定義します。)
このドキュメントでは、 EHR_requester (アーティファクトの通信を希望し、その通信を許可する)、 EHR_provider (リクエストされたアーティファクトを含み、返すことができるリポジトリ サービス)、およびEHR_recipient間の通信として、上記の ac のそれぞれに 1 つずつ、3 つのインターフェイスを定義します。は、アーティファクトを受信することを目的としており、その受信を許可されています (通常はEHR_requesterと同じですが、常に同じであるわけではありません)
これらのインターフェースはすべて計算視点仕様として表現されており、メッセージ プロトコル (EDIFACT, HL7 バージョン 3 など) やサービス プロトコル (SOAP, Java RMI など) など、さまざまなエンジニアリング 視点 (トランスポート) 形式を通じて実装をサポートすることを目的としています。したがって、この文書では、各インターフェイスで通信される「ペイロード」情報のみを指定します。メッセージ識別子、メッセージのタイムスタンプ、メッセージのバージョン管理などの属性は、通常、各種類のトランスポート プロトコルによって特定の方法で定義および処理されるため、この文書ではこの種の情報の独自の重複を定義しません。 ISO 13606-1 で定義された EHR_EXTRACT, ISO 13606-2 で定義された ARCHETYPE, および ISO 13606-4 で定義された EHR_AUDIT_LOG_EXTRACT にはすべて、ペイロード データのタイムスタンプ、作成者、バージョン管理情報が含まれていることに注意してください。彼らの情報モデル。
要求の確認応答とシステム/通信エラー メッセージは、ほとんどのエンジニアリング トランスポート プロトコルによって日常的に処理されます。この文書がこれらを複製することも適切ではありません。オプションの例外は、機密性を侵害することなくこれを明らかにすることが正当である場合に、リクエストが受信されたが拒否された理由を EHR_requester に返すために定義されます。
EHR_requester は、ローカルで決定される方法で EHR_provider に対して認証する必要があり、これもこの文書の範囲を超えていますが、ISO 22600 シリーズ (PMAC) で指定されている認可資格情報を提示します。 EHR_requester が EHR_provider に EHR_EXTRACT を第三者に「送信」することを望む場合があることが認識されています。この文書は、EHR_requester が他の当事者に代わって動作する委任アーキテクチャ内で使用できますが、委任に含まれる承認階層の表現と伝達は、特権管理およびアクセス制御アーキテクチャの問題であり、直接影響を与えるものではありません。この文書について。あるいは、第三者が推奨する特定の RECORD_COMPONENT の一意の参照 (たとえば、COMPOSITION の ehr-id および rc_id を介した特定の手紙または退院概要) を第三者に安全に伝達するために、ローカルな取り決めが行われてもよい。には、委任を使用する必要がなく、直接アクセスする権限があります。
Introduction
0.1 General
This document is part of a five-part standard series, published jointly by CEN and ISO through the Vienna Agreement. In this document, dependency upon any of the other parts of this series is explicitly stated where it applies.
0.2 Preface
This document defines the interfaces by which an EHR_EXTRACT, an ARCHETYPE or an EHR_AUDIT_LOG_EXTRACT may be requested and provided.
The scope of this document has been considered carefully in order to achieve several objectives:
- to specify those interfaces that are unique to the 13606 context, and not to include more generic health information communication interfaces that might be the scope of other standards and specifications;
- to specify the interfaces in ways that are compatible with the HISA standard series (ISO 12967 all parts);
- to specify the interfaces as computational viewpoints, in order to support the wide range of engineering viewpoints that might be adopted by individual vendors or eHealth programmes; (it should be noted that ISO 13606-1, ISO 13606-2 and ISO 13606-4 define the corresponding information viewpoints, and that ISO 18308 defines the corresponding enterprise viewpoint);
- to construct these interfaces such that they might easily be implemented as specialisations of standard interfaces within the commonly used engineering languages such as Java, Visual Basic, dotnet, SOAP, ebXML etc.;
- to work through the Joint SDO Initiative and Council on the production of Engineering Viewpoint Implementation Guides, that will define more specifically how to implement these interfaces, for example in HL7 version 3; these guides will be published separately from ISO 13606-5, to enable them to be maintained and updated more frequently (to reflect implementation experience) than is possible for a standards document;
- to recognise that EHR communication will be implemented within a healthcare communications infrastructure, usually nationally, that will define a generalised approach to many other complementary and necessary services such as patient demographics registries, provider registries, authentication and authorisation policies and services etc.; these are therefore not part of the formal scope of ISO 13606-5 but are referred to as being assumed and necessary complementary services;
- to require an ISO/TS 22600 series (PMAC) compatible architecture or its equivalent will be used for managing security services, and not to duplicate or conflict with these services in this document;
- to further support the protection of patient privacy by avoiding the need to reveal if any EHR data has been withheld by the provider when responding to a request;
- to enable each interface and term set to be extended locally to cater for specialised circumstances of EHR communication, in which additional requirements constraints might apply.
This document defines a set of interfaces by which the artefacts defined in ISO 13606-1, ISO 13606-2 and ISO 13606-4 may be requested and provided:
- a) ISO 13606-1 defines a reference model for an EHR_EXTRACT: part or all of the EHR of a subject of care;
- b) ISO 13606-2 defines an information model for an ARCHETYPE, and optionally a serialised form represented using Archetype Definition Language;
- c) ISO 13606-4 defines an EHR_AUDIT_LOG_EXTRACT to communicate the audit log activity history pertaining to part or all of an EHR.
(ISO 13606-3 defines term lists and reference archetypes, to which a direct interface is not required. ISO 13606-4 defines an access policy model to which a direct interface is also not required.)
This document defines three interfaces, one for each of a-c above, as a communication between an EHR_requester (wishing to and authorising the communication of the artefact), an EHR_provider (a repository service that contains and can return the requested artefact) and an EHR_recipient who is intended and authorised to receive the artefact (usually but not always the same as the EHR_requester).
These interfaces are all expressed as Computational Viewpoint specifications and aim to support implementation through many different Engineering Viewpoint (transport) formalisms, such as message protocols (e.g. EDIFACT, HL7 version 3) or service protocols (e.g. SOAP, Java RMI). This document therefore specifies only the “payload” information to be communicated at each interface. Attributes such as message identifiers, message time-stamping and message version management are normally defined and handled by each kind of transport protocol in particular ways, and this document therefore does not define its own duplication of this kind of information. It should be noted that the EHR_EXTRACT defined in ISO 13606-1, the ARCHETYPE defined in ISO 13606-2, and the EHR_AUDIT_LOG_EXTRACT defined in ISO 13606-4 all include time-stamping, authorship and version management information of the payload data as part of their information models.
Request acknowledgements and system/communication error messages are routinely handled by most engineering transport protocols. It is also not appropriate that this document duplicates these. An optional exception is defined to communicate back to the EHR_requester a reason why a request has been received but refused, if it is legitimate to reveal this without breaching confidentiality.
The EHR_requester will need to authenticate to the EHR_provider in ways that are to be locally determined, and will present authorisation credentials that are also beyond the scope of this document but are specified in the ISO 22600 series (PMAC). It is recognised that there might be times when an EHR_requester wishes the EHR_provider to “send” the EHR_EXTRACT to a third party. This document may be used within a delegation architecture, in which an EHR_requester acts on behalf of another party, but the representation and communication of the hierarchy of authorisations involved in delegation is a matter for the privilege management and access control architecture and does not directly impact on this document. Alternatively, local arrangements may be made to securely communicate to a third party a unique reference for any particular RECORD_COMPONENT (e.g. for a particular letter or discharge summary, via the ehr-id and rc_id of the COMPOSITION) that the third party is recommended to and has permission to access directly, without therefore requiring the use of delegation.