wiki:Archtectural Overview Versioning

TOC PREV NEXT

この文書はArchtectural Overview8 Versioningの翻訳である。内容の正確性については保証しないので,正確な内容については原文を参照すること

8 バージョニング

8 Versioning

8.1 概要

8.1 Overview

更新管理はopenEHRアーキテクチャでは欠くことのできない部分である。EHRに対するopenEHRのリポジトリやデモグラフィック情報は変更を制御するために集められた「バージョンコンテナ」(comon.change_controlパッケージのVERSION_OBJECT<T>クラスによりモデル化されている。)として管理される。それぞれが最上位のコンテンツ構造(CompositionやPartyといったもの)のバージョン情報を変更がなされる度に持っている。バージョン管理された最上位のコンテンツ構造を図23に示す。

Version control is an integral part of the openEHR architecture. An openEHR repository for EHR or demographic information is managed as a change-controlled collection of "version containers" (modelled by the VERSIONED_OBJECT<T> class in the common.change_control package), each containing the versions of a top-level content structure (such as a Composition or Party) as it changes over time. A version-controlled top-level content structure is visualised in FIGURE 23.

最上位構造単体でのバージョニングは必要ではあるが,一貫性,追跡可能性,永続性,巻き戻しやデータの過去の状態を法廷で検証できることもサポートするようなリポジトリが備えていなくてはならない要件を満たしてはいない。「変更制御」を支援する機能も必要となる。統制のとれた変更制御の仕組みでは、変更は最上位構造に任意に行われるのではなくリポジトリ自体に対して行われる。変更は「Contribution」と呼ばれるまとまった変更形式(change-sets)により行われ,リポジトリ内部で制御された項目の新しいあるいは変更されたバージョンを保持している。Change-setの重要な特徴は、トランザクションのように機能し、リポジトリを一貫した状態から他の状態に移行させることである。それに対して、任意の変更の組み合わせによってのみで制御された項目は容易に不整合を起こし,臨床データが関連するところでさえ危険な誤りを起こすこともある。

Versioning of single top-level structures is a necessary, but not sufficient requirement for a repository that must provide coherence, traceability, indelibility, rollback, and support for forensic examination of past states of the data. Features supporting "change control" are also required. Under a disciplined change control scheme, changes are not made arbitrarily to single top-level structures, but to the repository itself. Changes take the form of change-sets, called "Contributions", that consist of new or changed versions of the controlled items in the repository. The key feature of a change-set is that it acts like a transaction, and takes the repository from one consistent state to another, whereas arbitrary combinations of changes to single controlled items could easily be inconsistent, and even dangerously wrong where clinical data are concerned.

これらの概念は構成管理(configuration management; CM)としてよく知られており,今日ではフリーソフトウェアや商用製品を含めて、多くのソフトウェアの変更管理システムの基盤として使われている。これがopenEHRのアーキテクチャにおいて中心的な設計の特徴となっている。以下のセクションでもっと詳細を述べる。

These concepts are well-known in configuration management (CM), and are used as the basis for most software and other change management systems, including numerous free and commercial products available today. They are a central design feature of openEHR architecture. The following sections provide more details

8.2 構成管理パラダイム

8.2 The Configuration Management Paradigm

「構成管理」(configuration management; CM)のパラダイムはソフトウェア工学でよく知られており、IEEE標準にもなっている1。構成管理はリポジトリ内のアイテム(かつては,「構成アイテム」(configuration items; CI)と呼ばれていた)の変更を管理・制御することであり、同時に変更される明確な情報アイテムの論理的リポジトリに関連付けられている。健康情報システムでこのような官吏をするためには少なくとも二つの情報が必要となる。それは電子化された健康記録(electronic health records; EHR)とデモグラフィック情報である。過去のほとんどの分析では、変更管理の必要性については、変更についての監査証跡のための特定の要求や、リポジトリの以前の状態が使えるかどうかなどについて表現されてきた。openEHRでは、形式をもち、変更管理の汎用モデルとなり、健康情報にどのように適用できるかをしめすことを目標としている。

The "configuration management" (CM) paradigm is well-known in software engineering, and has its own IEEE standard1. CM is about managed control of changes to a repository of items (formally called "configuration items" or CIs), and is relevant to any logical repository of distinct information items which changes in time. In health information systems, at least two types of information require such management: electronic health records, and demographic information. In most analyses in the past, the need for change management has been expressed in terms of specific requirements for audit trailing of changes, availability of previous states of the repository and so on. In openEHR, the aim is to provide a formal, general-purpose model for change control, and show how it applies to health information.

