Your SlideShare is downloading. ×
The openEHR archetype formalism
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

The openEHR archetype formalism

3,856
views

Published on

Presentation on Archetype Definition Language and the openEHR approach to clinical modelling - given to the CIMI forum on October 09, 2011.

Presentation on Archetype Definition Language and the openEHR approach to clinical modelling - given to the CIMI forum on October 09, 2011.

Published in: Technology, Business

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,856
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
177
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The openEHRarchetype formalismCIMI forum 09 Oct 2011Thomas Beale, Sam Heard MD, Hugh Leslie MD © Thomas Beale 2011
  • 2. Overview © Thomas Beale 2011
  • 3. 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
  • 4. openEHR Goals © Thomas Beale 2011
  • 5. Ultimate ICT goals• To compute with health information • Cross-enterprise • Cross-system • Cross-product / vendor • Patient-centric • Over time & technology changes © Thomas Beale 2011
  • 6. 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
  • 7. Ultimate ICT goals• While dealing with relentless change in • Medicine, esp. drugs, interactions, procedures... • Information • Care processes • Patient needs • Legislation © Thomas Beale 2011
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. openEHR archetype background © Thomas Beale 2011
  • 13. Requirements based • Good European Health Record (GEHR) Project 1992 - 1995 • ISO 18308 Technical Report BelgiumUnited Kingdom Health Data Management Partners St Bartholomew’s Hospital ERIM Medical College Federation des Association MedecinsThe Royal Hospitals NHS Trust Generalistes de Bruxelles City & East London FHSA Insitut D’Hygiene et d’Epidemiologie The Royal Marsden HospitalUniversity of HullSmithKline Beecham Germany Zentralinstitut fur die Kassenarztliche VersorgungFranceCroix Rouge FrancaiseC2V LuxembourgKalamazoo S.A. Association desFrance Telecom Medecins et Microdata SARL Medecins Dentistes Centre de Recherche Public Henri Tudor Portugal Greece Instituto Clinica Spain University of Athens Geral Zona Norte Clinica Puerta de Hierro © Thomas Beale 2011
  • 14. openEHR and ISO 136061991 GEHR record1998 architecture CEN ENV13606 folders2000 openEHR draft2002 ADL 1.22004 openEHR 0.95 CEN 13606 ADL 1.4 drafting20052006 openEHR 1.0 CEN EN136062007 openEHR 1.0.12008 openEHR 1.0.2 ISO 136062011- ADL/AOM 1.5 © Thomas Beale 2011
  • 15. About the approachFundamental 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
  • 16. About the approach What key requirements did we try to satisfy?AD-16  Will work with ANY RM & data typesST-01,02  Definition of standard content elements (archetypes)AD-17  Identified and encapsulated (i.e. not a giant terminology)ST-04  Definition of use-case specific data-sets (templates)  UI forms, messages, reports, documentsCO-*  Flexibility of content – optionality; RM typing; rangesST-03,5-7  Reusability: specialisation & composition of models © Thomas Beale 2011
  • 17. About the approach What key requirements did we try to satisfy?AD-14  Creation of new data via use of templatesAD-15  Validation of incoming dataAD-06  Querying of data based on the content elements & RMTS-*  Integration with terminologyTS-07  Multi-lingualST-09  Works with stable RM – future proof  Supports continual incremental deployment © Thomas Beale 2011
  • 18. About the approach First we devised an architectural framework based on these requirements © Thomas Beale 2011
  • 19. Levels of Semantic Organisation Discharge summary UI form Concrete: GUI, messages, documents 1:N Discharge summary content Business-event specific Terminology model data sets - Templates Interface 1:N HbA1C, phys. exam, meds list, Theme-based models vital signs of content - Archetypes Querying etc SM virtual EHR 1:N terminology demographic EHR archetypeObservation, service service service service { { EHR ExtractQuantity, } EHR Demographic Integration Template OM Data Representation and domain Composition openEHR Archetype Profile AMcoded text etcRM patterns { Security Common Archetype OM { core Data Structures Data Types Support (identifiers, terminology acce ss) sharing - Reference Model © Thomas Beale 2011
  • 20. openEHR Semantic architecture Screen Forms 1:N Messages Use-case specific 1:N data-set definitions Defined connection Reports Templates to terminology TerminologyData conversion 1:N interface rules All possible Terminologies item Archetypes definitions Querying ICPC Snomed CT ICDx for health 1:N Portable, model- Reference Model based queries Defines all data openEHR scope © Thomas Beale 2011
  • 21. Why current Health Information Systems don’t solve the problem They have a form-builder Possibly a library of ‘elements’ And only SQL, to query against the proprietary database virtual EHR SM terminology demographic EHR archetype service service service service { { EHR Extract domain EHR Demographic Integration Composition Template OM openEHR Archetype Profile } AM And a proprietary databaseRM patterns { Security Common Archetype OM { Data Structures core Data Types Support (identifiers, terminology acce ss) © Thomas Beale 2011
  • 22. In the real world... java Int’l Nat’l / local Nat’l / local archetypes archetypes templates Template- C# based artefacts etcRM + DTs ADL, AOM, TOM Collaborative knowledge repository re f s e ts terminology canonical Querying openEHR AQL data All data = same information model © Thomas Beale 2011
  • 23. 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 Evaluate developers inclusions, flatten inheritance  An OPT is just a giant archetype © Thomas Beale 2011
  • 24. The key to (re-)using data  Is paths from archetypes & terminology  No dependency on physical DB schema re f s e ts terminology AQL data All data = same information model © Thomas Beale 2011
  • 25. The formalism © Thomas Beale 2011
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. About the approach What key requirements did we try to satisfy?ST-01,02  Definition of standard content elements (archetypes)ST-04  Definition of use-case specific data-sets (templates)  UI forms, messages, reports, documentsCO-* WE NEED A  Flexibility of content – optionality; RM typing; rangesST-03,5-7  Reusability: specialisation & composition of models PURPOSE-BUILTREQ??  Creation of new data via use of templatesREQ??  FORMALISM & Validation of incoming dataAD-06  TOOL ECO-SYSTEM Querying of data based on the content elements & RMTS-*  Integration with terminologyTS-07  Multi-lingualST-09  Works with stable RM – future proof © Thomas Beale 2011
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. Archetype basics We first developed ADL (10 jul 2003 1st ed.) Archetype Object Model (10 Nov 2004) XML expression ~2005 - lossless © Thomas Beale 2011
  • 34. Archetype basics REQ-AD-16 (RM-indep’t) 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 © Thomas Beale 2011
  • 35. Archetype basics Archetypes and templates are separately identified, ‘small’ models – i.e. Not like terminology REQ-AD-17 (encapsulated) © Thomas Beale 2011
  • 36. © Thomas Beale 2011
  • 37. 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 REQ-ST-08 EXISTS IN XML (serialisable)  Don’t panic  © Thomas Beale 2011
  • 38. BasicStructureof anarchetype © Thomas Beale 2011
  • 39. REQ-AD-17 Identifier Constraint operator ∈(Encapsulated) Value constraint RM class REQ-CO-07 REQ-ST-01 (intra-elemRM attribute (data elements) constraints) SemanticREQ-ST-02 marking (Struct. Rel’ns) Language Local term definition support REQ-TS-07 (language) © Thomas Beale 2011
  • 40. A real one... © Thomas Beale 2011
  • 41. 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
  • 42. Languages REQ-TS-07 (languages) © Thomas Beale 2011
  • 43. Constraint basics REQ-CO-2 (cardinality) Can constrain: •types •values •cardinality •existence •occurrences © Thomas Beale 2011
  • 44. Constraints - occurrences  Occurrences: how many times in the data can this node occur? REQ-CO-02 (occurrences) © Thomas Beale 2011
  • 45. Constraints – alternatives REQ-CO-09 (choice) Single- valued attribute DV_TEXT or DV_URI ok © Thomas Beale 2011
  • 46. Constraints – match most specificfirst Organisation instance matches ORGANISATION constraint; Person instance matches PERSON constraint; any other Party instance matches PARTY constraint REQ-??-?? (preferred matching) © Thomas Beale 2011
  • 47. Constraints – group operator REQ-??-?? (grouping) © Thomas Beale 2011
  • 48. Constraints – node-levelannotations REQ-??-?? (annotations) © Thomas Beale 2011
  • 49. Constraints – slots ADL1.4 REQ-ST-03 (reusable models) REQ-ST-05 (composability) ADL1.5 © Thomas Beale 2011
  • 50. Constraints – external ref REQ-ST-03 (reusable This enables direct re-use models) of an archetype by another archetype REQ-ST-05 (composability) © Thomas Beale 2011
  • 51. Cross-attribute constraints ‘rules’ section (ADL 1.5; ADL1.4 – ‘invariant’ section) Xpath-based FOPL REQ-CO-08 (reusable Standard operators models) Built-in Variables  $current_date: ISO8601_DATE  $current_time: ISO8601_TIME  $current_date_time: ISO8601_DATE_TIME  $current_year: Integer  $current_month: Integer © Thomas Beale 2011
  • 52. 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
  • 53. 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
  • 54. 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
  • 55. REQ-ST-07(specialisation) © Thomas Beale 2011
  • 56. Specialisation child – Source form flatteningParent archetype Specialisation child – Flat form © Thomas Beale 2011
  • 57. Templates © Thomas Beale 2011
  • 58. Template formalism Today, the community uses a simple XML formalism developed (organically) by Ocean (http://www.openehr.org/releases/1.0.2/its/X ML-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
  • 59. Template formalism REQ-ST-04 (use case dep’t models) 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 © Thomas Beale 2011
  • 60. Templates – remove unneeded elements Archetype used in a template Templated form © Thomas Beale 2011
  • 61. Templates – top-level template Slot filling Slot-closing Make elements mandatory © Thomas Beale 2011
  • 62. Templates – operational template © Thomas Beale 2011
  • 63. Templates – OPT XML (AOM 1.5) © Thomas Beale 2011
  • 64. Terminology connection © Thomas Beale 2011
  • 65. 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
  • 66. Term definitions & bindings REQ-TS-08 (multi-purpose) Bind individual terms to Snomed codes REQ-TS-03 (sem. binding) © Thomas Beale 2011
  • 67. 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
  • 68. can ‘systolic’ be post-coordinated? © Thomas Beale 2011
  • 69. |Bp| v |bp finding| © Thomas Beale 2011
  • 70. 271649006 |systolic blood pressure| OR 72313002|systolic arterial pressure| OR 399304008|Systolic blood pressure on admission| OR.... 314449000| Average 24hour systolic blood pressure|Archetype paths © Thomas Beale 2011
  • 71. 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
  • 72. 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
  • 73. Problem/diagnosis © Thomas Beale 2011
  • 74. constraint_bindings = < [“SNOMEDCT”] = < items = < [“ac0.1”] = <http://www.terminology.org?refsetid=20293847593 > > © Thomas Beale 2011>
  • 75. All Infectious Agents ref set DefinitionResult  © Thomas Beale 2011
  • 76. 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
  • 77. Ex: Adverse reaction © Thomas Beale 2011
  • 78. ADL view © Thomas Beale 2011
  • 79. © Thomas Beale 2011
  • 80. © Thomas Beale 2011
  • 81. Agent category binding...Archetype term SCT candidatesat0011|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 33565001|chemical agent| ???substance| 167 top-level concepts containing ‘chemical’at0031|Non-active Nothing with ‘ingredient’ingredient of medication|at0032|imaging dye or Nothing suitablemedia|at0033|environmental| Some approximate matches... © Thomas Beale 2011
  • 82. Querying © Thomas Beale 2011
  • 83. Constraints – paths © Thomas Beale 2011
  • 84. BP archetype paths© Thomas Beale 2011
  • 85. 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
  • 86. 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
  • 87. AQL – Archetype Query Lang. Specification at http://www.openehr.org/wiki/display/spec/AQL- +Archetype+Query+Language © Thomas Beale 2011
  • 88. Operational use  Archetypes and Templates deployed in hospitals (Aus, Europe, Brazil...), cancer registry (Aus), gov. Programmes (Aus, NZ, SE, BR...) REQ-AD-14(data creation) Some systems create initial data from template  All systems validate data to be committed against REQ-AD-15(data valid’n) templates & archetypes  AQL deployed and heavily used for populating screens, reports etc © Thomas Beale 2011
  • 89. Tools & Specificationsstatus © Thomas Beale 2011
  • 90. The archetype specifications Today’s stack Target stack .oet-based downstream artefacts OPT-based downstream artefacts early TDO, TDS TDO, TDS dev’t late ADL 1.5 OPT dev’t Ocean .oet XML template format ADL 1.5 templatesArchetype Query Language (AQL) DSTU Archetype Object Archetype Def. Model 1.5 (AOM) Lang. (ADL 1.5) Archetype Object Archetype Def. current ISO 13606-2 Model 1.4 (AOM) Lang. (ADL 1.4) stable release Primitive types, Ids 1.0.2 de facto official REQ-??-?? (spec. Avail.) © Thomas Beale 2011
  • 91. About ADL 1.5 © Thomas Beale 2011
  • 92. About ADL 1.5 © Thomas Beale 2011
  • 93. About ADL 1.5 © Thomas Beale 2011
  • 94. openEHR Archetype tools - today commercial Artefact repository CKM REQ-AD-03 (computable) Integration Various tools mapping REQ-AD-04 free Generate artefacts Various OPT generators (gen. artfacts) Edit templates Template Designer (Ocean, C#.NET) open sourceEdit Linköping U. LinkEHRed Archetype Editorarchetypes (Ocean, VB.NET) Archetype Editor (Linköping, Java) LinkEHR Archetype Engine ADL Workbench (Valencia U, Java)Compile ADL (openEHR, Eiffel)1.4 and 1.5archetypes ADL reference compiler ADL parser (openEHR, Eiffel) (openEHR, Java) openEHR BMM model spec Reference Model openEHR (data view) © Thomas Beale 2011 specifications RM XSDs
  • 95. Archetype Compiler 43 syntax errors 71 validity errors 170 test archetypes Regression testing © Thomas Beale 2011
  • 96. Full object model - AOM © Thomas Beale 2011
  • 97. tools – future possibilitiesArtefactrepository CKMIntegrationmapping open source EclipseGenerate archetypeartefacts Various OPT generators environmentEdittemplates ADL 1.5 Java ADL 1.5 ref. Editor (openEHR, Eiffel) Editor x x xEdit (openEHR, java)archetypes ADL WorkbenchCompile ADL (openEHR, Eiffel) Bosphorous Eclipse1.4 and 1.5 (ZeroMQ / PB)archetypes ADL ref. compiler ADL ref.compiler EMF/Ecore (openEHR, Eiffel) (openEHR, java) openEHR BMM model spec Reference Model openEHR (data view) © Thomas Beale 2011 specifications RM XSDs
  • 98. 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
  • 99. 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
  • 100. Requirements score Requirements not directly addressed:  REQ-AD-13 Standards Be considered to work toward the clinical modeling languages 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
  • 101. Resources © Thomas Beale 2011
  • 102. 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/archit ecture/am/adl1.5.pdf AOM 1.5 - http://www.openehr.org/svn/specification/TRUNK/publishing/archit ecture/am/aom1.5.pdf Templates 1.5 (draft) - http://www.openehr.org/svn/specification/TRUNK/publishing/archit ecture/am/tom.pdf © Thomas Beale 2011
  • 103. Resources Archetype Identification (draft) - http://www.openehr.org/svn/specification/TRUNK/publishing/archit ecture/am/knowledge_id_system.pdf Archetype governance (early draft) - http://www.openehr.org/svn/specification/TRUNK/publishing/archit ecture/am/dist_dev_model.pdf Archetype Editor - http://www.openehr.org/svn/knowledge_tools_dotnet/TRUNK/Arch etypeEditor/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
  • 104. Resources ADL Workbench - http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_work bench/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 © Thomas Beale 2011