openehr specification projectrelease 1.0 - road mapit.behdasht.gov.ir/uploads/256_1197_openehr...

openEHR Specifications

http://svn.openehr.org/specification/TRUNK/publishing/index.html (1 of 6)2006/11/01 04:29:47 .

COOLjsTree

openEHR Specification ProjectRelease 1.0 - Road Map

Overview

The following table describes the deliverables of the openEHR specification project and indicates the current status of each. The meanings of the statuses are as follows:

stable: the deliverable has been reviewed and validated by some level of implementation. draft: the deliverable is available but should not be considered stable yet, as testing of formal

semantics is not yet complete. forthcoming: the deliverable is not available yet, but will be in a future release. under redevelopment: the deliverable exists but needs to be upgraded or updated.

Reading the Documents

Most links in the table below are to Adobe PDF files. All files are in colour. If you do not see them in colour or have other problems reading them, we suggest upgrading to the latest Acrobat Reader. If you still experience problems with reading PDF files, your browser configuration may need to be adjusted. See the Adobe Acrobat support page for more help.

Deliverable Description Status Comments

General

Introducing openEHR

First introduction to the openEHR Foundation and its activities. Stable

CM Plan

Technical document describing how versioning, changes, and releases are made. Describes the workflow of the Architectural Review Board (ARB).

Stable

Requirements

ISO 18308 Conformance Statement

Document describing conformance of openEHR architecture to ISO TS 18308, "Requirements for EHR Architectures".

Stable

Architecture

Architecture Overview

Read me 1st document for the whole architecture. provides a summary of the reference, archetype and service models, and describes global semantics.

Stable

This is a new document containing some content from the old "roadmap" document as well as new content describing the key semantics of the openEHR reference

http://www.adobe.com/products/acrobat/readstep2.htmlhttp://www.adobe.com/support/products/acrreader.htmlhttp://www.adobe.com/support/products/acrreader.html


model.

Modelling Guide

Describes the use of UML and other related issues in object-oriented modelling. Stable

Terminology

Documentary form of the openEHR terminology, which is a set of vocabularies and code sets used by the reference and archetype models.

Stable

Reference Model

EHR IM The information model of the openEHR EHR Stable

EHR Extract IM

The information model of the EHR Extract, which is a serilialisation of content from an EHR.

Under Redevelopment

The EHR Extract Information Model has to be redeveloped due to changes in semantics in the other models, including the Folder structure, version identification and so on. It is scheduled for Release 1.1

Demographic IM The openEHR demographic model. Stable

Common IM

Information model containing common concepts, including the archetype-enabling LOCATABLE class, party references, audits and attestations, change control, and authored resources.

Stable

Data Structures IM

Information model of data structures, incuding a powerful model of HISTORY and EVENT. Stable

Data Types IMInformation model of data types, including quantities, date/times, plain and coded text, time specification, multimedia and URIs.

Stable

Support IMSupport model containing low-level concepts, assumed types, and terminology interface specification used in the rest of the models.

Stable

Integration IMModel supporting expression of legacy data in a free form for further processing into and out of openEHR information structures.

Draft

Archetype Model



Archetype Principles

Semantic principles of archetypes and templates. Stable

Archetype Definition Language 1.3 (ADL)

Syntax specification for archetypes. Stable

ADL 1.3 remains the current ADL syntax in use, and most current tools only process ADL 1.3. Some improvements that were done as part of the ADL 2 work will be reverse-engineered into ADL 1.3 in the near future; these are mainly to do with pathing.

Archetype Definition Language 2.0 (ADL2)

Improved syntax specification for archetypes. Draft

ADL version 2.0 is an improved syntax for expressing archetypes, and is has two important features over ADL 1.3: it is extensible without the syntax needing to be changed, because in ADL2, an archetype is a dADL document; and due to being in dADL/embedded cADL format, it can more easily be converted to and from XML. The current version of this specification has not yet been fully



implemented or tested. Implementors of this specification should consider engineering backwards compatibility for ADL 1.3 in their tools.

Archetype Object Model (AOM)

Object model of archetypes. Stable

Template Object Model (TOM)

Object model of templates. Forthcoming

The templates document has been partially completed and will be included in Release 1.1.

openEHR Archetype Profile (OAP)

openEHR plug-in additions to the generic archetype object model. Stable

Archetype System

Description of system of archetype management and governance.

Under Redevelopment

This document will change as a result of current work on archetype ontologies, governance, and logistical management.

Service Model

EHR Kernel API

API of a client component that provides a virtual EHR interface, including fine-grained archetype-based data manipulation, and querying.

Forthcoming

EHR ServiceCoarse-grained service specification for EHR back-end providing check-out, Contribution check-in, querying.

Forthcoming

Demographic Service

Service specification for demographic back-end. Forthcoming

Archetype service Archetype repository service specification. Forthcoming

Computable



UML computable form of model

Expression of openEHR models in tool-based UML; published in XMI format. Draft

Terminology as an XML file Terminology in computable XML form. Draft

ITS

XML schemas XML-schema expression of the reference model. Draft

Java ITS Guide Guide to java implementation of openEHR. Draft

Release Strategy

With the advent of Release 1.0 of openEHR, more rigorous change management rules come into play. These are designed to protect developers and users from adverse effects of changes, and to allow them to upgrade in an orderly fashion. Future releases will follow a 3-digit numbering scheme similar to many open source projects, e.g. Apache, using identifiers like 1.0.1 etc. The meaning of a change in each digit is as follows:

3rd position: used to indicate error corrections and minor additions that do not change the semantics. Thus, Release 1.0.2 is the second error correction release after Release 1.0.

2nd position: used to indicate significant additions that do not change the semantics of the existing part of the release. Release 1.3.0 would be the 3rd release containing compatible additions to Release 1.0.

1st position: used to indicate changes to the semantics or large changes. Release 2.0 would contain changes incompatible in some way with Release 1.0, most likely requiring software upgrade and possibly data migration.

Changes to Documentation

Where changes to documentation are made, e.g. due to a request to clarify an explanation, fix a typographical error, a CR will be raised, and the revision number of the affected document(s) will change, but there will not be a new release number.

Error corrections

Where the changes made are to correct an error in a model, parsing rules or some other aspect of the formal semantics of the specifications (and possibly accompanying changes to explanatory text), an error-correction release will be made.

Compatible Additions

Where the changes have the effect of adding a new specification or other artifact which is completely compatible with the current release, an enhancement release is made.

Major Changes

Where changes actually alter semantics of existing artefacts (other than for minor error corrections), a new major release is declared. Such changes would normally be grouped into as few such releases as possible.

Change Management

As with pre-1.0 releases, change management will remain a disciplined process. Two types of online document, the Problem Report (PR) and the Change Request (CR), are used to track problems and



changes. These are used as follows:

anyone can raise a PR to indicate some issue or problem with the current release. A PR documents the issue seen from the user's perspective, with the resolution being provided by the development team.

only a member of the development team can raise a CR. All CRs can be viewed here. A CR documents a change to the current release. A CR will either describe the problem it is solving, or refer to one or more PRs it is designed to address. The CR is a document of the change and the process of applying it to the release.

From Release 1.0 onward, the way CRs are processed will change slightly. All changes to the specifications, apart from document text changes (e.g. improving explanations, fixing typos) will be signalled to the community via the openehr-technical mailing list, and a period of time given for the community to inspect the proposed changes and provide feedback. This is particularly aimed at allowing implementers to indicate the knock-on effects of changes. In the process of such discussions it may turn out that the proposed change will not go ahead, or that it will go ahead in a later release than originally planned. In this way, the community will be able to ensure that releases into the future remain stable and occur at a reasonable rate. All changes in the Release 1.0 mainline must also be implemented in at least one instance of software, schemas or other appropriate formal expression before being accepted as a change to the specifications.