8.2.1 リポジトリの構成

8.2.1 Organisation of the Repository

ソフトウェアリポジトリやEHRを構成するような複雑な情報アイテムのリポジトリの一般的な構成は以下のとおりである

The general organisation of a repository of complex information items such as a software repository, or the EHR consists of the following:

  • 多くの明確な情報モデルアイテム、あるいは構成アイテム。それぞれ固有のものであると識別され,内部の複雑性を保持していてもよい。
  • オプションで構成アイテムを組織化するディレクトリシステム。
  • 第一にバージョンをつけられたアイテムと正確に対応できるよう関連付けられた他の環境情報。例えば、アイテムを作るために使われるツールのバージョン。
  • a number of distinct information items, or configuration items, each of which is uniquely identified, and may have any amount of internal complexity;
  • optionally, a directory system of some kind, in which the configurations items are organised;
  • other environmental information which may be relevant to correctly interpreting the primary versioned items, e.g. versions of tools used to create them.

ソフトウェアや文書のリポジトリでは,構成アイテムはファイルシステムのディレクトリに配置したファイルとなる。構成アイテムとは、openEHRを基盤としたEHRでは、Compositionであり、オプションでFolder構造を持ち,デモグラフィックサービスなどではPartyである。Contributionはユーザーによってリポジトリに作られる。この一般的な抽象概念を図24に示す。

In a software or document repository, the CIs are files arranged in the directories of the file system; in an EHR based on openEHR, they are Compositions, the optional Folder structure, Parties in the demographic service and so on. Contributions are made to the repository by users. This general abstraction is visualised in FIGURE 24.

8.2.2 変更管理

8.2.2 Change Management

変更は構成アイテム単独で起こらず,リポジトリ全体に起こる。以下のような変更が起こりうる。

Change doesn't occur to Configuration Items in isolation, but to the repository as a whole. Possible types of change include:

  • 新しい構成アイテムの作成
  • 構成アイテムの削除
  • 構成アイテムの変更
  • ディレクトリ構造の部分削除や変更、作成
  • ディレクトリ構造の別の場所に構成情報を移動
  • 既存の構成アイテムの証明
  • creation of a new CI;
  • removal of a CI;
  • modification of a CI;
  • creation of, change to or deletion of part of the directory structure;
  • moving of a CI to another location in the directory structure;
  • attestation of an existing CI.

構成管理の目的は以下について確実に行うことである ssd.dyndns.info/Diary/ The goal of configuration management is to ensure the following:

  • リポジトリが常に整合性のある状態であること
  • リポジトリを以前のどの状態にでも再構成できること
  • 全ての変更が監査証跡されていること
  • the repository is always in a valid state;
  • any previous state of the repository can be reconstructed;
  • all changes are audit-trailed.

8.3 変更時間の管理

8.3 Managing Changes in Time

リポジトリを適切に変更管理するには2つの機構が必要である。第1に、バージョン制御はそれぞれの構成アイテムのバージョンとそれが一つであればディレクトリ構造も管理するために使用される。第2に、openEHRではcontributoinとして知られている「change-set」の概念である。これはユーザーによって個々の構成アイテム(とEHRの最上位構造)に論理的変化をもたらすように加えられた変化の集合のことである。たとえば,文書リポジトリで複数のファイル(CIs)を含む文書に論理的な変更が加えられるような更新がなされるような場合である。そこには複数のファイル(CIs)からなる文書の変化を含む1つのCONTRIBUTIONに対応したリポジトリがあるだけである。EHRではCONTRIBUTOINは1つのCOMPOSITIONよりも多くの変更が加わることがあり,FOLDER構造にも変更が加わることもある。EHRに対するどのような変更であってもCONTRIBUTIONが必要である。アイテムに対して起こりうる種類の変更でCONTRIBTIONに影響するものは,

