the openehr archetype formalism

© Thomas Beale 2011

Thomas Beale, Sam Heard MD, Hugh Leslie MD

The openEHR archetype formalism CIMI forum 09 Oct 2011


Overview


This presentation

openEHR goals – what was important to us openEHR archetype background The formalism Terminology connection Templates Querying Tools and Specifications status Conclusions Resources


openEHR Goals


Ultimate ICT goals

• To compute with health information • Cross-enterprise • Cross-system • Cross-product / vendor • Patient-centric • Over time & technology changes


Ultimate ICT goals

• In particular: • X-enterprise patient care pathway tracking • Decision support for doctors • Business process analysis for provider orgs • Business intelligence for payers & public health • Medical research ‘study’ analysis • Person-centred data analysis, ethically targetted

marketing etc • Integrate health data with social & educational

media streams in patient-centred portals


Ultimate ICT goals

• While dealing with relentless change in • Medicine, esp. drugs, interactions, procedures... • Information • Care processes • Patient needs • Legislation


Getting there requires...

A ~change-immune semantic architecture, allowing meaning of information and healthcare process

steps etc to be reliably defined convertability of information from proprietary /

legacy sources to common formats computability of information by inferencing

engines, decision support, business intelligence, using knowledge bases


Getting there requires...

A systems and services architecture defining groupings and access protocols enabling: Aggregation of information from source systems Varying levels of conformance, esp. for existing

systems Incremental deployment Satisfying changing business needs


Assumptions

A services architecture with no semantic underpinning can deliver: Human – human information transmission Very basic search facilities Limited computability, where information is

already widely standardised, e.g. HL7v2 lab, ADT Some security / privacy support

But not generalised patient-centric computability – can’t access the main economic potential


The clock is ticking...

Today we are still creating peta-bytes of non-interoperable, non-computable health data

Post-hoc ‘re-engineering’ of the data to make it computable is too expensive to be realistic

We know this because medical research projects regularly burn their entire budget on data re-engineering


openEHR archetype background


Requirements based • Good European Health Record (GEHR)

Project 1992 - 1995 • ISO 18308 Technical Report

University of Hull

Croix Rouge Francaise

SmithKline Beecham

United Kingdom St Bartholomew’s Hospital

Medical College The Royal Hospitals NHS Trust

City & East London FHSA The Royal Marsden Hospital

Instituto Clinica Geral Zona Norte

Portugal

Clinica Puerta de Hierro Spain

Association des Medecins et

Medecins Dentistes

Luxembourg

Microdata SARL Centre de Recherche Public

Henri Tudor

Zentralinstitut fur die Kassenarztliche Versorgung

Germany

University of Athens Greece

France Telecom

France

C2V Kalamazoo S.A.

Belgium Health Data Management Partners

ERIM Federation des Association Medecins

Generalistes de Bruxelles Insitut D’Hygiene et d’Epidemiologie


openEHR and ISO 13606 GEHR

CEN ENV13606

openEHR draft

CEN 13606 drafting

folders

record architecture

ADL 1.2

openEHR 0.95 ADL 1.4

openEHR 1.0

openEHR 1.0.1

openEHR 1.0.2

CEN EN13606

ISO 13606 2008

2007

2006

2005 2004 2002 2000

1998

1991

ADL/AOM 1.5 2011-


About the approach

Fundamental assumptions: Existing Reference Model, expressed in UML Defines the data ‘syntactic’ interoperability Used to build back-end software, databases,

documents, messages etc

Content ‘modelling’ requires constraints Many/most model ‘concepts’ have no defined

concepts in terminology (today) has to be an internal terminology capability


About the approach What key requirements did we try to satisfy?

Will work with ANY RM & data types

Definition of standard content elements (archetypes) Identified and encapsulated (i.e. not a giant terminology)

Definition of use-case specific data-sets (templates) UI forms, messages, reports, documents

Flexibility of content – optionality; RM typing; ranges

Reusability: specialisation & composition of models

AD-16

ST-01,02 AD-17

ST-04

CO-*