$LastChangedDate$ $LastChangedRevision$


http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/PR/folder_contentshttp://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/folder_contents

Introducing openEHRRev 1.1

Page 1 of 11 Date of Issue:02 Jan 2006

2005 The openEHR Foundationemail: [email protected] web: www.openEHR.org

2005 The openEHR Foundation

The openEHR foundationis an independent, non-profit community, facilitating the creation and sharing

of health records by consumers and clinicians via open-source, standards-based implementations.

openEHR is an internationally registered trademark of the openEHR Foundation

email: [email protected] web: www.openEHR.org

Founding Chairman

David Ingram, Professor of Health Informatics, CHIME, University College London

Founding Members

T Beale, Dr S Heard, Dr D Kalra, D Lloyd, Dr P Schloeffel

Introducing openEHR

Release 1 .0publ ic

comment

Date of Issue:02 Jan 2006 Page 2 of 11


Overview of openEHR Introducing openEHRRev 1.1

Overview of openEHR

The FoundationThe openEHR Foundation is a not-for-profit company, limited by guarantee. Its founding sharehold-ers are University College London, UK and Ocean Informatics Pty Ltd, Australia. It is regulatedunder the UK Companies Acts 1985 and 1989. The aims and management of the Foundation, exer-cised through its Board of Directors, are described on the openEHR website. The Board is responsi-ble for the governance of the Foundation, including strategic direction, financial management, legalregulation, and intellectual property (IP) management. The Board determines the roles, structures,and procedures of the Foundation and ensures that these function correctly. The major work of techni-cal and clinical oversight and supervision of openEHR product developments is delegated to theArchitectural Review Board (ARB) and Clinical Review Board (CRB).

AimsThe openEHR Foundation is dedicated to the development of an open, interoperable health comput-ing platform, of which a major component is clinically effective and interoperable electronic healthcare records (EHRs). It does this by researching clinical requirements, and creating specifications andimplementations. The specifications take the form of modular information models, service modelsand clinical information models. The platform supports the following requirements:

ability to record any clinical information, including complex time-based lab results, imag-ing, diagnoses, care plans, evaluations, patient education material, and stateful, workflow-based instructions and intervention information;

archetype- and template-enabling of all clinical systems, empowering clinical profession-als to define the content, semantics and user interfaces of systems independently from thesoftware;

proper integration with terminology systems, incuding with: SNOMED-CT1 so that relia-ble inferencing and decision support based on EHR data will be possible; LOINC2, so thattraceability and sharing of laboratory data is possible; and ICDx3 and ICPC4 classifications,enabling reliable reimbursement, management, and public health studies;

ability to integrate openEHR with messaging systems, particularly HL7 version 2 and EDI-FACT, via the use of legacy archetypes and systematic mapping definitions;

ability to integrate with existing hospital information systems and other databases, also viathe use of legacy archetypes;

integration with applications via a published API; distributed versioning and merging of EHR, demographic and other information; to make the architecture componentised, adaptive and future-proof, so that it may be a

reliable basis for managing 100 year+ health records.

The Foundation publishes the specifications for the architecture openly. It also publishes implemen-tation technology specification expressions, such as XML and database schemas corresponding to

1. A major ontological terminology effort by the College of American Pathologists; see http://www.snomed.org2. A code system for laboratory observations. See http://www.regenstrief.org/loinc/.3. WHO International Classification of Diseases. See http://www.who.int/classifications/icd/en/.4. Primary care classificatoin. See http://www.globalfamilydoctor.com/.

http://www.snomed.org/http://www.regenstrief.org/loinc/http://www.who.int/classifications/icd/en/http://www.globalfamilydoctor.com/http://www.openehr.org/

of 11 Date of Issue:02 Jan 2006


Introducing openEHR Overview of openEHRRev 1.1

the models. From these artifacts it creates open source implementations which are validated in clini-cal environments, used for further research, and ultimately deployed in actual clinical environments.

The other major activity of the openEHR Foundation is the development of evidence-based clinicalinformation and workflow models, known as archetypes. These are developed collaboratively bydomain experts, and published openly in an online, intelligent repository, and are directly consumableby systems based on the openEHR archetype principle.

Modus OperandiThe openEHR Foundation works in an open manner, based on active relationships with domainexperts and users, with national and international standards bodies, including ISO, CEN, and sHL7,with software and system developers, and with educational institutions and researchers. The technicalwork is carried out within a scientific framework i.e. the use of an experimental methodology to vali-date and refine hypotheses. It is performed in an engineering mode, i.e. with a dedicated team under-taking an iterative process of requirements capture, design, implementation and testing. All of itsdeliverables are version-controlled and formally change-managed.

Unlike closed commercial developments, openEHR conducts its development in the open, with directcommunity involvement in specification, software implementation and evaluation, so that users cansee and trust the foundations and structures of the software they are using.

MembershipMembership of openEHR implies a commitment towards realising the vision of high quality, interop-erable EHRs, and a willingness to share ideas and experience. Membership is free, and is availablesimply by registration on the openEHR.org website.

openEHR ActivitiesThe openEHR Foundation works in two broad activity areas: the technical and the clinical. Thetechnical area is where engineering work is done, including specifications, implementations, testingand conformance. The clinical area is where healthcare domain professionals and organisationsengage with openEHR, including on the development and deployment of ontologies, archetypes, tem-plates, guidelines, and clinical education and training. These two areas of activity in openEHR arevisible in the two-level modelling approach of openEHR, through which a rigorous yet flexibledevelopment framework enables reliable sharing of clinical meaning in addition to guaranteed datainteroperability.

ManagementWithin each of the two openEHR activity areas, work is performed by project groups (PGs) eachcomprising a team of developers responsible for the work done on a project. Change management onsome of these projects is overseen by a review board. In the technical area, the Architectural ReviewBoard (ARB) performs this function. Its membership comprises some eight members of openEHR,appointed by the Foundation Board, all with long-term experience in an area of health informatics.The current membership of the ARB is posted on the openEHR website ARB page. The role of theARB is to review and make decisions on change requests (CRs) for reference projects (definedbelow). It operates using simple majority voting.

In the clinical area, the Clinical Review Board (CRB) performs a corresponding change managementfunction. The CRB, likewise, comprises an international group of experienced clinical professional

http://www.openehr.org/about_openehr/t_arb.htm




members of openEHR. Issues affecting both areas are managed through consultation between theboard.

The management structure of openEHR is illustrated in FIGURE 1. Projects whose change is man-aged by the ARB or CRB are shown joined to the relevant board of review; others are not..

What is an openEHR Project?An openEHR project is defined as any project that:

is based on openEHR in one of the following ways:- contributes to openEHR specifications or- aims to build something that satisfies openEHR conformance criteria of nominated

openEHR specifications; agrees to use the relevant Technical or Clinical Change Management plan (CM Plan) and; agrees to the IP framework defined by openEHR for its products and services; is registered as an openEHR project with the openEHR Foundation.

Common aspects of openEHR change management in both activity areas include:

the use of version and change management toolset/environment; the use of Problem Reports (PR) and Change Requests (CR), and the lifecycle and process

for handling them; the use of defined operating procedures including for the distribution and publication of

artefacts (also described in the CM plans).

Similarly, openEHR projects agree to respect the following intellectual property rights.

All project documents must use the openEHR public licence (document form). Project source code must use the openEHR open source licence. The project must respect and preserve the structure of the org.openehr namespace, which is

