A framework on templates : semantic interoperability in HL7

1. A framework on templates:semantic interoperability in HL7 A.Rossi Mori acting co-chair, Templates SIG Minneapolis, 2001-05-08

2. What is the clinical template activity? • Template Special Interest Group • templates@lists.hl7.org • Acting Co-chair: Angelo Rossi Mori • What is a template? • “Further specialization or constraint of an existing information model” • RIM (Reference Information Model) • MIM (Message Information Model) • R-MIM (Refined Message Information Model) • HMD (Hierarchical Message Definition) • Specialization of “clinical assessment”, “service event,” “service order”

3. Work Items • Collect use cases and requirements • Describe the different classes of templates • Define the formal notation for each kind of template • Define how creation works with the RIM and HDF,for each kind of template • Define an appropriate process for creating, approving, and maintaining each kind of templates • Define a mechanism for participating with professional societies or other domain experts in the creation of template content • Create a repository, if there is a perceived needfor storing and sharing templates

4. Where would templates be used? • Claims attachments • CDA and Medical Records Documents (transcription) • Level 2: Relating document names to document sections • Level 3: Data elements within sections of documents • Immunization queries and results • GCPR templates created for interoperability • Laboratory Observations • Panels and batteries • Microbiology culture results • Patient observations • Blood pressure, heart rate, respiratory rate • Heart exam, eye exam, chest auscultation • Data sets (professional organizations)

5. which approach ? • collect requirements • see if they are already satisfied by current v2.x/v3 artifacts • if yes, there is a real need for a better solution ? • if not, could this requirement be satisfied by using current artifacts ? do we really need more ? • in both cases: • it that one the best solution with the current artifacts ? • a new artifact or modifications of the methodology could be appropriate ?

6. possible advantages / motivations • more robust, principled, clean process(i.e. facilitate maintenance) • distributing the standardisation process among more subjects (i.e. facilitate the std process, comply with correct responsibilities of gov’t agencies and clinical societies) • more coherent with the overall methodology (i.e. simplify the methodology) • prepare specialised formalisms and toolscompatible with the methodology

7. why we need templates ? • human readabilityarbitrary structures and data (including narrative) must be understandale by human • machine processabilitystructures must be expected by the receiving applications in order to be processable, i.e. we need standard

8. different kinds of templates • inside an attribute valueencapsulation (code phrase) • one statementhow many/which attributes must be used ?e.g. variable style vs. value style • multiple statements • batteries: how to manage the common attributes ? • data sets and scores • use explicit relationships or single statement ? • internal structure of documentsCDA level 2 - allowed sections • extending and customising the RIM/R-MIMsextensibility (National, regulatory needs)

9. developing kinds of templates - 1 • inside an attribute value • VocabTC extends the format for the vocab tables attached to an attribute • terminology developers or VocabTC register post-coordinated coding systems • one statement • O-O (?) defines typical styles • clinical societies populate the examples

10. developing kinds of templates - 2 • multiple statements - battery-like • O-O (?) ballots the structure for a generic batterye.g. GEHR archetype with “protocol” • O-O (?) ballots the structure for major types of batteries, e.g. • set of obs with the same device • set of obs with the same sample • series of obs with same property at different times • the templates SIG develops a simple tool and formalism to input actual templates • clinical societies populate a register of actual templates, according to the above styles

11. developing kinds of templates - 3 • multiple statements - data sets • Templates SIG should explore the issues • internal structure of documents • SDTC ballots basic styles forhigh-level document categories • SDTC registers a small set of particular templatesfor the most common types of documents • external bodies register actual templates according to the basic styles • extending and customising the RIM/R-MIMs • Templates SIG and MnM ballot the rules • external bodies register extension to the RIMand their actual templates

12. issue 1 - generalise the HDF vision • templates are a way to define data structures • according to the HDF(HL7 development framework)all data structures must be derived from the RIM • RIM items can be restricted, renamed,aggregated at any depth • classes, relations and attributes in the RIMare considered here as Layer 0 - L0 • two further layers should be considered • R-MIM Layer - L1 • Semantic Layer - L2

