Tooling Strategy DRAFT DOCUMENT for REVIEW AND COMMENTS

1. Tooling StrategyDRAFT DOCUMENT for REVIEW AND COMMENTS Budget Implications HL7 Tooling Work Group (WG)

2. Tools and Specifications Are Interdependent

3. Full life cycle of standards and their adoption • The arrows represent milestones as the end state of a corresponding process • Although quality assessment may cause steps to be repeated, the natural progression is sequential. • All steps require tools and produce outputs • Tools that can use the output of other tools reduce the time and effort of users and reduce errors • The Tooling Work Group is identifying tools that make standards easier to produce and easier to adopt

4. Standards Development • Different types of standards specifications are developed using different tools • The primary purpose of a standards specification is for people to read it • A secondary output of standards specifications can be output that is useful in downstream stages

5. Software Development • HL7 tools should be able to be used to refine the universal standard for use by implementation initiatives, whether the resulting implementation guides are published via HL7 processes or not • Output resulting from HL7 standards processes may be useful for software development and certification processes, but the responsibility to develop tools to support these stages is not part of HL7’s current mandate Clearly in HL7’s Responsibility Clearly Not in HL7’s Responsibility

6. Software Deployment and Operations Clearly Not in HL7’s Responsibility • However, there are some shared interests to remember: • Some tools that are useful in standards development or refinement steps may also be useful in software deployment and operations stages • Tools used in these stages are primarily the responsibility of HL7 members, so no request for funding would be directly targeted for this stage • Useful tools may be recognized and validated via the RIMBAA work group and communicated to potentially interested parties by the Tooling WG communication

7. Lessons Learned • Developing an initial version of a tool is only the first, and often least, cost • Producing tools in a predictable, responsive timeframe is unrealistic to do with all volunteers • “Donated” tools are often difficult to support and maintain and do not interoperate with other tools (warning) • Standards that produce MIF based technical components are useful in downstream processes • Incremental development is less risky but requires more resources for testing and more formal test plans and related test cases • Tools that are suitable for technical users may not be suitable for less technical users • Design attention to usability costs more but can produce more useful tools • One tool that does a lot of things is more difficult to maintain than different tools that are designed to work together • Tools that are based on different technologies require expertise in that technology to successfully support and maintain (warning)

8. Assumptions • HL7 wishes to promote the ease of adoption using tools to minimize effort • HL7’s primary responsibility is to produce and approve universal standards • HL7 will fund tools that can be used to refine universal standards and support implementation guidance • HL7 will encourage standards to be developed that include components useful to “downstream” processes • HL7 does not intend to develop tools in competition with its members and therefore does not fund tools used further downstream, unless they are also useful further upstream • HL7 may facilitate open-source tooling that supports software development, testing and certification, configuration and operation by enhancing communications about such tools and promoting resulting tools as evaluated by HL7 RIMBAA (note: RIMBAA works in this domain typically outside the awareness ofmost of HL7) • HL7 will maintain and supports tools it commits to acquire/develop • HL7 expects supported tools to interoperate • HL7 will encourage open source development and enhancement of tools of interest to HL7 members

9. Preliminary Tooling Development Strategy • Tooling will acquire/develop tools needed to produce standards as the first priority • Tooling projects that produce tools that are useful for both standards development and downstream software development should normally receive priority • Funded tooling projects are expected to conform to MIF (where appropriate) to enable interoperability among tools, including publishing tooling • Funded tooling project success criteria will include demonstrated interoperability • Eclipse will be the preferred tooling development environment • Recommend the TSC require projects to indicate how they expect to publish and what technical components will be produced – may require update to PSS template • Encourage volunteer toolsmiths working directly with HL7 Work Groups to become tooling liaisons with HL7 Tooling, to document requirements and to learn how to make tools interoperate with other tools, including publishing • Encourage volunteer tool users to become actively involved in tooling projects by paying for users to be testers and documenters • Funded tooling projects will be conducted as open development/open source projects – preferably in collaboration with Open Health Tools • Close collaboration with Publishing, Modeling and Methodology, and other directly affected Work Groups will be part of each tooling project • Tooling projects will include tooling for V2 as well as V3 • Tooling used in software development, implementation and operation stages will be fostered via the RIMBAA Work Group • Improved communication to both internal and external audiences for all stages of the standards and software lifecycle is being planned • Tools will be budgeted based on the full life cycle to better manage year to year costs

10. Budget Implications • Funded projects will include resources to lead, document requirements, code, test and document tools produced • Project coordination will be needed to monitor multiple projects and resolve cross-project-cross working group issues in a timely fashion • More formal project management reduces risk but may also take more time • Expertise for architectural advice for the Eclipse platform will be needed to reduce risk • HL7 support staff skill mix may need to be enhanced to cost-effectively support and maintain what gets acquired and/or built • HL7 HQ infrastructure may need to be enhanced

11. Tooling WG Proposed Budget Categories • Tooling administration • Harmonization support • OID Registry support • Tooling WG support- existing staff responsibilities • Project Coordination • Tooling Development Projects • Tooling Enhancement Projects • New Tooling Projects • Tooling communication including upgraded documentation • Tooling training • Tooling physical infrastructure

12. Known/Current projects that need Resource Estimates • Vocabulary Management • Possibly IHTSDO Workbench enhancement • EHRS-FM Profile Designer - • Static Model Designer Upgrade – • V2 Messaging Workbench update