managed by the ARB. Irrevocability: organisations contributing to projects cannot retrospectively revoke the right

of the openEHR Foundation and community to continue to use software or other artefacts

openEHR Board

ARB

PG PG PG PG

PG PG PG PG PG

CRB

PG PG

PG PG PG

FIGURE 1 Management Structure of openEHR

delivery activities delivery activities

Technical activities Clinical activities



Introducing openEHR Overview of openEHRRev 1.1

which they have developed within the openEHR environment (since this would contravenethe terms of the license). They may of course use any such developed works as a basis forother developments. This condition ensures that neither the community (which may havecome to rely on a component) nor the original developing organisation (which may havespent significant time and money on the development) lose access to the work; if the inter-ests cease to coincide, the development is simply forked, and only one line remains withinthe openEHR framework.

Copyright of donated IP may optionally be transferred to the openEHR Foundation, converted to jointcopyright with the openEHR Foundation, or may remain with the originating organisation or author.

Projects agreeing to this framework can take advantage of the facilities provided by the openEHRFoundation, including version management, build servers and a distribution server. It particularlyenables smaller projects to proceed where otherwise they might not have sufficient materialresources.

This approach to development is offered as a collaboration environment by openEHR, and is not arequirement of developing openEHR-compliant products. Development organisations are welcome todevelop openEHR-based products in any way they see fit. It is expected that many projects will beexecuted by companies, universities and others, according to their own needs and priorities, includingfully commercial and closed source projects.

What is an openEHR Product?Regardless of the manner in which its development proceeds, a component, executable, or other arte-fact (such as a information model schema) can only be represented or promoted as an openEHRproduct, and can only use service marks containing terms such as openEHR, openEHR-compli-ant, openEHR 1.x compliant and so on, if it has been shown to be conformant to the appropriateopenEHR specification(s), through a testing procedure defined and certified by the Foundation,against a specified set of test cases, test data or other appropriate test material. The name openEHRis registered internationally as a trademark, and its use with respect to products and services requirespermission of the openEHR Foundation. In practical terms this means that users of openEHR-certi-fied end products (particularly those for clinical information management) can rely on claims by thedeveloper to be openEHR compliant. It aims to prevent non-conformant (potentially faulty) soft-ware or other products being promoted under the banner of openEHR. The test cases and criteria aredeveloped by the community and reviewed by the ARB and/or CRB.

The following figure illustrates the relationship among openEHR projects, products, and non-openEHR work.

openEHRprojects

otherprojects

developingopenEHRproducts

openEHR.org

openEHR products

non-openEHR

work

FIGURE 2 Relationship between Projects and Products




Intellectual PropertyThe openEHR Foundation has created a framework to enable the openEHR community to build arepository of intellectual property (IP), for common use. Since the IP includes specifications, soft-ware, knowledge bases (e.g. clinical vocabularies) and educational materials, which will find use inclinical and related environments, as well as use in research and education, some legal protection isalso required. This is to ensure continuing quality and open access to the IP. The measures adopted bythe openEHR Foundation are typical of those used by standards development organisations (due tothe fact that openEHR publishes specification documents), and other open source development organ-isations: copyright, source code licensing, trade- and service-mark protection, and control of theopenEHR namespace.

Copyright: Recognition of AuthorshipopenEHR copyright exists on four kinds of deliverables: documents, software source (including sche-mas, interfaces), executable software, and knowledge products, such as terminologies. Legally, copy-right law guarantees that the original author of the original version of a given artefact is alwaysrecognised. However, it does not, on its own, offer much legal protection of such IP, due to the factthat such artefacts keep changing over time, unlike artistic works, which are generally published onceonly in their finished form (and for which copyright law was mainly developed). For this reason, theopenEHR Foundation does not demand that the output of all openEHR projects be copyrighted to theFoundation - the copyright may be retained by the original developer, or a joint copyright may beadopted. However, all reference specifications, ITSs and reference implementation project delivera-bles must be solely or jointly copyrighted to the openEHR Foundation. Deliverables of non-referenceimplementation projects may retain the copyright of the original developing organisation.

Source Licenses: Protection for DevelopersBecause specification documents, software and related artefacts are by their nature constantly chang-ing, the conditions of use, copying, modification and sale are specified explicitly in licenses, ratherthan relying on potentially unreliable copyright law (which in any case varies across jurisdictions).Two types of license are used - one for documents, and one for software and related materials. TheopenEHR licenses are available from the Foundation website license page. These licenses aredesigned to guarantee fair, open and continued availability of all openEHR products to the openEHRcommunity. They provide the main protection for developers of materials that their work will not betaken out of circulation, or otherwise appropriated by private individuals or bodies.

Trademark & Service-marks: Protection for UsersControlled use of the openEHR trademark and related service-marks is the main protection forusers of openEHR products, ensuring that, for any product claiming to be compliant, conformant orotherwise based on openEHR, this is in fact the case, and that the exact meaning of the claimed con-formance/compliance can be investigated (e.g. by accessing and inspecting the relevant test cases orother materials from the openEHR website). The openEHR trademark and any related service-markmay only be used with permission of the openEHR Foundation.

End-use Licenses: Rights of UsersEnd-use licenses govern the conditions of use of end products - artefacts that can be deployed in aruntime environment. The openEHR Foundation itself employs only a minimal end-use license for itsreference implementations, which essentially says that the relevant artefact can not be modified whilebeing presented as its original. This simply ensures that a published component is not altered at thebinary level and passed off as the original (or at least that where this happens, it is clearly in violation

http://www.openehr.org/about_openehr/t_licensing.htm



Introducing openEHR Technical ActivitiesRev 1.1

of the conditions of use). More complex end use licenses (often called EULAs - end use licenseagreements) may be used by commercial organisations to control the use of their products; suchlicenses are not the business of the openEHR Foundation.

The openEHR.org Domain and org.openehr NamespaceThe openEHR Foundation owns the openEHR.org internet domain, all related variants and sub-domains, and by extension, the org.openehr namespace. Population of the namespace (for examplewith Java libraries and XML-schemas) is managed on behalf of the Foundation by the openEHRARB, for the benefit of the community. The principal aim is to ensure that the namespace is clearlydefined. Only openEHR reference deliverables may be defined in the org.openehr namespace.

Technical ActivitiesFIGURE 3 illustrates the areas technical activity of openEHR, including specification and implemen-tation projects, and delivery/deployment activities.

Requirements ProjectopenEHR undertakes the collation of requirements for the design, implementation and deployment ofinteroperable EHRs a) to support the seamless sharing and continuity of health care and b) to enableEHR systems to interface with medical knowledge, evidence of best practice and other systemsneeded to deliver safe, secure and effective health services. Requirements developed by openEHR arecontributed to relevant international standards initiatives.

Architecture ProjectThe openEHR Foundation publishes a number of formal model specifications, including: theopenEHR Reference Model (RM), consisting of the primary information models (IMs), the archetype

FIGURE 3 openEHR Technical Activities

Requirements

Architecture ITSs

Conformance

EHR Server Demographic Server

Tools

implementation

specification

delivery Standards Engagement

...

Specifications

Conformance Testing

Education& Trainingactivities

projects

projects

technical

Archetype Parser

Systems



Clinical Activities Introducing openEHRRev 1.1

model (AM) which includes the Archetype Definition Language (ADL) and Archetype Object Model(AOM), and the openEHR service model (SM), which defines interfaces to major software services ina health information environment.

Because these specifications are underpinned by explicit requirements and by the results of imple-mentation and deployent of previous versions and thus constitute an evidence-based informationarchitecture. As with requirements, openEHR architectural specifications are also contributed to rele-vant international standards initiatives.