13. layers of RIM refinement • classes, attributes and relations in the R-MIMs (LayerL1) are directly derivedfrom RIM itemsand the USAM manual e.g. “performed lab procedure”, “test order”,“is-consequence-of” • the detailed classes and relations inSemantic LayerL2are derived from RIM or structural items of layer L1e.g. “systolic blood pressure measurement”,“heart sounds”, “differential white cell count”(i.e. LOINC-like)

14. R-MIMs • G-CPR is developing “information graphs” • it is an UML diagram similar to R-MIM,with a moderate refinement of the RIM R-MIMs are made of refined RIM elements (classes, attributes, relations)

15. extensibility External bodies could produce their own R-MIMs using classes, attributes and relationships outside the RIM Extensibility is an opportunity for HL7that must be taken under control Usage of HDF and RIM – with customisations – could be a benefit for other organizations: • National affiliates • government agencies (US, non US) • professional associations • disease networks • healthcare organizations

16. responsibilities • stewardship (the body responsible for creation and maintenance): HL7, Nat’l affiliate, gov’t agency, professional association, disease network, healthcare organization, company • enforcing power balloted, regulated, registered, legacy

17. creating R-MIMsand extensibility L0 non-RIM classes, attributes and relations RIM stewardship enforcing L1 refined by > < refined by refined by > R-MIM stewardship enforcing enforcing balloted, regulated, registered, legacy stewardship HL7, Nat’l affiliate, gov’t agency, professional body, disease network, organization, company

18. issue 2 - semantic structures semantic structures deal with content • (minimum) data sets, clinical DB structures • combination of clinical statements • scores, evaluation scales (LOINC nursing assessments) • batteries (LOINC panels) • combination of fragments into one clinical statement

19. semantic structures in HL7 • GEHR defines various kinds of archetypes • one of them is the generic content archetype,e.g. “blood pressure”, “diabetic foot” • HL7 “semantic structures” could be similar to a detailed CMET • each generic semantic structure should be compatible with a R-MIM • a generic semantic structuremay be refined by many particular structures

20. tools and organizational issues which role for HL7 in populating semantic structures ? • making registration rules and style guidelines(standards for upload/download, localrepositories ?) • promoting the approach within • National agencies (US and abroad) • Nat’l and int’t disease networks • Nat’l and int’t professional bodies • providing tools and organizational support • managing the actual registry vs. using USHIK ? • providing guidelines, tools and support to improve quality / coherence / systematization

21. hierarchical descriptions models XML schemata Production of the Hierarchical Description of a structural view L1 structural layer XML schema for message/doc XML schema for component R-MIM HD-structural

22. hierarchical descriptions models XML schemata class_cd L1 A XML schema for component R-MIM HD-structural has slot for LOINC-like C L2 specific B XML schema for fragment HD-semantic generic refined by >

23. hierarchical descriptions XML schemata models RIM non-RIM classes and relations L0 L1 XML schema for message/doc refined by > < refined by refined by > XML schema for component R-MIM HD-structural has slot for L2 XML schema for fragment HD-semantic refined by >

24. a pathway to semantic structures • working registry to store Semantic structures defined by various authoritative bodies (e.g. Nat’l professional bodies ?) under HL7 • provisionally usable just after registration • a step towards more interoperability • raises requests to fix the RIM • but will contain conflicting descriptions • the registry is the support for a subsequent systematization process • HL7 should produce measures to support comparisons and canonization of similar descriptions

25. why a register ? legacy systems will use transformations from their legacy format to the standard component and vice versa • for communication: • using registered Semantic structures reduces the need of transformations by the receiving systems • for quality and coherence: • as a check list of essential features to be specified about a statement • to reduce unnecessary variability andto increase clarity in motivated differences

26. issue 3 - organisers vs. bundles there are 2 kinds of clinical data structures : • an organiser is filled in by users with independent statementssharing some common featuree.g. family history • a bundle is made ofinter-dependent fragmentse.g. drug prescription

27. organising structures • an organising structure (see CDA) is defined by its name only • it provokes expectations in the human users • it may be filled in according to a ”template” • this template contains at least one organiser or one textual data element • it is represented by an Organising structure • it propagates a default technical context to its content (author, date, language, ...) • it cannot propagate mood or status

28. semantic structures • a bundle (~ CENcluster) is defined by its content • it contains only bundles and/or data atoms with controlled content(i.e. coded or quantitative data elements) • clinically, it can be made of • a set of statements sharing essential features (e.g. Apgar) • fragments of a statement (e.g. a medication) • a bundle provides a scope to its content • a strong context (including mood, status) can be propagated according to rules • a bundle is represented by a semantic structure