Properly managing changes to the repository requires two mechanisms. The first, version control, is used to manage versions of each CI, and of the directory structure if there is one. The second is the concept of the "change-set", known as a contribution in openEHR. This is the set of changes to individual CIs (and other top-level structures in the EHR) made by a user as part of some logical change. For example, in a document repository, the logical change might be an update to a document that consists of multiple files (CIs). There is one Contribution, consisting of changes to the document file CIs, to the repository. In the EHR, a Contribution might consist of changes to more than one Composition, and possibly to the organising Folder structure. Any change to the EHR requires a Contribution. The kinds of changes that can occur to items affected in a Contribution are:

  • 新しいアイテムの追加: 新しいVERSIONコンテナが作成され最初のVERSIONが加えられる
  • アイテムの削除: データ属性をVOIDに設定された新しいバージョンが作成されて既存のVERSIONコンテナに加えられる
  • アイテムの変更: アイテムの内容の変更された形式を含むデータを持つVERSIONが作成され,既存のVERSIONコンテナ(これは論理的更新や修正の際にもなされることがある)に加えられる。
  • アイテムのインポート: 新しい'import'VERSIONが作成され,それを取り入れたVERSIONに組み込まれる
  • アイテムの証明: 新しいATTESTATIONが既存のVERSIONのATTESTATIONリストに加えられる
  • addition of new item: a new Version container is created and a first Version added to it;
  • deletion of item: a new Version whose data attribute is set to Void is added to an existing Version container;
  • modification of item: a new Version whose data contains the updated form of the item content is added to an existing Version container (this may be done for a logical update or correction);
  • import of item: a new `import' Version is created, incorporating the received Version;
  • attestation of item: a new Attestation is added to the attestations list of an existing Version.

典型的なリポジトリ変更の手順は図25に示されている

A typical sequence of changes to a repository is illustrated in FIGURE 25.

この図には,4つのCONTRIBUTION(左側に青い楕円で示されている)の多くのCI(ディレクトリツリーは単純のため示さない)を含むリポジトリに対する影響が示されている。CONTRIBUTIONが作成されることにより,リポジトリにもある種の変更が加えられる。第1に,新しいCIが1つ作り出されて,ほかの3つのCIも修正される(変更は「C」の三角形で示されている)。第2のCONTRIBUTIONは新しいCIを一つ作成することにしか影響しない。第3番目は作成されると作成されることで2つの変更がなされ,一方で4番目はひとつの変更しかなされない。(FOLDER構造への変更はここでは示していない)

This shows the effect of four Contributions (indicated by blue ovals on the left hand side) to a repository containing a number of CIs (the directory tree is not shown for the sake of simplicity). As each Contribution is made, the repository is changed in some way. The first brings into existing a new CI, and modifies three others (changes indicated by the `C' triangles). The second Contribution causes the creation of a new CI only. The third causes a creation as well as two changes, while the fourth causes only a change. (Changes to the folder structure are not shown here).

図25でCONTRIBUTIONは,たとえば,レコードに対すして起こっている正確な更新などの差分の集合として文学的に記述されているかのように示されている。こうして,第1のCONTRIBUTIONは集合{CIw, Ca1, Cc1, Cd1}などとなる。これが文学的に真に正しいかどうかは永続的解決を構築できるかどうかによっている。ある条件では,CIのいくつかはユーザーが現在のリストを見て,直ちに変更を入力するようなものである。このような状況は図25で示されているが,ほかにも図26に示すようにシステムがこれらのCIについての現在の状態をユーザが編集して,バージョンを更新することもある。アプリケーションによってはどちらもお子の会うものもあり,どのCIが更新されるかによるものもある。内部バージョンの実装は差分をどのように効率よく保存するかによるところもあり,そうでないところもある。

One nuance which should be pointed out is that in FIGURE 25 Contributions are shown as if they are literally a set of deltas, i.e. exactly the changes which occur to the record. Thus, the first Contribution is the set {CIw, Ca1, Cc1, Cd1} and so on. Whether this is literally true depends on the construction of the persistence solution. In some situations, some CIs may be updated by the user viewing the current list and entering just the changes - the situation shown in FIGURE 25; in others, the system may provide the current state of these CIs for editing by the user, and submit the updated versions, as shown in FIGURE 26. Some applications may do both, depending on which CI is being updated. The internal versioning implementation may or may not generate deltas as a way of efficient storage.

openEHRの目的のため,CONTRIBUTIONは図26で実装されるような作成されると同時に証明されたVERSIONの集合であると考えられている。

For the purposes of openEHR, a Contribution is considered as being the set of Versions created or attested at one time, as implied by FIGURE 26.

8.3.1 変更制御されたリポジトリの汎用モデル

8.3.1 General Model of a Change-controlled Repository