Abstract information models are published as directly usable implementation technologies specifica-tions (ITSs), such as OMG IDL, XML, programming languages, and database schemas.

Implementation ProjectsThe openEHR Foundation engages in the implementation of interoperable software components,including archetype and EHR tools and components, using rigorous design and development method-ologies. These reference implementations enable the validation of the published specifications, ensur-ing they are not simply 'paper' exercises.

Standards ActivitiesThe openEHR Foundation is committed to supporting relevant government-sponsored and industry-based standards bodies as a means of encouraging the widespread and effective adoption of interoper-able EHRs. Members of openEHR work closely with standadisation bodies, including ISO TC215,CEN TC/251, HL7 and national standards bodies.

Educational ActivitiesIn order to promote and assist understanding and acceptance of openEHR methodology and modelsby a wide audience, the openEHR Foundation develops educational materials, runs workshops, andprovides consultancy services internationally. It also develops materials suitable for use in clinical,healthcare, and health informatics courses.

Clinical ActivitiesActivities in the openEHR clinical activity area are illustrated in FIGURE 4.

FIGURE 4 openEHR Clinical Activities

TemplatesVocabularies Terminologiesdevelopment Archetypes

Education & Training

Clinical Trials

Clinical Knowledge

bases

Standards Engagement

Clinical Engagement

delivery

projects

activities

domain



Introducing openEHR The openEHR MethodologyRev 1.1

Vocabularies and TerminologyIn the clinical activity area, openEHR is concerned with existing and emerging clinical ontologies andterminologies. It also develops specific openEHR terminologies of its own to facilitate the integrationof software components and knowledge bases, through the use of archetypes and templates.

Archetypes and TemplatesArchetypes are a key element of the openEHR methodology. They are reusable, structured models ofclinical information concepts that appear in EHRs, such as 'test result' , 'physical examination' and'medication order', and are expressed in terms of constraints on the reference model. All data inopenEHR EHRs are instances of reference model entities, configured by archetypes. Archetypes alsoact as mediators between data and terminology. They are language- and terminology-neutral.

Templates are (usually) locally defined models of screen forms, and ring together a selection of arche-types, terminologies, language and other details relevant to the particular local use of archetypes. Forexample, concepts such as 'referral' and 'prescription' are modelled as templates, which in turn usearchetypes for more fine-grained concepts.

Educational ActivitiesThe openEHR Foundation develops methodologies and publishes methods and materials for the for-mulation and use of archetypes, templates, terminologies and clinical guidelines, including thosedeveloped by openEHR projects. In collaboration with academic colleagues, it also develops materi-als suitable for use in clinical, healthcare and post-graduate health informatics courses.

Standards ActivitiesThe openEHR Foundation is .working with national and international standards bodies and profes-sional organisations to establish standards for the representation, capture and sharing of clinicalknowledge for use in health information environments.

The openEHR MethodologyThe openEHR development methodology, designed to formally integrate technical and clinical workin a coherent manner is summarised by FIGURE 5. In the technical environment, modellers and soft-ware developers create small, generic models and specifications which are then implemented withinsystems. They also build tools to support users performing modelling the healthcare domain - thebuilding of archetypes above terminologies and ontologies. At runtime, systems are driven by the def-initions created by domain experts using the tools. The information processing capabilities of suchsystems can evolve smoothly, based mainly on ongoing tool-enabled development work of clinicalexperts, rather than by continual software maintenance and redeployment.

The key benefits of this approach are:

direct, flexible and sustainable involvement of domain experts and users; significant reductions available in costs of development and deployment of health informa-

tion systems, due to smaller, more stable software; the creation of a much more adaptable and durable health computing environment.



Participating in openEHR Introducing openEHRRev 1.1

Participating in openEHRA useful starting point for prospective participants is the openEHR primer.

Membership is free, and obtained via the membership page.

The Foundation maintains four discussion lists:

openehr-announce: one way list for major announcements; openehr-technical: dedicated to openEHR technical architecture, archetype language, serv-

ice models and so on; recommended for all ICT professionals working with openEHR, andhealthcare professionals interested in technical issues;

openehr-clinical: dedicated to clinical modelling, archetype development, terminologies,clinical use and demonstration of openEHR; recommended for health professionals and ICTpeople interested in the clinical world;

openehr-implementers: dedicated to implementation issues. Recommended for actual andprospective implementers.

Developers are encouraged to visit the developer page. An equivalent starting point for health pro-fessionals is the clinicians page.

Organisations interested in supporting or contributing to openEHR should contact Dr Dipak Kalra [email protected] or or [email protected].

FIGURE 5 The openEHR Development Methodology

modelsimplemented in

technicalenvironment

stable

clinicalenvironment

archetypes

smallgovern

terminologies

software

healthcare domain

users developers

ontologies

SystemsTools

expert

implemented in

mailto:[email protected]://www.openehr.org/advice/contents.htmlhttp://www.openehr.org/cgi-bin/membDB-loginhttp://www.openehr.org/developer/t_developer.htmhttp://www.openehr.org/getting_started/t_clinicians.htmhttp://www.openehr.org/getting_started/t_openehr_primer.htmhttp://svn.openehr.org/specification/TRUNK/publishing/openEHR/[email protected]



Introducing openEHR Participating in openEHRRev 1.1

Amendment Record

Issue Details Who Completed

R E L E A S E 1.0

1.1 Changes to Aims and Modus Operandi. T Beale 02 Jan 2006

1.0 Final group review. D Ingram, D Kalra,D Lloyd

15 Mar 2005

0.9.5 David Ingram review. D Ingram 12 Mar 2005

0.9.1 Various comments from Dipak. D Kalra 03 Mar 2005

0.9 Initial writing. Based on CM Plan and openEHR planningmeetings.

T BealeS Heard

D IngramD KalraD Lloyd

12 Feb 2005

The openEHR Change Management PlanRev 1.0

Author: {T Beale} Page 1 of 37 Date of Issue:28 Jan 2006

2003-2006 The openEHR Foundationemail: [email protected] web: www.openEHR.org

2003-2006 The openEHR Foundation

The openEHR foundationis an independent, non-profit community, facilitating the creation and sharing

of health records by consumers and clinicians via open-source, standards-based implementations.

email: [email protected] web: www.openEHR.org

Founding Chairman

David Ingram, Professor of Health Informatics, CHIME, University College London

Founding Mem-bers

Dr P Schloeffel, Dr S Heard, Dr D Kalra, D Lloyd, T Beale

The openEHR Change Management Plan

Editor:{T Beale}1

Revision: 1.0

Pages: 37

1. Ocean Informatics Australia

Release 1 .0publ ic

comment

Date of Issue:28 Jan 2006 Page 2 of 37 Author: {T Beale}



Copyright Notice

Copyright openEHR Foundation 2001 - 2005 All Rights Reserved

1. This document is protected by copyright and/or database right throughout the world and is owned by the openEHR Foundation.

2. You may read and print the document for private, non-commercial use. 3. 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.

4. 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).

5. 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"

6. 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.

7. 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




Amendment Record

AcknowledgementsThis paper has been funded by The University College, London and Ocean Informatics, Australia.

Issue Details Who Completed

R E L E A S E 1.0

1.0 Update release details. T Beale 28 Jan 2006

0.9 Changes due to migration to subversion. T Beale 28 Jul 2005

0.8 Split off openEHR Overview document. T Beale 04 Feb 2005

0.7 Addition of sections on governance, IP and project overview. T Beale M Darlison

10 Jan 2005

0.6 Review by UCL team D Kalra,T Austin,

N Lea,D LloydT Beale

