HL7 Tooling—A Progress Report

1. HL7 Tooling—A Progress Report John Quinn HL7 CTO HL7 Board Retreat; Asheville, NC July 31, 2008

2. Two Goal Areas • Two Separate but Related set of Requirements: • Ballot/Publishing: RIM artifact based standards and Implementation Guides first, all products when complete. • “Use” of RIM based standards (or the “other half” of the HDF)

3. Priority • Both are important • Risks are different to HL7 • Ballot/Publication the most immediate risk to the continued publication of normative editions • Lack of “use” tools has been repeatedly identified as a barrier to the adoption of RIM-based Standards.

4. Publication

5. Critical Issues • Publication content is prepared on personal systems within WG • Quality review and harmonization of static model definitions across WGs: • occurs semi-manually at the submitter (WG) level; • thus, before publication, specifications must undergo an iterative review and correction process for cross-WG concerns

6. Current Publication Process

7. Future Publication Process

8. Current Capabilities(and some resulting issues) • HL7 is publishing an increasing scope, volume and variety of specifications in each of 3 development ballot cycles plus, other approved ballot cycles and one normative edition • Balloting process is web based, permitting global participation • V3 specification development and publishing is supported by tooling designed to minimize design errors by authors

9. Current Capabilities(and some resulting issues) • Specifications may include V3 artifacts intended to be input into automated processes as part of normative standards • Many implementers across the globe are taking advantage of V3 artifacts to produce implementation guides, test cases, validation process input or as initial design artifacts for their own software development

10. Publication Issues • Increased scope and volume of the normative edition is stressing capacity of staff support • Different specification preparation processes are followed within work groups depending on group preferences and volunteer skills/time available

11. Publication Issues • The specification content structure has become inconsistent across specifications over time, particularly for content prepared as text documents • Text editing for content expressed in XML files lacks a good WYSIWYG editor, leading to inconsistent representation • There is little automated publication quality assurance tooling available to work groups prior to publication processing

12. Publication Issues • Significant authoring time/skill is required to produce specification artifacts that could be automated • Version management of interdependent artifacts and specification content is difficult over time and across specifications • There are performance issues that negatively impact the publication production process • There will be further response issues if we increase the use of web based applications.

13. Publication Issues • Tool support and publication production rely on diminishing volunteer time/skills which increases quality risks and publication delays • V3 Ballot becoming unwieldy for reviewers and requests received for Domain or Topic “views” with all dependent sections included, capable of being printed • Cross specification completeness and quality checks desired

14. Publication Issues • Template Authoring (e.g., CDA IGs) adds additional static model constraints to those currently used when designing static models which will require new authoring capabilities to capture required rules

15. Tools Today(by Product Life Cycle Process Step) • Current Ballot Production and Publishing Process • Project Approval • Word – scope statement • Project Initiation • Word - project plan • Project Insight – register project • Requirements Analysis • Standard UML tools; Rational Modeling suite - class diagrams, activity diagrams, state diagrams • Word – requirements glossary, business rules and vocabulary definitions

16. Tools Today(by Product Life Cycle Process Step) • Current Ballot Production and Publishing Process (cont.) • Logical Design—V3 Messages • RMIM Designer – static models • Publication Database – dynamic models, explanatory text • V3 Schema Generator – XML and MIF schemas • RoseTree – HMDs • Logical Design—V3 Foundation • Rational Rose - RIM • Vocabulary Harmonization Submission - Vocabulary • RoseTree – RIM, Vocabulary • XML Authoring - Abstract DataTypes • Web-based OID registry – OIDs

17. Tools Today(by Product Life Cycle Process Step) • Current Ballot Production and Publishing Process (cont.) • Draft Specification • V2 Specification • Word Template • V3 Specification • RMIM Designer • Publications Database, Description Editor – explanatory text, model annotations • Publishing Widget - Publications Database extract • V3 Schema Generator – XML transforms to CSV, HTML, XSD, MIF formats • Excel – macros produce HMD table view from CSV