図27には以下に示す内容を含む変更管理リポジトリの抽象モデルが示されている。

FIGURE 27 shows an abstract model of a change-controlled repository, which consists of:

  • バージョン管理された設定アイテム - VERSION_OBJECT<T>のインスタンス
  • CONTRIBUTION
  • オプションとしてFOLDERのディレクトリシステム。FOLDERが使われれば,FOLDER構造も一単位としてバージョン管理されなければならない。
  • version-controlled configuration items - instances of VERSIONED_OBJECT<T>;
  • CONTRIBUTIONs;
  • an optional directory system of folders. If folders are used, the folder structure must also be versioned as a unit.

The actual type of links between the controlled repository and the other entities might vary - in some cases it might be association, in others aggregation; cardinalities might also vary. FIGURE 27 therefore provides a guide to the definition of actual controlled repositories, such as an EHR, rather than a formal specification for them.

8.4 「仮想バージョンツリー」

8.4 The "Virtual Version Tree"

openEHRで定義されているバージョニングモデルの基本となる設計コンセプトは,「仮想バージョンツリー」として知られている。この概念は単純に抽象化されている。情報はリポジトリ(EHRのような)にまとめてコミットされると,それぞれのまとまりにひとつのバージョン「データ」がつけられる。バージョンにはそれぞれ,順々にVERSIONオブジェクト(あるいは「バージョンコンテナ」)の内部にあるバージョンツリー内に位置づけられている。仮想バージョンツリーの概念では,既存のVERSIONオブジェクトははさまざまなシステムに数多くのコピーを持つことになる。そして,すべてのバージョンが作成されるような方法でバージョンを作成することと,すべてのコピーをバージョンツリーに合成した結果として「仮想」バージョンツリーとは実際に互換性を持つ。これはバージョンを識別するのに単純な方法を使って得られたことであり,データを共有しやすくするためのものでもある。二つのきわめて一般的なシナリオが仮想バージョンツリーの概念によってその役割を果たしている。

An underlying design concept of the versioning model defined in openEHR is known as a "virtual version tree". The idea is simple in the abstract. Information is committed to a repository (such as an EHR) in lumps, each lump being the "data" of one Version. Each Version has its place within a version tree, which in turn is maintained inside a Versioned object (or "version container"). The virtual version tree concept means that any given Versioned object may have numerous copies in various systems, and that the creation of versions in each is done in such a way that all versions so created are in fact compatible with the "virtual" version tree resulting from the superimposition of the version trees of all copies. This is achieved using simple rules for version identification and is done to facilitate data sharing. Two very common scenarios are served by the virtual version tree concept:

  • 「処方」や「問題リスト」といった患者の状態をしめす代替となる長期にわたるデータ(openEHRでは永続的COMPOSITION)が医療機関や介護機関で作成され,そのほかの多くの施設にわたって共有されるように維持管理される
  • あるひとつの場所にあるEHRサーバ内のEHRがほかのEHRサーバにミラーリングされる(たとえば,関連のある患者が同じように治療を受けるケア事業者)。ミラーリング処理はサーバ間で継ぎ目なく,位置や時間,データを作成した著者にかかわりなく非同期に同期されることが要求されている。
  • longitudinal data that stands as a proxy for the state or situation of the patient such as "Medications" or "Problem list" (persistent Compositions in openEHR) is created and maintained in one or more care delivery organisations, and shared across a larger number of organisations;
  • some EHRs in an EHR server in one location are mirrored into one or more other EHR servers (e.g. at care providers where the relevant patients are also treated); the mirroring process requires asynchronous synchronisation between servers to work seamlessly, regardless of the location, time, or author of any data created.

openEHRのバージョニングの仕組みはデータが作成されたりコピーされた場所を問わないこと,共有する際に矛盾がないこと,論理的コピーが明示的に表されることが保証されている。それにより共有されるケアの内容についてのデータの共有について直接的に支援している。

The versioning scheme used in openEHR guarantees that no matter where data are created or copied, there are no inconsistencies due to sharing, and that logical copies are explicitly represented. It therefore provides direct support for shared data in a shared care context.


  1. 1. IEEE 828-2005 - standard for Software Configuration Management Plans.

1IEEE 828-2005 - standard for Software Configuration Management Plans.

TOC PREV NEXT

Last modified 10 years ago Last modified on Apr 18, 2008, 10:19:49 PM

Attachments (5)

Download all attachments as: .zip