10 Dec 2004

0.5.2 Review by prof. David Ingram (UCL). D Ingram 20 Feb 2004

0.5.1 Further review by Tim Cook . T Beale 10 Dec 2003

0.5 Further development of ARB process. T Beale 06 Dec 2003

0.4 Review by Tim Cook ; furtherdevelopment.

T Cook,T Beale

22 Nov 2003

0.3 Updated in preparation for public openEHR CM site launch. T Beale 15 Nov 2003

0.2 Updated May visit UCL T Beale 13 May 2003

0.1 Initial Writing T Beale 20 Jan 2003




Table of Contents

1 Introduction .............................................................................. 71.1 Purpose...................................................................................................71.2 Audience ................................................................................................71.3 Status......................................................................................................71.4 Terms and Acronyms .............................................................................7

2 Overview ................................................................................... 82.1 Activities ................................................................................................82.2 Management...........................................................................................8

3 openEHR Technical Projects................................................. 123.1 The Specification project .....................................................................123.2 Reference Implementation Projects .....................................................143.3 Ad hoc Implementation Projects..........................................................14

4 Repository Organisation........................................................ 164.1 Repository Naming ..............................................................................164.2 Repository Design................................................................................16

5 Release Management ............................................................. 185.1 Overview..............................................................................................185.2 Release Structure and Branching .........................................................185.3 Release Naming ...................................................................................20

6 Change Management ............................................................. 216.1 Overview..............................................................................................216.2 The Change Process.............................................................................226.2.1 Overview........................................................................................226.2.2 Problem Reporting.........................................................................236.2.3 Change Request Process for openEHR Reference Projects...........236.2.3.1 Workflow ....................................................................................................236.2.3.2 CR Lifecycle ...............................................................................................246.2.3.3 Project Group-managed CRs ......................................................................256.2.3.4 Review Board-managed CRs ......................................................................256.2.4 Change Request Process for ad hoc Projects .................................266.2.4.1 Workflow ....................................................................................................266.2.4.2 CR Lifecycle ...............................................................................................276.2.4.3 CR Management .........................................................................................27

7 Tools......................................................................................... 297.1 Overview..............................................................................................297.2 Configuration Management System ....................................................297.3 PR / CR Database ................................................................................307.4 Publishing/Distribution ........................................................................30

8 CI Identification ..................................................................... 31Appendix AForms ............................................................................ 33A.1 Problem Report Form ..........................................................................33A.2 PR Form Fields ....................................................................................33A.3 Change Request Form..........................................................................34A.4 CR Form Fields....................................................................................34



The openEHR Change Management Plan IntroductionRev 1.0

1 Introduction

1.1 PurposeThe 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) andcarried out within the openEHR development environment. These projects have controlled deliver-ables, and a clear problem reporting and change request strategy, defined by this document. Twochange management strategies are described: one with a review board for reference projects, andone without, for ad hoc projects.

1.2 AudienceThe primary audience for this document is developers of specifications and software for theopenEHR Foundation.

1.3 StatusThis 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/specifica-tion/TRUNK/publishing/CM/CM_plan.pdf.

1.4 Terms and AcronymsARB Architectural Review BoardCI Configuration Item - any controlled artifact, such as a document, source file, test

case etc.CM Configuration managementIP Intellectual propertyPG Project Group

http://svn.openehr.org/specification/TAGS/Release-1.0/publishing/CM/CM_plan.pdfhttp://svn.openehr.org/specification/TAGS/Release-1.0/publishing/CM/CM_plan.pdfhttp://svn.openehr.org/specification/TRUNK/publishing/introducing_openEHR.pdf



Overview The openEHR Change Management PlanRev 1.0

2 Overview

2.1 ActivitiesThe figure below illustrates the technical activity areas of openEHR, including specification andimplementation projects, and delivery/deployment activities.

Each solid-line bubble on the left part of the diagram is a project in openEHR. As shown, there arefour major areas of activity: specification, implementation, knowledge, and delivery. The first twocorrespond to what most people would think of as software development; their change management isthe subject of this document. The projects in these two groups are described in more detail in section3 on page 12.

2.2 ManagementIn the technical space of openEHR, work is performed by project groups (PGs), which are in somecases overseen by the Architectural Review Board (ARB). The ARB consists of a eight or more inter-national members of openEHR, all with long-term experience in an area of health informatics. Thecurrent makeup of the ARB may be found on the openEHR website ARB page. The ARBs function isto 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 simplemajority voting.

Project typesProject groups are groups of developers responsible for the work done on a project. There are twokinds of openEHR technical project - reference projects, and ad hoc projects. Reference projectsdevelop reference deliverables, which constitute the official basis for the community to developand test the conformance of products. All reference projects are change managed by their projectgroup and the ARB.

FIGURE 1 openEHR Technical Activities

Requirements

Architecture ITSs

Conformance

EHR ServerKernel Demographic Server

ADL Parser

Tools Systems

implementation

specification

delivery Standards Engagement

...

Specifications

Conformance Testing

Education& Trainingactivities

projects

projects

technical

http://www.openehr.org/about_openehr/t_arb.htm



The openEHR Change Management Plan OverviewRev 1.0

Ad hoc openEHR projects on the other hand do not generate reference specifications or implementa-tions, and can be change-managed without recourse to the ARB. Ad hoc project groups will mostlikely be self-selecting. Anyone can become a member of a project by making themselves known tothe existing group, and being given modification rights on the relevant repository. A managementview of openEHRs technical space is illustrated in FIGURE 2 below. In this figure, reference projectgroups are shown connected to a board of review, while ad hoc projects are not.

openEHR Reference DeliverablesSome deliverables created in the openEHR technical space are reference deliverables. These arti-facts are the definitive instance in their category: the openEHR information and service model speci-fications, the implementation technology specifications (ITSs) such as XML-schemas, programminglanguage interfaces, openEHR terminology, conformance test cases and openEHR reference imple-mentations (e.g. parsers). Reference implementations are created either for the purposes of conform-ance 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 inFIGURE 3 below.

Definition of an openEHR Technical ProjectFor the purposes of managing work done under the openEHR banner, the notion of an openEHRtechnical project is explicitly defined as any project that follows this change management plan.

openEHR Board

ARB

PG PG PG PG

PG PG PG PG PG

FIGURE 2 Management View of the openEHR Technical Space

delivery activities

reference

ad hoc project groups

project groups

openEHRreferenceprojects

openEHRad hocprojects

otherprojects

developingopenEHRproducts

openEHR.org

openEHR products

non-openEHRprojects

FIGURE 3 Relationship between Projects and Products

openEHRreference

deliverables



Overview The openEHR Change Management PlanRev 1.0

is a) based on openEHR in some formal way (typically aims to build something that satisfiesopenEHR conformance criteria) and b) that agrees to do its work within the development frameworkoffered at openEHR.org, defined below. All projects that develop reference deliverables are openEHRprojects. The openEHR project development environment is defined by the following.

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 teamalways knows who is in it, and has agreed among themselves that they can make modifica-tions. Non-team members proposing sensible modifications are likely to be asked to join theteam.

A standard Problem Report (PR) lifecycle. A standard Change Request (CR) lifecycle. 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 cre-ated and viewed in a known place and in a sensible way by users. PRs are the public prob-lem-logging and reporting interface for users.

For reference projects, development is overseen by the ARB, according to the change man-agement process described in Change Request Process for openEHR Reference Projects onpage 23. For ad hoc projects, development may adopt the simpler non-ARB processdescribed in Change Request Process for ad hoc Projects on page 26.

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 tobe a single tool, but if e.g. ant and make are used, they should be used in the same wayacross projects.