29. data atom • a data atom corresponds to one RIM attribute • it is considered as elementary by the RIM, i.e. by most applications • a data atom appears in actual messagesas a name-value pair • code phrases are allowed, with constraints decided by vocab TC and negotiated with the RIM

30. meanings in organisers vs. bundles within any data structure, an item influences the meaning of the other items, but: • in a bundle, all the fragments are essentialto build the meaning of the whole • within an organiser, the statements influence the clinical interpretationof the other statements

31. organiser vs. bundle (UML) organiser bundle quantitative data atom name (range) interval with units textual data atom name text structured data atom name range coded data atom name (range) value domain

32. Organising structure • do not mix organisers and bundles • same HDF process, but separate streams • an Organising structure is made of organiserse.g. a document is made of sections • use cases: dictations and transcriptions • layers of refinement of organisers • L1: “family history”, “plan” • L2: “anesthesia” in a surgical report

33. issue 4 - kernel and contexts we need a systematization and clear names for the different kinds of contexts • which attribute goes in which context ? • see also GEHR archetypes • base concept (e.g. pure disease, pure procedure) • operational detail (e.g. device, challenge, site) • status concepts (e.g. severity, certainty, negation, state, mood, risk) • instantiation context (when, where, …) • attribution context (e.g. author, language, confidentiality) • envelope (e.g. sender, receiver)

34. different kinds of information • kernel – generic concepts • status – generic life cycle, … • different for diagnoses and procedures • instantiation – related to the event • when, where, … • attribution – related to documenting • author, date of recording, confidentiality • envelope – related to transaction • sender, receiver, dates of transaction

35. canonisation of semantic fragments terminological details base concept 1 0..* status concept kernel a theoretical model from a clinical point of view, NOT the way to represent multiple statements in messages or documents 1..* 1 fully described expression instantiation context (actual event) 1 1 situated expression attribution context (description) 1 1 clinical statement envelope 1..* 1 payload transaction unit

36. how to split a stm into fragments fragments vs. one attrib value 2 fragments vs. HL7 artifacts 3 1 RIM perspective semantic fragment represented as HL7 artifact ?? clinical statement from an application point of view from a clinical point of view class name attribute name attribute value

37. semantic features vs. processing • clinical point of view • pure semantic features • produce an enumerated list of the reasonably isolable kinds of fragment • intrinsic/absolute feature of a coding system, independent of use cases and potential utilisation • application point of view • units that are worthwhile processing • there is a frequent/relevant need for usage of a kind of fragment (=attribute) in most applications, according to use cases

38. set of statements {“blood pressure”, a position, a device type. a mood} clinical statement “systolic” 1 1 differentiating part of statement set of common fragments - “systolic” - “diastolic” {a position, a device typea mood} 1 * set of statements 4 name batteries / data sets “blood pressure” global fragments they apply to the set as a whole, a global interpretation

39. different usage of fragments task – terminological phrase • admission – operation for lower third rectum cancer • scheduling – low anterior resection of rectumorabdominoperineal amputation of rectum (Miles operation) • reporting – low anterior resection of rectumwith double stapling technique • discharge – other anterior resection of rectum, ICD-9-CM 48.63 • reimboursement – operation for rectumcancer, DRG 147 • cost analysis – anterior resection of the rectumwith double stapling technique • quality assurance (low anterior resection of rectumwithout temporary colostomyandoperation for lower third rectumcancer)

40. terminology as proxy • how to control diversity ? • globalisation: eliminate diversity • terminology replaces actual information • in family history – just name of the relative • what is a surgical operation ? • performing the activity – many hours • reporting – one doument • type of procedure – one expression • class for statistics or reimboursement – one classification code

41. summary of issues • generalize the HDF process - global vision • R-MIM to guide creation of templates • extensibility (Z-segments) • support to professional bodies, agencies, Nat’l affiliates ? • semantic structures on content • (minimum) data sets, clinical DB structures • combination of clinical statements • scores, evaluation scales (LOINC nursing assessments) • batteries (LOINC panels) • combination of fragments into one clinical statement • organising structures and CDA - a separate stream • various kinds of “context”