The openEHR archetype formalism


Published on

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

The openEHR archetype formalism

  1. 1. The openEHRarchetype formalismCIMI forum 09 Oct 2011Thomas Beale, Sam Heard MD, Hugh Leslie MD © Thomas Beale 2011
  2. 2. Overview © Thomas Beale 2011
  3. 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. 4. openEHR Goals © Thomas Beale 2011
  5. 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. 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. 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. 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. 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. 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. 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. 12. openEHR archetype background © Thomas Beale 2011
  13. 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. 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. 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. 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. 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. 18. About the approach First we devised an architectural framework based on these requirements © Thomas Beale 2011
  19. 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. 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. 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. 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. 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. 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. 25. The formalism © Thomas Beale 2011
  26. 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. 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. 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 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. 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. 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. 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. 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. 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. 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. 35. Archetype basics Archetypes and templates are separately identified, ‘small’ models – i.e. Not like terminology REQ-AD-17 (encapsulated) © Thomas Beale 2011
  36. 36. © Thomas Beale 2011
  37. 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. 38. BasicStructureof anarchetype © Thomas Beale 2011
  39. 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. 40. A real one... © Thomas Beale 2011
  41. 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. 42. Languages REQ-TS-07 (languages) © Thomas Beale 2011
  43. 43. Constraint basics REQ-CO-2 (cardinality) Can constrain: •types •values •cardinality •existence •occurrences © Thomas Beale 2011
  44. 44. Constraints - occurrences  Occurrences: how many times in the data can this node occur? REQ-CO-02 (occurrences) © Thomas Beale 2011
  45. 45. Constraints – alternatives REQ-CO-09 (choice) Single- valued attribute DV_TEXT or DV_URI ok © Thomas Beale 2011
  46. 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. 47. Constraints – group operator REQ-??-?? (grouping) © Thomas Beale 2011
  48. 48. Constraints – node-levelannotations REQ-??-?? (annotations) © Thomas Beale 2011
  49. 49. Constraints – slots ADL1.4 REQ-ST-03 (reusable models) REQ-ST-05 (composability) ADL1.5 © Thomas Beale 2011
  50. 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. 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. 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. 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. 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. 55. REQ-ST-07(specialisation) © Thomas Beale 2011
  56. 56. Specialisation child – Source form flatteningParent archetype Specialisation child – Flat form © Thomas Beale 2011
  57. 57. Templates © Thomas Beale 2011
  58. 58. Template formalism Today, the community uses a simple XML formalism developed (organically) by Ocean ( 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. 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. 60. Templates – remove unneeded elements Archetype used in a template Templated form © Thomas Beale 2011
  61. 61. Templates – top-level template Slot filling Slot-closing Make elements mandatory © Thomas Beale 2011
  62. 62. Templates – operational template © Thomas Beale 2011
  63. 63. Templates – OPT XML (AOM 1.5) © Thomas Beale 2011
  64. 64. Terminology connection © Thomas Beale 2011
  65. 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. 66. Term definitions & bindings REQ-TS-08 (multi-purpose) Bind individual terms to Snomed codes REQ-TS-03 (sem. binding) © Thomas Beale 2011
  67. 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. 68. can ‘systolic’ be post-coordinated? © Thomas Beale 2011
  69. 69. |Bp| v |bp finding| © Thomas Beale 2011
  70. 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. 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. 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. 73. Problem/diagnosis © Thomas Beale 2011
  74. 74. constraint_bindings = < [“SNOMEDCT”] = < items = < [“ac0.1”] = < > > © Thomas Beale 2011>
  75. 75. All Infectious Agents ref set DefinitionResult  © Thomas Beale 2011
  76. 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. 77. Ex: Adverse reaction © Thomas Beale 2011
  78. 78. ADL view © Thomas Beale 2011
  79. 79. © Thomas Beale 2011
  80. 80. © Thomas Beale 2011
  81. 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. 82. Querying © Thomas Beale 2011
  83. 83. Constraints – paths © Thomas Beale 2011
  84. 84. BP archetype paths© Thomas Beale 2011
  85. 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. 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. 87. AQL – Archetype Query Lang. Specification at +Archetype+Query+Language © Thomas Beale 2011
  88. 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. 89. Tools & Specificationsstatus © Thomas Beale 2011
  90. 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. 91. About ADL 1.5 © Thomas Beale 2011
  92. 92. About ADL 1.5 © Thomas Beale 2011
  93. 93. About ADL 1.5 © Thomas Beale 2011
  94. 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. 95. Archetype Compiler 43 syntax errors 71 validity errors 170 test archetypes Regression testing © Thomas Beale 2011
  96. 96. Full object model - AOM © Thomas Beale 2011
  97. 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. 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. 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. 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. 101. Resources © Thomas Beale 2011
  102. 102. Resources ADL 1.4 - AOM 1.4 - ADL 1.5 - ecture/am/adl1.5.pdf AOM 1.5 - ecture/am/aom1.5.pdf Templates 1.5 (draft) - ecture/am/tom.pdf © Thomas Beale 2011
  103. 103. Resources Archetype Identification (draft) - ecture/am/knowledge_id_system.pdf Archetype governance (early draft) - ecture/am/dist_dev_model.pdf Archetype Editor - etypeEditor/Help/index.html openEHR XSDs including .oet template format - © Thomas Beale 2011
  104. 104. Resources ADL Workbench - bench/doc/web/index.html BMM Schemas - Test archetype repository - openEHR mailing lists - © Thomas Beale 2011