18. Tools Today(by Product Life Cycle Process Step) • Current Ballot Production and Publishing Process (cont.) • Draft Specification • EHR Functional Model • Word • CCOW • Word • Arden Syntax • Word

19. Tools Today(by Product Life Cycle Process Step) • Current Ballot Production and Publishing Process (cont.) • Ballot Publication • V3 Specifications Ballot Site • Ballot publishing XML transform process – ballot directory, indexing and linking HTML to form V3 Ballot Site • Similar process to produce V3 Normative addition with resulting version identification added • WinZip – package downloads • V2, EHR Functional Model, CCOW Specifications • Word • PDF transform – PDF format

20. V3/RIM-Based Ballot Publication • The primary reason HL7 has developed proprietary tooling is: • To be able to enforce HL7 design methodology and rules as artifacts and supporting text are authored. • There is a consistent tension between the trade-offs of quality and familiarity when developing tools. • Since V3 intends to encourage consistency of design across domains and topics and has a RIM as a unifying mechanism, any tools that replace those that HL7 is currently dependent on must increase coherence and consistency, while increasing productivity of authors and editors by increasing ease of use.

21. Future Publication Process

22. Future Publication Process • The major difference between the current and proposed process: • Increase the quality of specifications by centralizing specification design artifacts and explanatory text in a robust source control environment. • Automate quality checks both within and across domains that can be run iteratively as specifications are developed and any discrepancies reported to appropriate work groups until all automated checks have passed. • Then (and only then) are the draft specifications submitted for the integrated ballot and publishing production.

23. Future Process Pre-requisites • Develop detailed processes and agree to: • Change tracking bug report tracking • Design tools for both static and dynamic models with output in XML • Standardize specification structure for all specification types • Author all specification source text in XML format • Select XML authoring tools that provide familiar WYSIWYG formatting features and spell check

24. Future Process Pre-requisites • Develop detailed processes and agree to (cont): • Agree on automated quality criteria • Develop quality checks (processes and automation) • Put in place conversion processes to transform existing content to new formats • Train modeling, vocabulary and publishing facilitators in new tools and processes • Agree to specification formatting styles and develop style sheets for them • Confirm the design and plan for an infrastructure capable of running increased volumes without performance degradation.

25. Opportunities • IBM sponsored licenses of Rational Modeling Suite for use by HL7 volunteers supporting requirements analysis and documentation • Open Health Tools (OHT) has current and proposed projects that provide opportunities to collaborate to produce appropriate tooling: • NHS sponsored Static Model Designer Project will produce a replacement for the RMIM Designer • IHTSDO sponsored SNOMED CT terminology work bench will produce tools likely to be of use in managing HL7 vocabulary as well

26. Opportunities • IBM/VA sponsored UML Modeling Tools intends to produce tools based on Eclipse foundation that use a familiar UML notation but enforce HL7 Static Model Constraint rules, with enhancements to automate more types of constraints using current Object Constraint Language and emerging OMG Semantics of Business Vocabulary and Rules (SBVR) • OHT has identified a potential project to jointly sponsor with HL7, IBM and IHTSDO, an opportunity to leverage publishing tools based on DITA (a “Topic Map” based standard for consistent publishing of both human readable documentation and machine readable artifacts) for which external funding may become available

27. Opportunities • Explore with the NHS opportunities to leverage tools developed to support NHS implementation guide production, especially those used to support MIF based static model annotations, model difference comparisons, dynamic model design and presentation, and template design as well as XML processes used for quality checking • Revisit existing MOU with UNLV to confirm continued infrastructure support or consider alternatives • Consider tooling required to support SOA specifi-cation development and include in tooling plans

28. Opportunities • Consider investing in increased tooling training for modeling, vocabulary and publishing facilitators, with an emphasis on editors of current specifications that are not XML based • Explore conversion strategies to convert existing Word specifications into XML format and using XSLT transforms to ready them into a new integrated DITA based structure