The openEHR archetype formalism
-
Upload
ocean-informatics -
Category
Technology
-
view
4.010 -
download
0
description
Transcript of The openEHR archetype formalism
© Thomas Beale 2011
Thomas Beale, Sam Heard MD, Hugh Leslie MD
The openEHR archetype formalism CIMI forum 09 Oct 2011
© Thomas Beale 2011
Overview
© Thomas Beale 2011
This presentation
openEHR goals – what was important to us openEHR archetype background The formalism Terminology connection Templates Querying Tools and Specifications status Conclusions Resources
© Thomas Beale 2011
openEHR Goals
© Thomas Beale 2011
Ultimate ICT goals
• To compute with health information • Cross-enterprise • Cross-system • Cross-product / vendor • Patient-centric • Over time & technology changes
© Thomas Beale 2011
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
© Thomas Beale 2011
Ultimate ICT goals
• While dealing with relentless change in • Medicine, esp. drugs, interactions, procedures... • Information • Care processes • Patient needs • Legislation
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
openEHR archetype background
© Thomas Beale 2011
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
© Thomas Beale 2011
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-
© Thomas Beale 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
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
About the approach
First we devised an architectural framework based on these requirements
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
The formalism
© Thomas Beale 2011
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
© Thomas Beale 2011
We looked at various formalisms
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
© Thomas Beale 2011
We looked at various formalisms
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’
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
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)?
© Thomas Beale 2011
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
© Thomas Beale 2011
Archetype basics
We first developed ADL (10 jul 2003 1st ed.) Archetype Object Model (10 Nov 2004) XML expression ~2005 - lossless
© Thomas Beale 2011
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)
© Thomas Beale 2011
Archetype basics
Archetypes and templates are separately identified, ‘small’ models – i.e. Not like terminology REQ-AD-17
(encapsulated)
© Thomas Beale 2011
© Thomas Beale 2011
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)
© Thomas Beale 2011
Basic Structure of an archetype
© Thomas Beale 2011
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)
© Thomas Beale 2011
A real one...
© Thomas Beale 2011
Meta-data REQ-AD-08 (meta-data)
BUT: archetypes do not try to include all meta-data
REQ-ST-13 (model content)
© Thomas Beale 2011
Languages
REQ-TS-07 (languages)
© Thomas Beale 2011
Constraint basics
Can constrain: •types •values •cardinality •existence •occurrences
REQ-CO-2 (cardinality)
© Thomas Beale 2011
Constraints - occurrences
Occurrences: how many times in the data can this node occur?
REQ-CO-02 (occurrences)
© Thomas Beale 2011
Constraints – alternatives
DV_TEXT or DV_URI ok
Single- valued
attribute
REQ-CO-09 (choice)
© Thomas Beale 2011
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)
© Thomas Beale 2011
Constraints – group operator
REQ-??-?? (grouping)
© Thomas Beale 2011
Constraints – node-level annotations
REQ-??-?? (annotations)
© Thomas Beale 2011
Constraints – slots
ADL1.4
ADL1.5
REQ-ST-03 (reusable models)
REQ-ST-05 (composability)
© Thomas Beale 2011
Constraints – external ref
This enables direct re-use of an archetype by another archetype REQ-ST-05
(composability)
REQ-ST-03 (reusable models)
© Thomas Beale 2011
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)
© Thomas Beale 2011
Cross-attribute constraints
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”)
© Thomas Beale 2011
Cross-attribute constraints
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?
© Thomas Beale 2011
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
© Thomas Beale 2011
REQ-ST-07 (specialisation)
© Thomas Beale 2011
Parent archetype
Specialisation child – Source form
Specialisation child – Flat form
flattening
© Thomas Beale 2011
Templates
© Thomas Beale 2011
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
© Thomas Beale 2011
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)
© Thomas Beale 2011
Templates – remove unneeded elements
Archetype used in a template
Templated form
© Thomas Beale 2011
Templates – top-level template
Slot filling
Make elements mandatory
Slot-closing
© Thomas Beale 2011
Templates – operational template
© Thomas Beale 2011
Templates – OPT XML (AOM 1.5)
© Thomas Beale 2011
Terminology connection
© Thomas Beale 2011
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
© Thomas Beale 2011
Term definitions & bindings
Bind individual terms to Snomed codes REQ-TS-03
(sem. binding)
REQ-TS-08 (multi-purpose)
© Thomas Beale 2011
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
© Thomas Beale 2011
can ‘systolic’ be post-coordinated?
© Thomas Beale 2011
|Bp| v |bp finding|
© Thomas Beale 2011
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
© Thomas Beale 2011
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.
© Thomas Beale 2011
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)
© Thomas Beale 2011
Problem/diagnosis
© Thomas Beale 2011
constraint_bindings = < [“SNOMEDCT”] = < items = < [“ac0.1”] = <http://www.terminology.org?refsetid=20293847593 > > >
© Thomas Beale 2011
All Infectious Agents ref set
Definition
Result
© Thomas Beale 2011
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)
© Thomas Beale 2011
Ex: Adverse reaction
© Thomas Beale 2011
ADL view
© Thomas Beale 2011
© Thomas Beale 2011
© Thomas Beale 2011
Agent category binding... Archetype term SCT candidates
at0011|food| 406465008|food allergen|, 255620007|Foods| Note 149 top-level concepts containing ‘food’
at0012|animal| 39866004|animal| Note 241 top-level concepts containing ‘animal’; no ‘animal allergen’
at0013|medication| 119 top-level terms containing ‘medication’ (heavily pre-coordinated), but no |medication|...!
at0014|Other chemical or substance|
33565001|chemical agent| ??? 167 top-level concepts containing ‘chemical’
at0031|Non-active ingredient of medication|
Nothing with ‘ingredient’
at0032|imaging dye or media|
Nothing suitable
at0033|environmental| Some approximate matches...
© Thomas Beale 2011
Querying
© Thomas Beale 2011
Constraints – paths
© Thomas Beale 2011
BP archetype paths
© Thomas Beale 2011
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
© Thomas Beale 2011
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)
© Thomas Beale 2011
AQL – Archetype Query Lang.
Specification at http://www.openehr.org/wiki/display/spec/AQL-+Archetype+Query+Language
© Thomas Beale 2011
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)
© Thomas Beale 2011
Tools & Specifications status
© Thomas Beale 2011
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.)
© Thomas Beale 2011
About ADL 1.5
© Thomas Beale 2011
About ADL 1.5
© Thomas Beale 2011
About ADL 1.5
© Thomas Beale 2011
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)
© Thomas Beale 2011
Archetype Compiler
170 test archetypes
Regression testing
43 syntax errors 71 validity errors
© Thomas Beale 2011
Full object model - AOM
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
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).
© Thomas Beale 2011
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...
© Thomas Beale 2011
Resources
© Thomas Beale 2011
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
© Thomas Beale 2011
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
© Thomas Beale 2011
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