A standard way of distributing the software to users, particularly binaries (i.e. make it easyfor non-IT users).

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 orauthor.

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, orMPL as the licence they use the software under.

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 theorg.openehr namespace.

Irrevocability: organisations cannot retrospectively revoke the right of the openEHR Foun-dation and community to continue to use software or other artifacts which they have devel-oped within the openEHR environment (since this would contravene the terms of the

http://subversion.tigris.org/



The openEHR Change Management Plan OverviewRev 1.0

license). They may of course use any such developed works as a basis for other develop-ments. This condition ensures that neither the community (which may have come to rely ona component) nor the original developing organisation (which may have spent significanttime and money on the development) lose access to the work; if the interests cease to coin-cide, the development is simply forked, and only one line remains with openEHR.

Projects that agree to these items will be able to take advantage of the facilities provided by theopenEHR Foundation, including version management, build servers and a distribution server. It par-ticularly enables smaller projects to proceed where otherwise they might not have sufficient technicalresources.

This approach to development is offered as a service by openEHR, and of course is not a requirementof developing openEHR-compliant products. Development organisations are encouraged to developopenEHR-based products in any way they see fit. Many projects will be done by companies, universi-ties and so on, according to their own processes, including completely commercial closed sourceprojects.



openEHR Technical Projects The openEHR Change Management PlanRev 1.0

3 openEHR Technical Projects

3.1 The Specification projectThe openEHR specification project includes deliverables that are considered technical specifications -i.e. that can be used either to develop further specifications, or to build systems, test plans, or otherusable artifacts. The specification project includes requirements, abstract architecture, ITSs and con-formance specifications as shown in the following table.

Deliverable Component Description

RequirementsRequirements Base

The Requirements Base is a repository of requirements underpinning the EHR and related functionality in the health information environment. This repository is the definitive requirements basis of openEHR, and will continue to evolve in time. It consists of both functional requirements and use cases.

ConformanceStatement

Conformance statement of openEHR with respect to exist-ing/emerging standards, e.g. ISO TS 18308.

Architecture

Design Principles

Design principles of health information systems and in par-ticular the EHR

Reference Model (RM)

The primary set of abstract, formal specifications of openEHR models in the information viewpoint. These abstract expressions are independent of implementation tech-nologies. Includes abstract Information Models for:

EHR_extract Common Data Structures Data Types Support (low level primitives)

Service Model (SM)

The primary set of abstract, formal specifications of openEHR models in the computational viewpoint. These abstract expressions are independent of implementation tech-nologies. Includes abstract Service Models for:

EHR Demographics Workflow Archetype repository

Archetype Model (AM)

Various formal specifications defining the openEHR arche-type semantics.

Archetype Principles Archetype Definition Language (ADL) specification Template Definition Language (TDL) specification Archetype Query Language (AQL) specification Archetype Object Model (AOM)

Archetype System

The openEHR Archetype System



The openEHR Change Management Plan openEHR Technical ProjectsRev 1.0

The primary models are used as the source for the published documentary form of the specifications,generally in Adobe PDF format. There is not considered to be any semantic difference between tool-based abstract model expressions and their documentary counterparts, i.e. there is no mapping orconversion. The primary models are also losslessly translated to a UML-2.0 compliant XMLinstance form, from which all other views are generated.

Implementation Technology Specification (ITS) ComponentsITSs are the concrete expressions of abstract specifications in specific implementation-oriented tech-nologies, and are the artifacts used directly for building software and databases. They are generatedvia a mapping process, and may have reduced semantic content, e.g. they might not include certainabstract semantics such as functions, invariants. For example, the XML-schema ITS does not containfunctions, since XML-schema is a data-oriented formalism, and does not have a way (or need) toexpress functions. Otherwise however, ITSs do include full coverage of all the relevant openEHRspecifications. The two categories of ITS are as follows.

Interoperability specifications include any expression of an abstract specification in a concreteinteroperability technology, including:

IDL expressions, e.g. in OMG IDL syntax, DCE syntax Microsoft, WSDL, or other publiclyavailable interface formalisms

XML schema or other XML-based formalism

Implementation specifications include any expression of an abstract specification in a concreteimplementation technology, including:

any programming language. Such expressions may be code interfaces, example workingcode, or other code guidelines.

any database schema language. Such expressions may include full schemas for particulardatabase products and generic schemas for a class of product.

Change ManagementIn the above table, the items in the Component column are the items against which problem reports(PRs) are made. In general, PRs will only be raised against executable components or computablecomponents like XML-schemas.

The abstract architecture deliverable (second major row of table) is the main driver of major releasesof the specification project. That is to say, if the abstract models change in any significant way, a newrelease is declared. The Architectural Review Board (ARB) decides on new releases.

Deliverable Component Description

ImplementationTechnology

Specifications(ITSs)

ITS-java Java expression of architecture specificationsITS-xml_schema XML-schema expression of architecture specificationsITS-idl OMG IDL expression of architecture specificationsITS-csharp C# expression of architecture specificationsetc other languages,

Conformance Conformance Test cases and plans for testing of conformance of openEHR implementations against Requirements and ITSs.



openEHR Technical Projects The openEHR Change Management PlanRev 1.0

Changes in the abstract architecture models will immediately cause changes in the ITSs, since theseare the directly usable expression of the abstract architecture. However it might be some monthsbefore various implementation projects are changed to reflect specification changes.

3.2 Reference Implementation ProjectsReference implementation projects produce artifacts of which only one official version is needed.These are usually used as the basis for conformance testing, or in some cases, are core software com-ponents that must have guaranteed correctness and reliability. The following table shows a number ofopenEHR reference implementation projects.

3.3 Ad hoc Implementation ProjectsThe ad hoc implementation projects produce non-reference tools or systems based on any referencedeliverable, whether directly from specifications, or on existing components. Over time, there maywell be multiple projects each implementing the same category of deliverable, such as an archetypeeditor or EHR server; products developed in this way will usually perform the same general function,but may have significantly different performance characteristics, user interface design approaches, ordiffer in some other way relevant to end use. The following table shows a list of possible openEHRprojects, and their components.

Project Component Description

Tools (various)

This project develops various tools any converter that creates a derived artifact from an

abstract one tools for validating specifications in the reference

model tools for working with test data or test cases archetype and template validation tools

KernelKernel in lang X

Open source implementation of the openEHR refer-ence and archetype models, as an archetype- and template-enabled data processing component.

Wrappers in other languages

Open source implementations of wrappers of the kernel for other development languages

ADL Parser

Eiffel ADL Parser Original ADL reference parser implementing current version of the ADL specification.

Java-wrapped ADL parser

Java wrapping for the parser, implemented using JNI

dotNet ADL parser Dotnet edition of the parser, for MS Windows.etc

Project Component DescriptionArchetype Editor Tool for creating and viewing archetypes.

EHR server EHR repository providing versioned Contribution interface, with transaction managementDemographic

serverDemographic data repository, providing versioned Contribution interface, with transaction management



The openEHR Change Management Plan openEHR Technical ProjectsRev 1.0

etcProject Component Description



Repository Organisation The openEHR Change Management PlanRev 1.0

4 Repository Organisation

