1 / 26

catalogue, synthesise

Share with clinical and other non-HL7 communities. Templates SIG. M & M TC. develop HL7 constraint formalisms. Templates, forms, data sets used in real, diverse health settings. Formal HL7 constraint specification for static models.

reece
Download Presentation

catalogue, synthesise

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Share with clinical and other non-HL7 communities Templates SIG M & M TC developHL7 constraintformalisms Templates, forms, data setsused in real, diverse health settings FormalHL7 constraintspecificationfor static models Formal representation of clinical “business object”REQUIREMENTS catalogue,synthesise develop and useimport and export tools Agreed requirements for constraints Agreed approach with Terminfo andClinical Statement

  2. Definition Description sets Publication status Node constraints Term and concept bindings Attributes, associations and context Data value constraints References to EHR instances Archetype & Template requirements

  3. globally unique identifier id of repository maintaining this archetype health informatics domain (e.g. EHR) underlying RM concept (scope) code or phrase natural language parent archetype predecessor, reason for revision, successor Definition

  4. providing party & organisation natural language scope: concept code, clinical speciality, types of patients, keywords intended use, potential erroneous uses reference to knowledge source (e.g. url) detailed explanation of purpose, notes url or references to explanatory materials Description sets (multiple)

  5. Tentative Draft Private Public Preferred Former Deprecated suggest adding Test date, authorising party & organisation review or validity date Publication status

  6. Explicit node Reference: to part or all of another archetype internal external constraints defining an inclusion or exclusion set Node constraints

  7. internally-unique id Reference Model class inclusion or exclusion constraints (e.g. for existence, multiplicity) logical related to environmental parameters related to other EHR node values to be instantiated within the same archetype related to EHR instance data or workflow or care pathway processes Explicit Node constraints

  8. Principal concept (mandatory: the “meaning”) Term binding Synonym Language translation for each term: code, rubric, coding system and version, language in which mapping made Binding to terms

  9. common label attribute/association name optionality multiplicity if ordered if unique data value constraints other dependencies and constraints Attributes and associations

  10. includes constraints on contextual information e.g. subject of information potentiality (present, absent, possible, probable, risk, goal, expectation, etc.) process (done, is in progress, is planned to be done, has not been done, should not be done, etc.) Attributes and associations

  11. inclusion and/or exclusion criteria null, null flavour values default value fixed value list of values data type specific constraints e.g. value range, units, term set, date ranges logical conditions and other constraint rules (and formalism used) data value constraints

  12. the archetype identifier the archetype node identifier the attribute or association name the occurrence in the instance hierarchy e.g. first, most-recent, any, n ordered by y, highest value, lowest value, one or more instances within a (definable) recent time interval References to EHR data (1)

  13. the intended relationship between this specified instance value and the data value being constrained e.g. the same value as a subset or substring of greater than, greater than or equal to, less than, less than or equal to earlier than, later than, etc. if ... then... must not be the same as References to EHR data (2)

  14. 13606-1 profile for archetypes

  15. 4.1 Template Architecture The Template Architecture that governs the normative HL7 V3.0 Templates must satisfy a series of requirements from the HL7 Standard V3 HDF Static Model: 4.1.1 Templates shall represent syntactically and semantically structured aggregation of data, including coded vocabulary or numerical data, as defined by domain experts or organizations. 4.1.3 The template architecture shall support structured aggregations of archetypes. 4.1.4 The template architecture shall support structured aggregation and composition of templates resulting in conformant Templates. 4.1.5 The template architecture shall support the re-use and import of archetypes into an authoring environment (including constraints expressed within those archetypes). 4.1.6 Templates may take the form of HL7-conformant balloted RMIM’s, local information models or LIMs expressed in HL7-conformant structural notations, and HL7-conformant clinical document specifications. 4.1.7 An HL7 Template Library shall provide the ability to associate each template instance with relevant referenced HL7 specifications that contained within its components. 4.1.8 The HL7 Template Library shall provide the ability to query for all HL7 specifications components suitable for reference or inclusion in an HL7 Template 4.1.9 Registered HL7 V3 Templates shall include collected metadata about the Templates, such as the components that have been constrained. 4.1.10 Templates must allow for the recursive representation and traversal of associations in support of constructs with zero or more instances. Templates can include by reference other templates in an object oriented fashion. HL7 Templates draft 28 Feb 05

  16. 4.2 Template Assertions The assertions of Templates as Static Models are governed by the HL7 V3 Standard HDF Static Model (3.2) requirements, including: 4.2.1 Static assertions. 4.2.2 Co-Occurrence Assertions Note that all co-occurrence assertions that are definitional shall result in the formation of new Static Model, in this case a particular kind of Template (termed an Archetype). 4.2.3 Containment assertions 4.2.4 Logic assertions 4.2.5 Mathematical assertions HL7 Templates draft 28 Feb 05

  17. 4.3 Normative Template Representation The normative representation of HL7 Standard V3 Templates is governed by the HL7 Standard V3 HDF Static model requirements. The required UML examples are provided in Section 5.0. The particular view by specific metalanguages (XML, OWL, and ADL) is detailed below in the Technical Specifications provided in the annexes 4.4 Template Declaration When used in HL7 V3 instance: 1. Template ID (infrastructure root) is used to assert conformance to a Template. 2. Template ID asserts Template binding to an instance. HL7 Templates draft 28 Feb 05

  18. 4.5 Templates Registration This section defines Templates registry and repository requirements. 4.5.1 Templates Repository ... 4.5.1.2. The repository shall be capable of supporting hierarchical relationships among two templates. For example, if a series of Echocardiography Templates were represented, each applying tighter and tighter constraints, this hierarchy can be captured and queried in the repository. ... HL7 Templates draft 28 Feb 05

  19. 4.5.2 Templates Metadata 4.5.2.1 Template ID 4.5.2.2 Name of the Template (required) 4.5.2.3 Description and scope of the Template (required) 4.5.2.4 Balloted rMIM fragment ID against which Template is developed (required) 4.5.2.5 Registering authority: organization, institution, committee, or individual (required) 4.5.2.6 Version number (required) 4.5.2.7 Publication state 4.5.2.8 Date of creation (required) 4.5.2.9 Date first in effect 4.5.2.10 Revision dates 4.5.3.11 Revision history 4.5.2.9 Date of expiration (optional) 4.5.2.10 Name of author, institutional affiliations(s) and contact information 4.5.2.11 Co-authors, institutional affiliations, and contact information (optional) 4.5.2.12 Technical contact 4.5.2.13 Administrative contact 4.5.3.14 Format (optional): e.g. rdfs: OWL, ebXML, and SR-XML 4.5.3.14 URI to documentation 4.5.3.15 URI of the package of templates HL7 Templates draft 28 Feb 05

  20. An archetype ontology to map individual archetypes to a generic knowledge framework - to enable their use alongside other knowledge resources Domain Base Concept Models, enabling sharable archetypes to be written Rules about binding co-ordinated terminology values to archetype nodes (the “TermInfo” problem) A rich library of archetypes conforming to the above, held within a public-domain repository Guidance on how to map EHR system data conforming to each archetype to EN13606-1 (and other RMs) new CEN work item proposal

  21. proposals Formal representation of clinical “business object”REQUIREMENTS

  22. 1. Accept (refine) CEN archetype requirements (prEN13606-2, Annex A) as the requirements for formally representing clinical business objects in the Templates SIG, for communication with M&M 2. Agree that this clinical content synthesis work can be harmonised with CEN and openEHR, provided that no assumption is made about which Reference Model is to be used 3. Review CEN archetype model as a candidate for a data repository and authoring tools 4. Collaborate with M&M on mapping this to its evolving HL7 Template formalisms proposals

  23. Undertake as a joint project with CEN and openEHR Templates SIG M & M TC developHL7 constraintformalisms catalogue,synthesise Templates, forms, data setsused in real, diverse health settings FormalHL7 constraintspecificationfor static models Formal representation of clinical “business object”REQUIREMENTS developguidelines & rules for “good” archetypes and templates develop and useimport and export tools Agreed requirements for constraints Agreed approach with Terminfo andClinical Statement

  24. mapped to and used within: openEHR Reference Model CEN 13606 HL7 R-MIMs Joint projectopenEHR, CEN, HL7 catalogue,synthesise Templates, forms, data setsused in real, diverse health settings Formal representation of clinical “business object”REQUIREMENTS Indexed repository developguidelines & rules for “good” archetypes and templates Data element inventory

More Related