ST-03,5-7


About the approach What key requirements did we try to satisfy?

Creation of new data via use of templates

Validation of incoming data

Querying of data based on the content elements & RM

Integration with terminology

Multi-lingual

Works with stable RM – future proof Supports continual incremental deployment

AD-14 AD-15 AD-06

TS-*

TS-07

ST-09


About the approach

First we devised an architectural framework based on these requirements


Levels of Semantic Organisation

Data Structures

Data Types

DemographicEHR

Security

EHR Extract

virtual EHR

Archetype OM

Support (identifiers, terminology acce ss)

AM

RM

SMEHR

servicearchetype

servicedemographic

serviceterminology

service

{core

Common{patterns

{domain{ }Integration

Composition openEHR Archetype Profile

Template OM

Concrete: GUI, messages, documents

1:N

Business-event specific data sets - Templates

1:N

Data Representation and sharing - Reference Model

Theme-based models of content - Archetypes

1:N

Querying

Terminology Interface

Discharge summary UI form

Discharge summary content model

HbA1C, phys. exam, meds list, vital signs etc

Observation, Quantity, coded text etc


openEHR scope

openEHR Semantic architecture

Templates

1:N

Reference Model

Archetypes

1:N

Terminology interface

Querying

1:N

Screen Forms

Messages 1:N

Reports

Data conversion rules Terminologies

Snom

ed CT

ICD

x

ICP

C

Defined connection to terminology

Portable, model-based queries

All possible item definitions for health

Use-case specific data-set definitions

Defines all data


Why current Health Information Systems don’t solve the problem

They have a form-builder

Possibly a library of ‘elements’

Data Structures

Data Types

DemographicEHR

Security

EHR Extract

virtual EHR

Archetype OM

Support (identifiers, terminology acce ss)

AM

RM

SMEHR

servicearchetype

servicedemographic

serviceterminology

service

{core

Common{patterns

{domain{ }Integration

Composition openEHR Archetype Profile

Template OM And a proprietary database

And only SQL, to query against the proprietary database


Collaborative knowledge repository

In the real world... Int’l

archetypes Nat’l / local templates

s e ts

terminology

All data = same information model data

canonical openEHR

java

C#

etc

Querying

Template- based artefacts

Nat’l / local archetypes

f re

RM + DTs

AQL

ADL, AOM, TOM


The key to building systems Is the operational

template (OPT) – this is the joining point between the semantic specifications and deployable software artefacts that can be used by normal developers

An OPT is just a giant archetype

Evaluate inclusions,

flatten inheritance


The key to (re-)using data

s e ts

terminology

f re

All data = same information model data

AQL

Is paths from archetypes & terminology

No dependency on physical DB schema


The formalism


We looked at various formalisms

KIF – requires conversion of RM to KIF first; obsoleted by OWL

XSD – does have constraints, reasonable data types, but inheritance model completely broken; can’t really be used for ‘modelling’, only definition of XML data

OWL – requires conversion of RM to OWL first; oriented to expressing ‘facts’ + reasoning on them Did an experiment in 2005 with Manchester Uni, OWL 1.1 – failed –

leaf types too weak; RM needed its own ‘namespace’ Today’s OWL much stronger; integrating with RM still ~messy However, various groups working on ways of doing it



OCL – can express constraints, but it is class-based, not object-based every constrainable element now has to be a class, e.g.

SystolicPressure This does not scale well - see real BP archetype – would need around

50 classes; with 300 archetypes, could easily need 10,000 classes – UML tools are not designed for this! With 1,500 DCMs....

There is no built-in way to do an archetype ‘slot’ or slot filler Requires numerous fake abstract super-types

There is no built-in terminology capability

OCL constraints are not specialisable down the inheritance hierarchy

No direct way to derive queries from DCMs



UML is designed to be additive down the inheritance hierarchy (which is correct for information modelling)

But for constraint-based models, required specialisation semantics down the inheritance hierarchy is subtractive

It is therefore difficult to clearly define a content UML model (e.g. BP) that constrains another UML model (the RM)

Constraining directly in UML is likely to lead to a basic modelling error – the ‘wingspan’ error See http://wolandscat.net/2011/05/24/ontologies-and-information-

models-a-uniting-principle/

CONCLUSION: although UML/MOF is very powerful, achieving the required aims involves a lot of ‘fighting the formalism’

http://wolandscat.net/2011/05/24/ontologies-and-information-models-a-uniting-principle/�

http://wolandscat.net/2011/05/24/ontologies-and-information-models-a-uniting-principle/�


About the approach What key requirements did we try to satisfy? Definition of standard content elements (archetypes)

Definition of use-case specific data-sets (templates) UI forms, messages, reports, documents

Flexibility of content – optionality; RM typing; ranges

Reusability: specialisation & composition of models

Creation of new data via use of templates

Validation of incoming data

Querying of data based on the content elements & RM

Integration with terminology

Multi-lingual

Works with stable RM – future proof

ST-01,02

ST-04

CO-*

ST-03,5-7

REQ??

REQ?? AD-06

TS-*

TS-07

ST-09

WE NEED A PURPOSE-BUILT FORMALISM &

TOOL ECO-SYSTEM


About the approach

A custom formalism can meet all the requirements in an efficient and clear way

Formalisms not originally designed for the job require: Adaptation Integration of multiple tools / formalisms Specific use / style guides Maturity lifecycle – it takes time Fighting the formalism


About the approach

Should we ignore other formalisms? No... Point 1: If other formalisms are to fulfill all the

requirements, the overall ‘toolkit’ will eventually have to replicate everything done by archetypes

With enough effort this is not out of the question, but is likely to take some years

?do a MOF or OWL tooling project over next 5y while using Archetypes/Templates – already working (with 10y R&D already done)?


About the approach

Point 2: But partial mappings can be very useful E.g. OWL has far more reasoning power E.g. MOF/based environment may provide better

software development integration facilities outward generation may not be too hard, and

may have good value for downstream (system building) and upstream (validation) purposes


Archetype basics

We first developed ADL (10 jul 2003 1st ed.) Archetype Object Model (10 Nov 2004) XML expression ~2005 - lossless


Archetype basics

Archetypes can be defined with the same formalism for ANY reference model We use the openEHR RM because it is specifically

adapted to content modelling – change requests over 8 years came from clinical

modellers

Today about half the tools are RM-driven, and others hardwired

A normal RM is needed to enable large-scale high-performance data processing systems to be built

REQ-AD-16 (RM-indep’t)


Archetype basics

Archetypes and templates are separately identified, ‘small’ models – i.e. Not like terminology REQ-AD-17

(encapsulated)


XML-enabled

About XML... Everyone wants it in tools No-one can read it for education & specification purposes, we use

ADL – same role as OWL-abstract EVERYTHING YOU SEE HERE IN ADL ALSO

EXISTS IN XML

Don’t panic

REQ-ST-08 (serialisable)


Basic Structure of an archetype


RM class

RM attribute

Constraint operator ∈

Semantic marking

Language support

Identifier

Local term definition

Value constraint

REQ-TS-07 (language)

REQ-CO-07 (intra-elem constraints)

REQ-ST-01 (data elements)

REQ-ST-02 (Struct. Rel’ns)

REQ-AD-17 (Encapsulated)


A real one...


Meta-data REQ-AD-08 (meta-data)

BUT: archetypes do not try to include all meta-data

REQ-ST-13 (model content)


Languages

REQ-TS-07 (languages)


Constraint basics

Can constrain: •types •values •cardinality •existence •occurrences

REQ-CO-2 (cardinality)


Constraints - occurrences

Occurrences: how many times in the data can this node occur?

REQ-CO-02 (occurrences)


Constraints – alternatives

DV_TEXT or DV_URI ok

Single- valued

attribute

REQ-CO-09 (choice)


Constraints – match most specific first

Organisation instance matches ORGANISATION constraint; Person instance matches PERSON constraint; any other Party instance matches PARTY constraint

REQ-??-?? (preferred matching)


Constraints – group operator

REQ-??-?? (grouping)


Constraints – node-level annotations

REQ-??-?? (annotations)


Constraints – slots

ADL1.4

ADL1.5

REQ-ST-03 (reusable models)

REQ-ST-05 (composability)


Constraints – external ref

This enables direct re-use of an archetype by another archetype REQ-ST-05

(composability)

REQ-ST-03 (reusable models)


Cross-attribute constraints

‘rules’ section (ADL 1.5; ADL1.4 – ‘invariant’ section)

Xpath-based FOPL Standard operators Built-in Variables

$current_date: ISO8601_DATE $current_time: ISO8601_TIME $current_date_time: ISO8601_DATE_TIME $current_year: Integer $current_month: Integer

REQ-CO-08 (reusable models)



Archetype-defined Variables $diagnosis:CODE_PHRASE ::=

/data/items[at0002.1]/value/defining_code

External symbolic queries $date_of_birth:ISO8601_DATE ::= query(“ehr”,

“date_of_birth”) $has_diabetes:Boolean ::= query(“ehr”,

“has_diagnosis”, “snomed_ct::1234567”) $is_female:Boolean ::= query(“ehr”, “is_female”)



Rules $systolic ::=

/data[at0001]/events[at0006]/data[at0003]/items[at0004]

$diastolic ::= /data[at0001]/events[at0006]/data[at0003]/items[at0005]

$systolic > $diastolic

Outstanding Formalism not 100% finalised in ADL 1.5

Not widely implemented in ADL 1.4

Q: are rules ‘assertions’ or computational formulae – e.g. BMI?


Specialisation

Enables a new archetype to be constructed as a specialisation of an existing one

A template is just a kind of specialised archetype Model of specialisation designed to ensure data

built from child archetype will validate against parent subsumption logic Redefinition of existing nodes - narrowed constraints

New nodes can be added – specific to specialisation


REQ-ST-07 (specialisation)


Parent archetype

Specialisation child – Source form

Specialisation child – Flat form

flattening


Templates


Template formalism

Today, the community uses a simple XML formalism developed (organically) by Ocean (http://www.openehr.org/releases/1.0.2/its/XML-schema/Template.xsd )

In ADL 1.5, templates are expressed in ADL / AOM – same as archetypes one formalism for everything

Templates are just specialised archetypes

http://www.openehr.org/releases/1.0.2/its/XML-schema/Template.xsd�

http://www.openehr.org/releases/1.0.2/its/XML-schema/Template.xsd�


Template formalism

What you can do in a template: Compose overall structure ‘slot-filling’ slots For all archetypes used, ‘remove’ unneeded

elements: occurrences = {0} Impose further constraints Any normal archetype constraint can be narrowed Terminology value-sets tightened Terminology ref-set references added

REQ-ST-04 (use case dep’t

models)


Templates – remove unneeded elements

Archetype used in a template

Templated form


Templates – top-level template

Slot filling

Make elements mandatory

Slot-closing


Templates – operational template


Templates – OPT XML (AOM 1.5)


Terminology connection


The b(l)inding truth...

• A majority of concepts and refsets needed in DCMs are either not defined in any external terminology or ontology, or have extremely ambiguous mappings

• Why? It appears to be because of the difference between: • How clinicians understand their information – very

operationally • How terminologists ‘describe’ the world –

somewhat theoretically


Term definitions & bindings

Bind individual terms to Snomed codes REQ-TS-03

(sem. binding)

REQ-TS-08 (multi-purpose)


Which SCT concept do we pick?

If we bind |systolic blood pressure| (usually means instantaneous), SNOMED-driven queries would pick up 24h av, max, min etc


can ‘systolic’ be post-coordinated?


|Bp| v |bp finding|


314449000| Average 24hour systolic blood pressure|

271649006 |systolic blood pressure| OR 72313002|systolic arterial pressure| OR 399304008|Systolic blood pressure on admission| OR....

Archetype paths


Considerations

Many parts of SNOMED, excessive precoordination makes it difficult to know what to choose

Crucial problem: whatever binding modeller chooses, query author might choose a different concept, and the results may not be correct.


Ref set binding

What is needed: a standardised URI for referring to Ref sets

Ref set refs mostly used in templates, not archetypes

REQ-TS-01b (intens. refset)


Problem/diagnosis


constraint_bindings = < [“SNOMEDCT”] = < items = < [“ac0.1”] = <http://www.terminology.org?refsetid=20293847593 > > >


All Infectious Agents ref set

Definition

Result


Internal value sets

Many value sets have to be internally defined Often no external concepts available, or no

ref set available Advantage of archetypes: Bindings can always be added later!!!

REQ-TS-01a (intens. refset)


Ex: Adverse reaction


ADL view


Querying


Constraints – paths


BP archetype paths


Paths Xpaths

/data[at0001] /events[at0006] /data[at0003]/items[at1006]/value

= /data[@archetype_node_id = ‘at0001’]

/events[@archetype_node_id = ‘at0006’] /data[.... Etc

Archetype paths can be used with native XML data


AQL query SELECT com2/context/start_time/value as START_DATE,

obs1/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude as SYSTOLIC, obs1/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude as DIASTOLIC, obs3/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude as PULSE_RATE, obs4/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value/magnitude as RESPIRATORY_RATE....

FROM EHR e[ehr_id/value='f271cd26-23fc-43a1-b411-34cdadaea067'] CONTAINS COMPOSITION com2 [openEHR-EHR-COMPOSITION.encounter.v1]

CONTAINS (OBSERVATION obs3 [openEHR-EHR-OBSERVATION.heart_rate-pulse-zn.v1] OR OBSERVATION obs1 [openEHR-EHR-OBSERVATION.blood_pressure-zn.v1] OR OBSERVATION obs4 [openEHR-EHR-OBSERVATION.respiration.v1] ....

WHERE com2/name/value matches {'Vital functions', 'Respiratory assessment', 'Assessment scales'} AND obs9/name/value = 'PEF before' AND obs10/name/value = 'PEF after' AND com2/context/start_time >= '20110406T000000.000+0200' AND com2/context/start_time < '30000101T000000.000+0100' REQ-AD-06

(queryable)


AQL – Archetype Query Lang.

Specification at http://www.openehr.org/wiki/display/spec/AQL-+Archetype+Query+Language

http://www.openehr.org/wiki/display/spec/AQL-+Archetype+Query+Language�

http://www.openehr.org/wiki/display/spec/AQL-+Archetype+Query+Language�


Operational use

Archetypes and Templates deployed in hospitals (Aus, Europe, Brazil...), cancer registry (Aus), gov. Programmes (Aus, NZ, SE, BR...) Some systems create initial data from template All systems validate data to be committed against

templates & archetypes

AQL deployed and heavily used for populating screens, reports etc

REQ-AD-14 (data creation)

REQ-AD-15 (data valid’n)


Tools & Specifications status


The archetype specifications

Primitive types, Ids

.oet-based downstream artefacts TDO, TDS

current stable release 1.0.2

Archetype Object Model 1.4 (AOM)

Archetype Def. Lang. (ADL 1.4)

Ocean .oet XML template format

official de facto

DSTU

ADL 1.5 templates

Archetype Object Model 1.5 (AOM)

Archetype Def. Lang. (ADL 1.5)

ADL 1.5 OPT late dev’t

OPT-based downstream artefacts TDO, TDS

earlydev’t

Archetype Query Language (AQL)

Today’s stack Target stack

ISO 13606-2

REQ-??-?? (spec. Avail.)


About ADL 1.5


openEHR Archetype tools - today

openEHR Reference Model

specifications

openEHR RM XSDs

Compile ADL 1.4 and 1.5 archetypes

Edit archetypes

Edit templates

Generate artefacts

Template Designer (Ocean, C#.NET)

Various OPT generators free

Integration mapping

Artefact repository CKM

BMM model spec (data view)

ADL Workbench (openEHR, Eiffel)

ADL reference compiler (openEHR, Eiffel)

Archetype Editor (Ocean, VB.NET)

Linköping U. Archetype Editor

(Linköping, Java)

open source

ADL parser (openEHR, Java)

commercial

LinkEHR Archetype Engine

(Valencia U, Java)

LinkEHRed

Various tools

REQ-AD-03 (computable)

REQ-AD-04 (gen. artfacts)


Archetype Compiler

170 test archetypes

Regression testing

43 syntax errors 71 validity errors


Full object model - AOM


tools – future possibilities

ADL Workbench (openEHR, Eiffel)

ADL ref. compiler (openEHR, Eiffel)

Various OPT generators

openEHR Reference Model

specifications

BMM model spec (data view)

openEHR RM XSDs

Compile ADL 1.4 and 1.5 archetypes

Edit archetypes

Edit templates

Generate artefacts

open source

ADL ref.compiler (openEHR, java)

Integration mapping

Artefact repository CKM

ADL 1.5 ref. Editor (openEHR, Eiffel)

Bosphorous (ZeroMQ / PB)

ADL 1.5 Java Editor

(openEHR, java)

Eclipse

EMF/Ecore

x x x

Eclipse archetype

environment


Conclusions

The openEHR community has 10 years’ experience with requirements can use them, and reduce manual rediscovery (CIMI req’ts list can be further improved)

Not everything is 100% complete: ADL 1.5 being finalised; tools still evolving

But a high degree of maturity the incremental cost from here to make

progress is small


Requirements score

Requirements we are unsure of: REQ-ST-11 Model Data Interpretation

Allow the interpretation of values (e.g. cut off points, ranges, min, max values) to be made explicit in clinical models.

REQ-ST-12 Clinical Behaviours /Workflow Allow the clinical behaviour of clinical models to be represented, if these are required to ensure quality data recording/storage.

REQ-TS-05 Design Pattern Define the semantics of a group of data elements (design pattern), in which a ‘focal concept’ data element can be qualified or modified by other data elements in the group (e.g. diagnosis, procedure, medication).


Requirements score

Requirements not directly addressed: REQ-AD-13 Standards

Be considered to work toward the clinical modeling language's conformance to ISO 13972, once this work has arrived to sufficient maturity.

Requirements being implemented: REQ-ST-10 Model Example Data

Allow each model structure to be illustrated using example data to demonstrate its function in clinical practice.

Requirements we might not agree with: REQ-AD-10 Ease of Use

Provide a representation that is easy to use without sophisticated software. (!)

We think it should be easy to use with sophisticated software...


Resources


Resources

ADL 1.4 - http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf

AOM 1.4 - http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf

ADL 1.5 - http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf

AOM 1.5 - http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf

Templates 1.5 (draft) - http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/tom.pdf

http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf�

http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf�

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf�

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf�

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf�

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf�

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/tom.pdf�

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/tom.pdf�


Resources

Archetype Identification (draft) - http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf

Archetype governance (early draft) - http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/dist_dev_model.pdf

Archetype Editor - http://www.openehr.org/svn/knowledge_tools_dotnet/TRUNK/ArchetypeEditor/Help/index.html

openEHR XSDs including .oet template format - http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf�

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf�

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/dist_dev_model.pdf�

http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/dist_dev_model.pdf�

http://www.openehr.org/svn/knowledge_tools_dotnet/TRUNK/ArchetypeEditor/Help/index.html�

http://www.openehr.org/svn/knowledge_tools_dotnet/TRUNK/ArchetypeEditor/Help/index.html�

http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html�


Resources

ADL Workbench - http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html

BMM Schemas - http://www.openehr.org/svn/knowledge2/TRUNK/rm_schemas/

Test archetype repository - http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/

openEHR mailing lists - http://www.openehr.org/community/mailinglists.html

http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html�

http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html�

http://www.openehr.org/svn/knowledge2/TRUNK/rm_schemas/�

http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/�

http://www.openehr.org/community/mailinglists.html�

the openehr archetype formalism

Technology