4.1 Repository NamingEach openEHR project is controlled in a separate versioned repository. Currently, the Subversion toolis used to manage repositories (see http://subversion.tigris.org and the relevant openEHRwebsite pages). Due to the way Subversion works, each project is a separate repository (explainedin detail in next section). Further, since most implementation efforts are oriented to one or other of themajor technologies avalailable, repositories are also distinguished on this basis. Technologies include:

Java and related frameworks, such as Eclipse, NetBeans, EJBx, J2EE, Hibernate etc; Microsoft .Net technologies, including C#.Net and VB.Net languages; Python and related tools such as Zope and Plone; The Eiffel language and technologies.

Repositories are separated on the basis of coherent projects rather than fine-grained choices of e.g.persistence framework for Java. Thus, the Java reference kernel project might develop one set ofbase libraries, and two alternative persistence mechanisms. If all of this work forms a coherent whole,it will be defined as a project, and have its own Subversion repository. On the other hand, not allthings done in a given technology need be in the same repository. Knowledge tools such as archetypeeditors and repository tools built in Java would have their own repository, since the project is inde-pendent of the EHR kernel and server work, and developed by a different group. There is no problemfor sharing libraries from one project with another - this is simply done by setting up the user work-space on the client machine appropriately, so that build scripts can find all the software.

In general the repositories are also desgined as source-only repositories; there is a separate reposi-tory for distributable binaries.

4.2 Repository DesignThe openEHR subversion repositories include the following:

specification: the specification project knowledge: clinical domain content, including terminology, archetypes, templates etc knowledge_tools_java: knowledge management tools built in Java, including a Java arche-

type editor knowledge_tools_dotnet: knowledge management tools built in .Net languages, including

the Ocean Informatics VB.Net archetype editor ref_impl_java: Java implementation of openEHR reference and archetype models, and

archetype-processing kernel ref_impl_dotnet: Microsoft .Net implementation of openEHR reference and archetype

models, and archetype-processing kernel ref_impl_eiffel: reference implementation of openEHR in the Eiffel language oe_distrib: repository containing binaries and packages for distribution.

Other repositories will be defined as the need arises. The full list of projects can always be found onthe projects button on the openEHR home page.

The internal structure of repositories tries to achieve two (sometimes contradictory) aims:

http://subversion.tigris.org/http://www.openehr.org/developer/t_svn_um_top.htmhttp://www.openehr.org/developer/t_svn_um_top.htmhttp://www.openehr.org/



The openEHR Change Management Plan Repository OrganisationRev 1.0

enable basic functioning of Subversoin; be consistent across repositories, in order to facilitate comprehension by new project mem-

bers; be consistent with accepted conventions for the relevant implementation technology, partic-

ularly as required by build tools or other framework components.

In support of the first aim, the following top-level structure is usually used:

TRUNK: mainline current development; BRANCHES: branch developments for new or alternative or test work; TAGS: named baselines (no development allowed) RELEASES: release branches, i.e. branches corresponding to stable major points in the

mainline (trunk) development, whose only further allowed changes are bugfixes.

This corresponds more or less to the recommended way in Subversion of separating mainline devel-opment; the only difference is that in openEHR upper-case directory names have been chosen tomake the special status of these directories clear in a check-out structure, and the RELEASES direc-tory has been added.

Further directory structure is built under the TRUNK directory. The following top-level division maybe used:

apps: subdirectories contain sources corresponding to various standalone applications; components: subdirectories contain sources corresponding to re-usable components, usu-

ally in the form of libraries such as dlls etc; libraries: subdirectories contain sources of libraries which are (re-)used at compile time by

other libraries, components or applications; distrib: sources or files requred for building or configuring distributable artefacts.

Below this level, directories would normaly have the name of the particular library, component orapplication. Below that, the following standard names can be used where sensible:

src: source; doc: documentation of source code; lib: sources which correspond to a binary library, i.e. a .so or .dll; conf or etc: configuration files; app: source corresponding to a standalone application or utility.

The above structures should be treated as guidelines; recommended directory structures are usuallyavailable from the documentation of tools being used.



Release Management The openEHR Change Management PlanRev 1.0

5 Release Management

5.1 OverviewA named release is formally defined as a named list - known as a baseline - of the set of control-led items in a repository, and their individual version numbers at the point of time of the release.Releases correspond to the release of major additions in specification or functionality of the totalproduct, and usually occur in coarse-grained time, e.g. every quarter, six months, or year. Everychange request that is processed between releases is targetted to a particular release, usually the nextone, but not necessarily - the CM system allows multiple future releases to be running at once.

Releases are created in Subversion repositories simply by performing an svn copy operation, whichessentially creates a lazy copy of the current state of a repository. Inspecting the RELEASES direc-tory in any repository will which release branches have been created; inspecting the TAGS directorywill show exactly the release points that have been tagged. For a given release branch, e.g. release0.9 of a repository, there may be more than one tag, e.g. 0.9, 0.9.1, 0.9b and so on.

Each release proceeds through a number of phases. The rules about what kind of changes can be madeto the repository during the phases vary, as shown in the following example:

phase = development any changephase = test only changes to correct errors or bugsphase = production only changes to correct bugs found in use

The actual phases used in openEHR repositories may vary with the repository. In fact, only the differ-ence between development and after development phases are made by branching the repositories.

All releases are named release-XXX, e.g. release-1.5, where 1.5 is the release identifier.Release identifiers can be any string.

5.2 Release Structure and BranchingThe relationship between releases is worth explaining in some detail, since it is the basis of the work-flow of any project. FIGURE 4 illustrates a typical workflow. Typical activities are as follows.

Work starts on the mainline of a repository (in the TRUNK directory), and continues forsome time.

At some point, it is decided that the state of work is stable enough to declare as a namedrelease that could be used outside the development team. What happens at this point is that alogical branch is created, representing the named release, while the mainline evolves susual. With Subversion, a branch is effected simply by an svn copy of the current TRUNKcontents to the a named directory in the RELEASES directory.

The directory hierarchy in RELEASES corresponding to the logical branch is now consid-ered to be limited to that release, i.e. it is considered to be in a testing phase. The only allow-able changes to it are bug and documentation fixes.

Tags can be made of any of the states of a release by performing the appropriate svn copycommand from (for example) RELEASES/release-xyz to TAGS/release-xyz.n.

Meanwhile, general development continues on the repository mainline in the TRUNK. Astime goes on, fixes will accumulate in each release branch made to date, due to testing anduse. Usually these fixes will be needed on the mainline development as well; the way toobtain them is to create a patch containing changes since the beginning of the branchrepository, and apply it to the repository mainline (red dashed arrows right to left).



The openEHR Change Management Plan Release ManagementRev 1.0

This operation may be repeated, where each patch is generated from the change followingthe last change in the previous patch.

Eventually another release will be declared, and the whole operation will repeat, leading to (for exam-ple), xxx-dev, xxx-0.9 and xxx-1.0 repositories. As time goes on, users will start using the xxx-1.0release, and xxx-0.9 will fall into disuse, and could ultimately be declared obsolete (no longer sup-ported) and be archived.

FIGURE 5 illustrates this release logic applied to the openEHR specification repository. The initialrepository is spec-dev, i.e. the main line of development in which all kinds of changes are added. Atsome point it will be cloned into spec-0.9, a branch for the 0.9 release of the openEHR specifications.The only changes permitted to be done to the spec-0.9 repository are those that fix bugs or problemsdesignated to be fixed in release 0.9. At a later point in time, a spec-1.0 repository is created.

The changes made to release-0.9 and release-1.0 may be transmitted one at a time back to specifica-tion/TRUNK, by systematic patching, or cumulative patches may be made. Patches may also be madefrom specification/RELEASES/release-0.9 to specification/RELEASES/release-1.0.

xxx/TRUNK

xxx/RELEASES/relA

FIGURE 4 Branching

main linedevelopmentfor proj xxx

any change

production fixes only

branch operation

release Abranch

repository

patch

testing changes onlypatch

clone

spec/TRUNK

FIGURE 5 Release Structure for the specification repository

spec/RELEASES/release-0.9

spec/RELEASES/release-1.0

clone

patch

patch

patch

clone



Release Management The openEHR Change Management PlanRev 1.0

5.3 Release NamingWith the advent of Release 1.0 of openEHR, more rigorous change management rules come into play.These are designed to protect developers and users from adverse effects of changes, and to allowthem to upgrade in an orderly fashion. Future releases will follow a 3-digit numbering scheme similarto many open source projects, e.g. Apache, using identifiers like 1.0.1 etc. The meaning of a changein each digit is as follows:

3rd position: used to indicate error corrections and minor additions that do not change thesemantics. Thus, Release 1.0.2 is the second error correction release after Release 1.0.

2nd position: used to indicate significant additions that do not change the semantics of theexisting part of the release. Release 1.3.0 would be the 3rd release containing compatibleadditions to Release 1.0.

1st position: used to indicate changes to the semantics or large changes. Release 2.0 wouldcontain changes incompatible in some way with Release 1.0, most likely requiring softwareupgrade and possibly data migration.

Changes to DocumentationWhere changes to documentation are made, e.g. due to a request to clarify an explanation, fix a typo-graphical error, a CR will be raised, and the revision number of the affected document(s) will change,but there will not be a new release number.

Error CorrectionsWhere the changes made are to correct an error in a model, parsing rules or some other aspect of theformal semantics of the specifications (and possibly also change explanatory text), an error-correctionrelease will be made.

Compatible AdditionsWhere the changes have the effect of adding a new specification or other artifact which is completelycompatible with the current release, an enhancement release is made.

Major ChangesWhere changes actually alter semantics of existing artefacts, a new major release is declared. Suchchanges would normally be grouped into as few such releases as possible.



The openEHR Change Management Plan Change ManagementRev 1.0

6 Change Management

6.1 OverviewThe approach to change management described here has been developed from change managementplans used in a number of industrial contexts. Useful published resources for interested readersinclude the IEEE standards for configuration management, change management and related issues. Agood online resource explaining the concepts at the Technical University of Eindhoven (softwareengineering home page, CM top page).

FIGURE 6 illustrates the overall openEHR change environment. For each project, a repository that iscontrolled by the configuration management (CM) system, and whose items (documents, source, etc)are created and modified by project groups (PGs). The entire openEHR community can access therepository for retrieval, or copy-out. Those developers in identified project groups can performmodifications to the controlled items according to the process described below. All community mem-bers can raise Problem Reports, and those members in an openEHR team can raise Change Requests.

The key elements of this environment are as follows.

RepositoryThe repository of deliverables (centre). Includes all documents, software source, and related informa-tion needed to recreate a deliverable from scratch.

The Configuration Management (CM) systemThe system controlling access to the repository, performs versioning of controlled items, release iden-tification, and manages change requests. The CM system enables any previous version of the reposi-tory to be obtained. Implemented in openEHR using Subversion and various online change requestand problem reporting tools.

Project Group (PG)Formally constituted team that is responsible for the development of deliverables of the project.These teams can be considered formal developers in the sense that they are defined users in the CM

users

CM system

PG

repository

ARB

check

check-out

FIGURE 6 openEHR change model for reference projects

outcheck

in

download

(source)

buildserver

crossload

http://wwwis.win.tue.nl:8080/2R690/se_cont.htmlhttp://wwwis.win.tue.nl:8080/2R690/se_cont.htmlhttp://wwwis.win.tue.nl:8080/2R690/cm_chang.html



Change Management The openEHR Change Management PlanRev 1.0

system and can execute a change via a check-out / modify / validate / check-in sequence. The projectgroup can raise Problem Reports (PRs) and Change Requests (CRs) at any time and are also responsi-ble for preliminary review of non-trivial PRs and CRs according to the change management processdescribed below.

The User CommunityThe openEHR community at large, consisting of any user or interested person or organisation. Usersin the community who are not in the informal or formal development pool, can copy-out all delivera-bles and can raise PRs. Users who are not otherwise developers or technically involved in any waytypically only download binary software builds.

The Architectural Review Board (ARB)The ARB is formally constituted of experts from diverse backgrounds, and operates according to theopenEHR ARB Terms of Reference. Its main activity is the review of major CRs, according to thechange management process described below. The ARB does not create PRs or CRs, and it does notreview PRs, being concerned only with change. (Naturally there may be some members of the ARBwho, in their role as a PG member may create PRs and CRs).

6.2 The Change ProcessThis section describes in detail the change process that applies to openEHR projects. However, read-ers do not need to know all the details to work on a project - the following processes and documenta-tion are generally supported by online tools that ensure that the process is easy to participate in andfollow.

6.2.1 OverviewChanges are made to a repository by members of the relevant project group. All changes have aChange Request (CR). A CR can only be raised by someone in the project group, and is the keydocument in the change process, being used to record all status and analysis information relating tothe change from its opening to rejection or resolution. CRs are raised either to fix problems, or to per-form enhancements to a component. A CR that is designed to fix a problem may refer to existing PRs(usually problems reported in released binaries by users), or the problem may simply be documentedin the CR itself (typically the case when a developer finds a problem).

A PR is raised describing in detail a problem or deficiency in a component or product, as perceived bya user (including developers acting as testers). Such descriptions tend to be at a coarse granularity ofcomponent or functionality, and only about main releases. A PR can be created by anyone. A PR cor-responds to a black-box view of the product or component - the raiser doesnt care how it is imple-mented, only that it is not working properly. Problem Reports have a simple lifecycle: they are raised,then either rejected or resolved. If not rejected, a PR is always resolved by one or more CRs. A CRmay resolve one or more PRs. FIGURE 7 illustrates the relationship between PRs and CRs within theuser and developer spaces respectively.

The scope of CR is always a whole repository (i.e. a whole project) even if it changes only a singlefile. In many cases, a CR causes changes in one project (e.g. the specification project) that will needto be taken into account in another repository (e.g. one of the implementation projects). It is up to themanagers of each project to decide on an appropriate moment to incorporate the relevant changes intheir repository.



The openEHR Change Management Plan Change ManagementRev 1.0

6.2.2 Problem ReportingNew Problem Reports (PRs) are created by users. They are reviewed initially be the relevant projectgroup, and are either rejected or cause the creation of one or more new CRs, or the modification ofexisting CR(s). Any CR related to a PR in this way should include the PR id in itsproblem_description. The CR then enters the process described below. If the CR is implemented andsolves the problem, any PR(s) referred to in its problem_description section are progressed to theresolved state. FIGURE 8 illustrates the PR lifecycle.

6.2.3 Change Request Process for openEHR Reference ProjectsThis section describes a change process in which a board of review as well as the project group proc-esses CRs. In openEHR, this process is applied to all reference projects, and any ad hoc projectsrequiring more disciplined change control.

6.2.3.1 WorkflowA new CR created by any project developer, and may be due the review of one or more PRs. Theprocess of handling a CR in a project using a review board is illustrated by FIGURE 9. If a CR is notrejected at some point, it is eventually implemented, causing changes in the appropriate repository.

Assuming sufficient repository-wide quality controls are applied before a CR is closed (such as docu-ment review, guaranteeing that change source compiles, builds and runs, and so on), the repository is

FIGURE 7 Relationship between PRs and CRs

User space Development space

prod Xrel 1.5

prod Yrel mar2004

PR

PRPRPRPR

PRPR

PR

PRrelease

releaseCR

CRCR

CR

CR

CR

CRlifecycle

PRlifecycle

initial

underway

rejected

resolved

FIGURE 8 PR Lifecycle

PG rejects

PG r