Clinical templates, registries and terminologies

1. Clinical templates, registries and terminologies Angelo Rossi Mori National Research Council, Rome - Italy HL7 / Clinical Templates SIG & CEN / TC251 / WG II

2. Contents • what is a clinical template ? batteries, data sets, reusable fragments of messages • 3 pillars for semantic interoperability repositories, templates, value domains • “HL7 light”: a complementary approach • decentralisation of a registration process • involvement of professionals and agencies • a common strategy for HL7 and CEN ?

3. what is a template ? too many legitimate perspectives and options

4. typology of templates 1/2 • USAM tables • e.g. role-link-role • ENCAPSULATION (terminology vs RIM) • e.g. to describe style in messages • BATTERY = set of “Acts” • sets of observations (i.e. battery) (precise description for orders and payments) • goals, outcomes • sets of procedures (e.g. clinical guidelines) • data sets (e.g. from regulatory agencies)

5. typology of templates 2/2 • CDA-L2 = set of sections • Clinical Document Architecture - level 2 • expected shape of a document • DICOM SR = set of sections, acts, materials, devices, … • MESSAGES = profiles, new messages ? • internal needs of an organization • needs of a specialty (e.g. cancer network) • needs of agencies (e.g. Public Health reporting) • needs of a region / country (e.g. xDT Germany)

6. sharing templates need for registries ?

7. emerging needs in HL7 ? • refine standard messages and documents with “local” detailed constraints or refinements, e.g. to satisfy the needs of • sub-communities (diabetes, cancer, ESRD) • ad-hoc information flows (e.g. CDC, HCFA) • regional or national information flows • management of pathology networks • registries, clinical trials, sharing records • secondary uses • reporting to authorities, statistics

8. clinical templates: a real need ? • is there a need to reduce combinatorial alternatives and impose a common “style” ? • what is better achieved by • a-posteriori transformations ? • is there a need for control over the processthrough registration and support databases ? • (i.e. decentralise but avoid the chaos) • if communication is local, why HL7 should • introduce international rules or registries ?

9. my vision: need for registries • if we want to share clinical templates • across organizations, • components of templates must be registered. • all names and labels used in templates • should be stored in a registry • should be mapped to the RIM classes • should have a well defined “value set” • (how can we decentralize the register ?)

10. 3 pillars for real interoperability • The optimal strategy is based on 3 pillars: • 1. data dictionaries and metadata registries, • including appropriate “LOINC codes” • 2. clinical templates • 3. tables with enumerated value domains • they are complementary • all 3 pillars are needed to assure a real semantic interoperability

11. 1. Metadata registries 1/2 • A registry of data elements, between • one thousand robust data elements i.e. the attributes in the RIM • millions of user-created XML labels • Specializations of the RIM: • each data element should be explicitly • registered as a child/refinement of a RIM class, • under control of the respective HL7-TC

12. 1. Metadata registries 2/2 • Quick solution: • Collection of data sets and lists of XML tags • with either answer-list or ranges of values • (e.g. see “names for observations” in LOINC; • see also xDT/Germany, ASTM E1384) • Optimal solution: • Integrated repository (e.g. ISO 11179) • with uniform and comparative representation • of data elements from all the sources

13. 2. Clinical templates • to aggregate data elements from the repository • (including the RIM) into meaningful fragments • i.e. building blocks, from predefined data elements, • to produce more detailed messages, between • hundreds of balloted standard messages • millions of user-created DTD/schemas • Templates (and the related data elements) • need a process for (local) registration • under the control of HL7 TCs • a neutral language to represent templates ?

14. 3. Value domains • Thousands of explicit tables • with enumerated value domains • or numeric ranges admitted values for each data element in the context of a clinical template • "terminologies in context" • coordinated by HL7 vocabulary TC (see the “context groups” in DICOM-SR)

15. HL7 light ?Open HL7 ? a registration process in addition to normal ballots

16. “HL7 light” ? • fix by ballot the common framework (ISO ?), i.e. • basic rules and development processes • RIM and common templates • rules for registration • my vision: two different speeds + legacy • ballot the general standards (as usual) • control decentralisation of detail • a registration process driven by HL7 users • 3. legacy systems (Z-segment and adaptations)

17. 1. Unified development process • Uniform process, according toHDF (HL7, CEN) • the development framework allows to define • the standard for a type of messages/documents • uniform measures for a vendor (level 7 !) to create, transport, parse, and visualizethe instances of messages and documents • general methods • same software • common skills • basic manuals and training

18. 2. Sharing pre-defined building blocks • 1. usual ballots in HL7 (RIM, messages, CMETs) • the RIM (and the CEN-RIM) • general-purpose messages • basic clinical templates and CMETs • 2. HL7 Committees registerdata elements and “shared” clinical templates (LOINC + ?) • data elements registered wrt the RIM • related value domains • useful clinical templates

19. ( Not just a list … ) • harmonise data elements / XML tags across different systems/organisations • facilitate users’ feedback into the process by uniform collection of legacy usages • facilitate mappingfrom legacy data elements of end-users to registered data elements [similarly to RELMA for LOINC]

20. 3. Decentralise detailed content • HL7 members register "local" clinical templates • define the content of their typical messages and documents (i.e. all and only the detailed data elements needed and adequate for a task) • National affiliates (and CEN/TC251 ?) • US government agencies • disease networks (e.g. cancer registries, ESRD) • member organisations • professional bodies

21. the new SIG a forum for discussion and harmonization

22. A new SIG on Clinical Templates • to coordinate discussion across TC/SIGs • and with external bodies • CEN, ASTM, DICOM, GEHR.org, ... • XML schemas, bizTalk, ebXML, … • compare perspectives on: • real needs • use cases, purposes, target groups • potential solutions • no production activities within the template SIG

23. role of HL7 groups vs templates SIG • The SIG is made of members from other groups • each TC/SIG should produce its vision • real user needs, use cases, kind of templates, • examples and the future “production” activities. • Role of the new SIG: • clarify the perspective of each group • discover similarities and differences • comparative review of TCs’ visions • strategic proposals to the HL7 Board

24. who has a “real need” for templates ? • e.g. professional societies • (see cardiologists in DICOM …) • quality of reports (check list) • (complete, understandable, processable) • clinical databases • uniform data collection • (clinical trials, clinical registries) • are they aware ? • what is the limit of “promotion” ?

25. perceived by professional groups ? • groups that are currently working • on clinical data sets include: • DEEDS (CDC) • Am. Dental Association • Am. Ophtalmology Association • Am. Coll. Obstetrics and Gynecology • Am. College of Pediatrics • (consistent structure across specialties • would be in the best interest of medicine)

26. filling in the gap • “clinical templates” as a keyword: • everything filling in the gap between • (slow) ballot-based process • Z-segments and local adaptations • including registry of data elements (LOINC+) • and related vocabularies • “now that XML is available • we don’t need HL7 anymore, right ?”

27. Issues • what is a clinical template ? batteries, reusable fragments of messages, data sets, messages, internal structure of documents • 3 pillars for semantic interoperability repositories, templates, value domains • HL7 light ? • decentralisation of a registration process • neutral representation of templates • involvement of professionals and agencies • concrete needs, use cases, solutions • volunteers to prepare the January meeting