| 17 | | 2. バックエンド・サービス： EHR、デモグラフィック、用語体系、アーキタイプ、セキュリティ、レコードのロケーション等を含む。この層では、異なるサービスの分離は透過的であり、各サービスは粒度の荒いサービス・インターフェースを持っている。 |
| 18 | | |
| 19 | | 2. back-end services: including EHR, demographics, terminology, archetypes, security, record location, and so on. In this layer, the separation of the different services is transparent, and each service has a coarse-grained service interface. |
| 20 | | |
| 21 | | 3. 仮想EHR： この層はミドルウェアであり、関連するサービスへのアクセスを提供するさまざまなバックエンド・サービスへの一貫したAPIセットを持っている。これによりユーザーは、EHR、デモグラフィック、セキュリティ、用語体系、及びアーキタイプ・サービスを含むEHRへのアクセスが可能となる。ここにはアーキタイプ駆動及びテンプレート駆動のカーネルも含まれ、このコンポーネントはアーキタイプ駆動データの生成と処理の役割を担う。この層にでは、バックエンド・サービスの分離は隠蔽されており、機能だけが開示される。バックエンド・サービスの他の組合わせのためのAPIを含め、他の仮想クライアントも可能である。 |
| 22 | | |
| 23 | | 3. virtual EHR: this tier is the middleware, and consists of a coherent set of APIs to the various back-end services providing access to the relevant services, thereby allowing user access to the EHR; including EHR, demographics, security, terminology, and archetype services. It also contains an archetype- and template-enabled kernel, the component responsible for creating and processing archetype-enabled data. In this tier, the separation of back-end services is hidden, only the functionality is exposed. Other virtual clients are possible, consisting of APIs for other combinations of back-end services. |
| 24 | | |
| 25 | | 4. アプリケーション・ロジック： この層は、ユーザー・アプリケーションやクエリ・エンジンのような別のサービスといった、なんであれアプリケーション固有のロジックから成る。 |
| 26 | | |
| 27 | | 4. application logic: this tier consists of whatever logic is specific to an application, which might be a user application, or another service such as a query engine. |
| 28 | | |
| 29 | | 5. プレゼンテーション層： この層は、それが利用可能な場合に、アプリケーションのグラフィカル・インターフェースから成る。 |
| 30 | | |
| 31 | | 5. presentation layer: this layer consists of the graphical interface of the application, where applicable. |
| | 19 | 1. persistence: data storage and retrieval. |
| | 20 | 1. back-end services: including EHR, demographics, terminology, archetypes, security, record location, and so on. In this layer, the separation of the different services is transparent, and each service has a coarse-grained service interface. |
| | 21 | 1. virtual EHR: this tier is the middleware, and consists of a coherent set of APIs to the various back-end services providing access to the relevant services, thereby allowing user access to the EHR; including EHR, demographics, security, terminology, and archetype services. It also contains an archetype- and template-enabled kernel, the component responsible for creating and processing archetype-enabled data. In this tier, the separation of back-end services is hidden, only the functionality is exposed. Other virtual clients are possible, consisting of APIs for other combinations of back-end services. |
| | 22 | 1. application logic: this tier consists of whatever logic is specific to an application, which might be a user application, or another service such as a query engine. |
| | 23 | 1. presentation layer: this layer consists of the graphical interface of the application, where applicable. |
| 38 | | ・ RM and AM: 主としてアーキタイプ処理及びテンプレート処理カーネルを構築するために使用される。 |
| 39 | | ・ RM common.change_control パッケージ: EHRやデモグラフィックのようなバージョン付きサービスにおけるバージョニング・ロジックを提供する。 |
| 40 | | ・ SM: 各種のサービスモデル・パッケージが主要なサービスの公開インターフェースを定義する。 |
| 41 | | ・ SM virtual_ehr パッケージは、仮想EHRコンポーネントのAPIを定義する。 |
| 42 | | ・ アーキタイプ: アーキタイプは直接いくつかのアプリケーションになるものと想定されている。たとえば、周産期スペシャリスト・パッケージは、この専門分野のアーキタイプ系列に部分的に依拠していると想定される。 |
| 43 | | ・ テンプレート: アーキタイプとテンプレートは、アプリケーションのプレゼンテーション層で使用されるであろう。GUIコードをかぶせる場合と、特定のテンプレートやアーキタイプに基づいてツールでコードを生成したり、ダイナミックにフォームを生成させる場合とがあろう。 |
| | 30 | * RM and AM: 主としてアーキタイプ処理及びテンプレート処理カーネルを構築するために使用される。 |
| | 31 | * RM common.change_control パッケージ: EHRやデモグラフィックのようなバージョン付きサービスにおけるバージョニング・ロジックを提供する。 |
| | 32 | * SM: 各種のサービスモデル・パッケージが主要なサービスの公開インターフェースを定義する。 |
| | 33 | * SM virtual_ehr パッケージは、仮想EHRコンポーネントのAPIを定義する。 |
| | 34 | * アーキタイプ: アーキタイプは直接いくつかのアプリケーションになるものと想定されている。たとえば、周産期スペシャリスト・パッケージは、この専門分野のアーキタイプ系列に部分的に依拠していると想定される。 |
| | 35 | * テンプレート: アーキタイプとテンプレートは、アプリケーションのプレゼンテーション層で使用されるであろう。GUIコードをかぶせる場合と、特定のテンプレートやアーキタイプに基づいてツールでコードを生成したり、ダイナミックにフォームを生成させる場合とがあろう。 |
| 46 | | ・ RM and AM: mainly used to construct an archetype- and template-processing kernel; |
| 47 | | ・ RM common.change_control package: provides the logic for versioning in versioned services such as the EHR and demographics; |
| 48 | | ・ SM: various service model packages define the exposed interfaces of major services; |
| 49 | | ・ SM virtual_ehr package defines the API of the virtual EHR component; |
| 50 | | ・ archetypes: archetypes might be assumed directly in some applications, e.g. a specialist peri-natal package might be partly based on a family of archetypes for this specialisation; |
| 51 | | ・ templates: both archetypes and templates will be used in the presentation layer of applications. Some will base the GUI code on them, while others will have either tool-generate code, or dynamically generate forms based on particular templates and archetypes |
| | 38 | * RM and AM: mainly used to construct an archetype- and template-processing kernel; |
| | 39 | * RM common.change_control package: provides the logic for versioning in versioned services such as the EHR and demographics; |
| | 40 | * SM: various service model packages define the exposed interfaces of major services; |
| | 41 | * SM virtual_ehr package defines the API of the virtual EHR component; |
| | 42 | * archetypes: archetypes might be assumed directly in some applications, e.g. a specialist peri-natal package might be partly based on a family of archetypes for this specialisation; |
| | 43 | * templates: both archetypes and templates will be used in the presentation layer of applications. Some will base the GUI code on them, while others will have either tool-generate code, or dynamically generate forms based on particular templates and archetypes |
