h1. CM Plan
openEHR リリース 1.0 パブリックコメント
openEHR Release 1.0 public comment
openEHR 変更マネジメント計画
編集：{ T Beale}
校訂版：1.0
頁数：37
The openEHR Change Management Plan
Editor:{T Beale}1
Revision: 1.0
Pages: 37
© 2003-2006 openEHR 財団
openEHR財団
は、消費者と医療者との保健医療記録共有の実現をオープンソースによる標準化を通じて推進する、独立した非営利のコミュニティです。
創設者会長 David Ingram, ロンドン大学医療情報学教授, CHIME.
創設メンバー P Schloeffel 博士, S Heard 博士, D Kalra 博士, D Lloyd 氏, T Beale 氏
email: info@openEHR.org web: http://www.openEHR.org
© 2003-2006 The openEHR Foundation
The openEHR foundation
is an independent, non-profit community, facilitating the creation and sharing
of health records by consumers and clinicians via open-source, standardsbased
implementations.
Founding David Ingram, Professor of Health Informatics, CHIME, University
Chairman College London
Founding Members Dr P Schloeffel, Dr S Heard, Dr D Kalra, D Lloyd, T Beale
email: info@openEHR.org web: www.openEHR.org
著作権についての注意事項
© openEHR 財団 2001-2005
無断複写・転載を禁じます。
この文書は、openEHR財団が全世界に所有する著作権乃至データベース権によって、保護されています。¶
個人的、非商業的な使用のために、本文書を読み、印刷することができます。¶
この文書（全体または一部）を、商業上の使用でなく、且つopenEHRについてコメントするか、openEHRの目標を追求するか、またはopenEHRについて第三者に知らせる目的である限り、プレゼンテーションおよび教育のために使用することができます。¶
本文書の使用にあたって、（第2項および第3項に基づき許容されるものを除き）いかなる変更、修正、追加、削除も行ってはならない。¶
この文書を使用する場合は必ず、次の様式の著作権表示を行わなければならない。¶
“© Copyright openEHR Foundation 2001-2005. All rights reserved. www.openEHR.org”
この文書は、学術コミュニティ向けのサービスおよび非商業的利用のために提供されている。したがってopenEHR財団は、その資料や文書とそれらの内容に関し、関係法令が許す限り、何ら責任を負うことは無く、何の保証もしない。¶
上記第１項から第6項に掲げる事由以外で、このサイトの資料や文書を、商業利用、ライセンス化、販売、配布、使用、複写することを希望する場合は、openEHR有償商業利用ライセンスの規約と条件に従うか、そうした活動を規定するopenEHR財団との個別的な同意文書を締結しなければならない。openEHR有償商業利用ライセンスの規約と条件は、次のURL：http://www.openehr.org/free_commercial_use.htm に掲載されている。¶
Copyright Notice
© Copyright openEHR Foundation 2001 - 2005
All Rights Reserved
This document is protected by copyright and/or database right throughout the world and is owned by the openEHR Foundation.¶
You may read and print the document for private, non-commercial use.¶
You may use this document (in whole or in part) for the purposes of making presentations and education, so long as such purposes are non-commercial and are designed to comment on, further the goals of, or inform third parties about, openEHR.¶
You must not alter, modify, add to or delete anything from the document you use (except as is permitted in paragraphs 2 and 3 above).¶
You shall, in any use of this document, include an acknowledgement in the form:¶
"© Copyright openEHR Foundation 2001-2005. All rights reserved. www.openEHR.org"
This document is being provided as a service to the academic community and on a non-commercial basis. Accordingly, to the fullest extent permitted under applicable law, the openEHR Foundation accepts no liability and offers no warranties in relation to the materials and documentation and their content.¶
If you wish to commercialise, license, sell, distribute, use or otherwise copy the materials and documents on this site other than as provided for in paragraphs 1 to 6 above, you must comply with the terms and conditions of the openEHR Free Commercial Use Licence, or enter into a separate written agreement with openEHR Foundation covering such activities. The terms and conditions of the openEHR Free Commercial Use Licence can be found at http://www.openehr.org/free_commercial_use.htm¶
修正記録
版番号 内容 修正者 完了日付
リリース 1.0
1.0 リリース版の細部を更新。 T Beale 2006.1.28
0.9 派生版へ移管したことによる変更。 T Beale 2005.7.28
0.8 『openEHRの概観』文書を分離。 T Beale 2005.2.04
0.7 管理、IP、プロジェクト概観の項目を追加。 T Beale
M Darlison 2005.1.10
0.6 UCLチームによる見直し。 D Kalra
T Austin
N Lea
D Lloyd
T Beale 2004.12.10
0.5.2 David Ingram教授(UCL)による見直し。 D Ingram 2004.2.20
0.5.1 Tim Cook Tim@openparadigms.com による再度の見直し。 T Cook 2003.12.10
0.5 ARB業務による開発の進展。 T Beale 2003.12.06
0.4 Tim Cook Tim@openparadigms.com による見直し；更なる開発。 T Cook
T Beale 2003.11.22
0.3 openEHR CMサイト公開準備のための更新。 T Beale 2003.11.15
0.2 5月のUCL訪問を更新。 T Beale 2003.5.13
0.1 最初の記載 T Beale 2003.1.20
謝辞
この論文は、ロンドン大学(UCL)とオーシャン・インフォマティクス社（オーストラリア）の出資を受けています。
Amendment Record
Acknowledgements
This paper has been funded by The University College, London and Ocean Informatics, Australia.
目次
１ はじめに
1.1 目的
1.2 読者
1.3 状態
1.4 用語と略号
２ あらまし
2.1 活動
2.2 マネジメント
3 openEHR 技術プロジェクト
3.1 仕様プロジェクト
3.2 参照実装プロジェクト
3.2 特別暫定実装プロジェクト
4 文書保管組織
4.1 リポジトリ命名規則
4.2 リポジトリ設計
5 リリース管理
5.1 あらまし
5.2 リリース構造と分岐
5.3 リリース命名規則
Table of Contents
1 Introduction.............................................................................. 7
1.1 Purpose...................................................................................................7
1.2 Audience ................................................................................................7
1.3 Status......................................................................................................7
1.4 Terms and Acronyms .............................................................................7
2 Overview ................................................................................... 8
2.1 Activities ................................................................................................8
2.2 Management...........................................................................................8
3 openEHR Technical Projects................................................. 12
3.1 The Specification project .....................................................................12
3.2 Reference Implementation Projects .....................................................14
3.3 Ad hoc Implementation Projects..........................................................14
4 Repository Organisation ........................................................ 16
4.1 Repository Naming ..............................................................................16
4.2 Repository Design................................................................................16
5 Release Management ............................................................. 18
5.1 Overview..............................................................................................18
5.2 Release Structure and Branching .........................................................18
5.3 Release Naming ...................................................................................20
6 変更マネジメント
6.1 あらまし
6.2 変更プロセス
6.2.1 あらまし
6.2.2 問題の報告
6.2.3 openEHR参照プロジェクトのための変更請求プロセス
6.2.3.1 業務手順
6.2.3.2 CRライフサイクル
6.2.3.3 プロジェクト・グループ-管理されたCR
6.2.3.3 レビュー委員会-管理されたCR
6.2.4 アドホックプロジェクトのための変更請求プロセス
6.2.4.1 業務手順
6.2.4.2 CRライフサイクル
6.2.4.3 CRマネジメント
6 Change Management ............................................................. 21
6.1 Overview..............................................................................................21
6.2 The Change Process.............................................................................22
6.2.1 Overview........................................................................................22
6.2.2 Problem Reporting.........................................................................23
6.2.3 Change Request Process for openEHR Reference Projects...........23
6.2.3.1 Workflow ....................................................................................................23
6.2.3.2 CR Lifecycle ...............................................................................................24
6.2.3.3 Project Group-managed CRs ......................................................................25
6.2.3.4 Review Board-managed CRs ......................................................................25
6.2.4 Change Request Process for ad hoc Projects .................................26
6.2.4.1 Workflow ....................................................................................................26
6.2.4.2 CR Lifecycle ...............................................................................................27
6.2.4.3 CR Management .........................................................................................27
7 ツール類
7.1 あらまし
7.2 設定マネジメントシステム
7.3 PR / CRデータベース
7.4 発行 / 配布
8 CIの識別
付録A 様式集
A.1 問題報告書様式
A.2 PR様式フィールド
A.3 変更請求様式
A.4 CR様式フィールド
7 Tools......................................................................................... 29
7.1 Overview..............................................................................................29
7.2 Configuration Management System ....................................................29
7.3 PR / CR Database ................................................................................30
7.4 Publishing/Distribution........................................................................30
8 CI Identification ..................................................................... 31
Appendix AForms ............................................................................ 33
A.1 Problem Report Form ..........................................................................33
A.2 PR Form Fields ....................................................................................33
A.3 Change Request Form..........................................................................34
A.4 CR Form Fields....................................................................................34
１ はじめに
1.1 目的
この文書の目的はopenEHR技術プロジェクト、つまり（文書『openEHRのご紹介』で解説された）openEHR技術スペース上でopenEHR開発環境により遂行されるプロジェクトのマネジメントを解説することにある。これらのプロジェクトには「管理された」成果物と、この文書によって定義された明確な問題報告と変更請求の戦略がある。二つの変更マネジメント戦略は、一つは参照プロジェクトのための「審査委員会」により行うもの、もう一つは特別暫定プロジェクトのための「審査委員会」なしで行うもの、と説明される。
1 Introduction
1.1 Purpose
The purpose of this document is to describe the management of openEHR technical projects, i.e. projects in the openEHR technical space (as described in the document Introducing openEHR) and carried out within the openEHR development environment. These projects have “controlled” deliverables, and a clear problem reporting and change request strategy, defined by this document. Two change management strategies are described: one with a “review board” for reference projects, and one without, for ad hoc projects.
1.2 読者
この文書の主たる読者は、openEHR財団のための仕様とソフトウェアの開発者である。
1.3 状態
この文書は、http://svn.openehr.org/specification/TAGS/Release-1.0/publishing/CM/CM_plan.pdf で入手できる。
この文書の最新版は、http://svn.openehr.org/specification/TRUNK/publishing/CM/CM_plan.pdf にある。
1.2 Audience
The primary audience for this document is developers of specifications and software for the openEHR Foundation.
1.3 Status
This document is available at http://svn.openehr.org/specification/TAGS/Release-1.0/publishing/CM/CM_plan.pdf.
The latest version of this document can be found at http://svn.openehr.org/specification/TRUNK/publishing/CM/CM_plan.pdf.
1.4 用語と略号
ARB (Architectural Review Board) アーキテクチャ審査委員会
CI (Configuration Item) 作物。例えば文書、ソース・ファイル、テスト事例など
CM (Configuration Management) 設定管理
IP (Intellectual property) 知的財産
PG (Project Group) プロジェクト・グループ
1.4 Terms and Acronyms
ARB Architectural Review Board
CI Configuration Item - any controlled artifact, such as a document, source file, test
case etc.
CM Configuration management
IP Intellectual property
PG Project Group
2 あらまし
2.1 活動
下図は、仕様および実装プロジェクトと、配布・展開活動を含む、openEHRの技術的活動領域を図示している。
技術的活動
仕様類
仕 様 アーキテクチャ ITSs
プロジェクト 要求事項
適合性
実 装 E H R 人口管理 アーキテクチャ
プロジェクト サーバー サーバー 解析プログラム ・・・
配 布 各 種 標準規格 適合性 教 育
活 動 ツール類 システム 業務提携 試 験 訓 練
図1 openEHR技術的活動
2 Overview
2.1 Activities
The figure below illustrates the technical activity areas of openEHR, including specification and implementation projects, and delivery/deployment activities.
図の左側の実線で囲まれている枠が、それぞれ一つのopenEHRプロジェクトである。図示したとおり、仕様、実装、知識、配布という4つの大きな活動領域がある。最初の2領域は、多くの人々がソフトウェア開発とみなしていることに対応し、その変更マネジメントが、この文書の主題である。これら2領域のプロジェクトは、第3節の12頁で更に詳しく説明している。
Each solid-line bubble on the left part of the diagram is a project in openEHR. As shown, there are four major areas of activity: specification, implementation, knowledge, and delivery. The first two correspond to what most people would think of as software development; their change management is the subject of this document. The projects in these two groups are described in more detail in section 3 on page 12.
2.2 マネジメント
openEHRの技術的空間では、プロジェクト・グループ(PGs)によって作業が行われ、場合によっては、アーキテクチャ審査委員会(ARB)がそれらを監督している。ARBは8名、またはそれ以上のopenEHRの国際的メンバーで構成され、全員が医療情報の分野で長い経験を持っている。ARBの現在の構成は、openEHRウエブサイトのARB pageでみることができる。ARBの役割は、あるプロジェクトに大きなインパクトがあるか、またはプロジェクト開発グループがそれ自身では解決できない変更を要求することについて、判断することである。決定は、単純多数決の方法で行っている。
2.2 Management
In the technical space of openEHR, work is performed by project groups (PGs), which are in some cases overseen by the Architectural Review Board (ARB). The ARB consists of a eight or more international members of openEHR, all with long-term experience in an area of health informatics. The current makeup of the ARB may be found on the openEHR website ARB page. The ARB’s function is to review and make decisions on requests for change that either have significant impact on a project, or that cannot be resolved by the project development group on its own. It operates using simple majority voting.
プロジェクトの種類
プロジェクト・グループは、一つのプロジェクトで行われる作業に責任を持つ開発者の集まりである。openEHR技術プロジェクトには、参照プロジェクトと、アドホック(臨時暫定)プロジェクトの二種類がある。参照プロジェクトでは、コミュニティが製品を開発し適合性を試験する「公式な」基盤を形成するための、参照成果物を開発する。全ての参照プロジェクトは、担当するプロジェクト・グループとARBにより変更が管理される。
Project types
Project groups are groups of developers responsible for the work done on a project. There are two kinds of openEHR technical project - reference projects, and ad hoc projects. Reference projects develop reference deliverables, which constitute the “official” basis for the community to develop and test the conformance of products. All reference projects are change managed by their project group and the ARB.
他方、アドホックopenEHRプロジェクトは参照仕様や実装を開発することはなく、ARBの関与なしに変更管理ができる。アドホック・プロジェクト・グループは、大抵は自薦によって構成される。あるグループに対して参加することを知らせれば、誰でも既存のプロジェクトのメンバーになることができ、関係するリポジトリ(電子書庫)で変更を行う権利が与えられる。openEHR技術空間でのマネジメント概観図を、以下の図2に示す。本図では、参照プロジェクト・グループは審査委員会に線でつないで示されるが、アドホック・プロジェクトはつながれていない。
Ad hoc openEHR projects on the other hand do not generate reference specifications or implementations, and can be change-managed without recourse to the ARB. Ad hoc project groups will most likely be self-selecting. Anyone can become a member of a project by making themselves known to the existing group, and being given modification rights on the relevant repository. A management view of openEHR’s technical space is illustrated in FIGURE 2 below. In this figure, reference project groups are shown connected to a board of review, while ad hoc projects are not.
openEHR理事会
配布活動
図2： openEHR技術空間でのマネジメント概観図
openEHR参照成果物
openEHR技術空間で創造される成果物のなかに「参照成果物」がある。これら制作物：openEHR情報およびサービス・モデル仕様、XMLスキーマといった実装技術仕様(ITSs)、プログラム言語インターフェイス、openEHR用語体系、適合性テスト事例、openEHR参照実装物（例えば構文解析パーサー）は、そのカテゴリーでの決定的なインスタンスである。参照実装物は、適合性テストを目的とすると同時に、絶対的に信頼できて、繰り返し使用可能な、標準的な構成部材が必要な場合のために創造されている。全てのopenEHR参照成果物は、openEHR参照プロジェクトで創造されている。様々な種類のプロジェクトとopenEHR/非openEHRプロジェクトとの関係を、以下の図3に示す。
openEHR Reference Deliverables
Some deliverables created in the openEHR technical space are “reference deliverables”. These artifacts are the definitive instance in their category: the openEHR information and service model specifications, the implementation technology specifications (ITSs) such as XML-schemas, programming language interfaces, openEHR terminology, conformance test cases and openEHR reference implementations (e.g. parsers). Reference implementations are created either for the purposes of conformance testing, or in cases where absolutely dependable, re-usable, standard components are required. All openEHR reference deliverables are created by openEHR reference projects. The relationship among various kinds of projects and openEHR/non-openEHR products is shown in FIGURE 3 below.
openEHR.org
openEHR openEHR
非 製品を openEHR 参 照
openEHR 開発する アドホック プロジェクト
プロジェクト その他の プロジェクト openEHR
プロジェクト 参照成果物
openEHR 製品
図3 プロジェクトと製品との関係
openEHR技術プロジェクトの定義
openEHRの旗印の下で行うマネジメント業務の目的のため、「openEHR技術プロジェクト」という観念は、このマネジメント計画に従うあらゆるプロジェクトと明確に定義されている。「openEHR技術プロジェクト」は、a) 何らかの正式な方法で（典型的には、openEHRの適合基準を満たす何かを構築する目的で）openEHRに準拠しており、b) 以下に定義されるようなopenEHR.orgが提案する開発フレームワークの範囲内で作業することに同意しているものである。参照成果物を開発する全てのプロジェクトは、openEHRプロジェクトである。openEHRプロジェクト開発環境は、以下のように定義される。
Definition of an openEHR Technical Project
For the purposes of managing work done under the openEHR banner, the notion of an “openEHR technical project” is explicitly defined as any project that follows this change management plan. is a) based on openEHR in some formal way (typically aims to build something that satisfies openEHR conformance criteria) and b) that agrees to do its work within the development framework offered at openEHR.org, defined below. All projects that develop reference deliverables are openEHR projects. The openEHR project development environment is defined by the following.
変更マネジメント
・標準バージョンと変更マネジメントツール/環境。この目的で、openEHRは現在、オープンソース・ツールSubversionを使用している。
・変更マネジメントの基本的ルール ― プロジェクトチームのメンバーのみが、a) 変更の要求、およびb) プロジェクト・リポジトリに何らかの変更を行うこと、が可能です。このことは、チームは常にその構成員を承知しており、お互いに修正を行い得ることを承認しているという意味に過ぎません。チームの非構成員で合理的な修正を望む者は、おそらくチームに参加するよう要請されます。
・標準的問題報告(PR)ライフサイクル。
・標準的変更要求(CR)ライフサイクル。
Change Management
• A standard version and change management toolset/environment. openEHR currently uses the open source tool Subversion for this purpose.
• A basic change management rule - only a member of a project team can a) create a change request, and b) make any change to the project repository. This simply means that the team always knows who is in it, and has agreed among themselves that they can make modifications. Non-team members proposing sensible modifications are likely to be asked to join the team.
• A standard Problem Report (PR) lifecycle.
• A standard Change Request (CR) lifecycle.
・CRおよびPRを作成しアクセスするための、標準オンラインツール/環境。CRが作成されたら、標準的方法により、開発者が目を通す必要があります。一方、PRが作成されたら、一定の場所で合理的な方法により、ユーザーが目を通す必要があります。PRは、ユーザーのための、公開された問題記録・報告のインターフェイスです。
・参照プロジェクトでは、ARBは、23ページのopenEHR参照プロジェクトのための変更請求プロセスに則って、その開発を監督します。アドホックプロジェクトの開発では、26ページのアドホックプロジェクトのための変更請求プロセスに説明される、ARBが関与しない、より簡略なプロセスが採用することが出来ます。
• A standard online tool/environment for creating and accessing CRs and PRs. CRs need to be able to be created and viewed in a standard way by developers, whilst PRs need to be created and viewed in a known place and in a sensible way by users. PRs are the public problem-logging and reporting interface for users.
• For reference projects, development is overseen by the ARB, according to the change management process described in Change Request Process for openEHR Reference Projects on page 23. For ad hoc projects, development may adopt the simpler non-ARB process described in Change Request Process for ad hoc Projects on page 26.
ビルドとリリース
・実装プロジェクトの最上層のディレクトリ構造は、同一でないとしても、ほぼ類似しています。
・（開発者が複数のプロジェクトで作業し易いように）プロジェクト間で出来るだけ同質的なビルド管理の方法。これは単一のツールが必要ということではありませんが、もしも例えばantとmakeが使用されたら、これらのツールを同様のやり方で、複数のプロジェクト間で利用すべきです。
・ソフトウェア、とりわけバイナリーファイルを、ユーザーに配布する標準的な方法（つまり、非ITユーザーが簡単に利用できるようにするために）。
Build and Release
• The top level directory structure of implementation projects is fairly similar if not the same.
• An approach to build management that is as far as possible homogeneous across projects (facilitates developers working on more than one project). This does not necessarily have to be a single tool, but if e.g. ant and make are used, they should be used in the same way across projects.
• A standard way of distributing the software to users, particularly binaries (i.e. make it easy for non-IT users).
知的財産権
・著作権は、openEHR財団に移転されるか、openEHR財団との共同著作権に転換されるか、または制作した機関や個人が保有するかを、選択できます。
・文書類（例えばマニュアル類）は、標準openEHR文書ライセンスを使用します。
・ソースコードは、標準openEHRオープンソースライセンスを使用します。現在、これはMozilla Tri-Lisenceですが、その実態は、ソフトウェアを使用するライセンスに即してユーザーにGPL、LGPL、またはMPLを推奨するメタ・ライセンス契約です。
Intellectual Property Rights
• Copyright may optionally be transferred to the openEHR Foundation, converted to joint copyright with the openEHR Foundation, or may remain with the originating organisation or author.
• Documents (e.g. manuals) use the standard openEHR document licence.
• Source code uses the standard openEHR open source licence. This is currently the Mozilla tri-license, which is really just a meta-license allowing the user to nominate GPL, LGPL, or MPL as the licence they use the software under.
・ソースコード、スキーマ、用語体系、およびその他あらゆる参照成果物について、ARBが定めるorg.openehrネームスペースの構造を尊重しなければなりません。参照プロジェクトでないものは、org.openehrネームスペースを使用することはできません。
・取り消し不能性：組織は openEHR環境で開発したソフトウェアやその他の成果物を、openEHR財団とコミュニティが継続使用する権利を、過去に遡って取り消すことはできません（この行為はライセンスの規定に違反することになるからです）。勿論、参加組織はそうした開発済み著作物のいずれかを、別の開発の基盤にしても構いません。この条件は、（構成要素として依存することになるであろう）コミュニティと（相当の時間と資金とを開発に費やしたであろう）開発元の組織のいずれもが、著作物へのアクセス権を失わないことを確証します；利害が一致しなくなった際には、その開発は単純に「二股」に分かれ、そしてopenEHRのフレームワーク中には、唯一本の開発ラインが残ることになります。
• Respect the structure of the org.openehr namespace by the ARB, for source code, schemas, terminologies and any other reference deliverable. Non-reference projects may not use the org.openehr namespace.
• Irrevocability: organisations cannot retrospectively revoke the right of the openEHR Foundation and community to continue to use software or other artifacts which they have developed within the openEHR environment (since this would contravene the terms of the license). They may of course use any such developed works as a basis for other developments. This condition ensures that neither the community (which may have come to rely on a component) nor the original developing organisation (which may have spent significant time and money on the development) lose access to the work; if the interests cease to coincide, the development is simply “forked”, and only one line remains with openEHR.
これらの条項に同意するプロジェクトは、バージョン管理、複数のビルド・サーバー、１個の配布サーバーを含む、openEHRが提供する設備を利用することができます。これで特に、普通なら十分な物的資源を利用できない比較的小規模なプロジェクトの推進が、可能になります。
Projects that agree to these items will be able to take advantage of the facilities provided by the openEHR Foundation, including version management, build servers and a distribution server. It particularly enables smaller projects to proceed where otherwise they might not have sufficient technical resources.
この開発アプローチは、openEHRによるサービスとして提供されるもので、openEHR適合製品開発の必須条件では、勿論ありません。開発組織は、openEHR準拠製品の開発に、自らが適切と考えるどんな方法を用いても構いません。多くのプロジェクトが、企業、大学などにより、完全に商業ベースで非公開ソースによるプロジェクトを含め、それら組織自身の業務プロセスに基づいて遂行されるでしょう。
This approach to development is offered as a service by openEHR, and of course is not a requirement of developing openEHR-compliant products. Development organisations are encouraged to develop openEHR-based products in any way they see fit. Many projects will be done by companies, universities and so on, according to their own processes, including completely commercial closed source projects.
KOBAYASHI Shinji さんが15年以上前に更新 · 1件の履歴