1. HDF: HL7 Methodology Ioana Singureanu M&M co-chair, HDF Editor Eversolve, LLC

2. HL7 Methodology Intended Audience: volunteers involved in standards development, facilitators, implementers Description: This tutorial describes the current and future HL7 methodology as described in the current DSTU. The elements of HL7 methodology described in this tutorial will the processes and artifacts required in order to complete, among other activities, an analysis of stakeholder requirements, the design of standards specifications, and technology implementation for published specifications. These processes and artifacts will be discussed in the context of the new project lifecycle intended to improve the effectiveness of projects. Additionally, this tutorial will cover elements of the Unified Modeling Notation (UML 2.1) required to analyze requirements, document behavior/dynamic modeling, and produce testable, technology-specific artifacts for implementation and conformance testing. Tools: HL7 Project Homebase, UML 2.1 Modeling Tool (.e.g. Rational Software Modeler) Related tutorials: Project Insight and Change Control

3. Healthcare Development Framework (HDF) Successor to the Message Development Framework Generic methodology adapted for healthcare interoperability A framework for development of interoperability specifications Process Artifacts (includes samples) Guidance/Best-practices HDF References HDF Project: http://hl7projects.hl7.nscee.edu/projects/hdf/http://hl7projects.hl7.nscee.edu/projects/hdf/ HDF Documentation: use Docs tab HDF tutorial: on the Docs under Tutorials HL7 Ballot Site Background Documents http://www.hl7.org/v3ballot/html/help/hdf/hdf.htm http://www.hl7.org/v3ballot/html/help/hdf/hdf.htm

5. HDF Process Overview Processes for work groups Project lifecycle Product analysis, design, approval Modeling and Methodology is the editor, other groups are involved (e.g. Project Services, Publication) Input information, outcome/artifacts, explicit process steps, stakeholders Iterative rather than waterfall

6. HDF Processes and Artifacts

7. Project Lifecycle for Product Development Standard development milestones (maintained by the Project Services WG)

8. Project Lifecycle for Product Development

9. Analysis Design Profiling Project Initiation DSTU Ballot May 2010 Nov 29 th, 2009 Mar 21 st, 2010

10. Analysis Project Initiation Informative Ballot Jan 2010 Oct 2009 Nov 29 th, 2009

11. Initiation Analysis Ballot Design

12. Chapter Structure Overview Context in the overall process Roles and Responsibilities Quality Criteria Tools used to automate and fulfill the process Artifacts used as input and created as an outcome of this process

13. Project Initiation Process (PIP) Roles used as lifelines (swim lane) Steps assigned to roles Process steps details Decisions Used to initiate new standard specifications or implementation guides

14. Initiation Analysis Ballot Design

15. Domain Analysis Process (DAP) Analysis Model Requirements consensus Improve communication between stakeholders from different organizations

16. Domain Analysis Model (DAM) Analyze the requirements, business process, use cases Information shared and system behavior Needed to reach agreement on the impact of a specific requirement or change request Required regardless of the target specification Provides justification/rationale for standard designs Best-practice for software development projects Well-suited for our Project Lifecycle Process

17. DAM Artifacts (Section 3.7) Storyboard = Scenario Process analysis Workflow Capabilities A business use case will refer to one or more scenarios Information/Static analysis Behavior/Dynamic analysis

18. NameDescription Domain Expert A Domain Expert, sometimes known as a Subject Matter Expert (SME) or Subject Matter Specialist (SMS), has detailed knowledge and hands-on experience in the domain of interest. This role does not require detailed knowledge of HL7 but it does require high level understanding of interoperability concepts. During the course of Requirements Analysis, a domain expert will acquire working knowledge of UML in order to communicate effectively with the Business Requirements Analyst. The SME associates actors with the activities they perform, specifies when they perform them, and what information is required. The SME will provide data element definitions and terminology definitions, where appropriate Business Analyst The business analyst is knowledgeable about the interoperability needs in a certain domain and the systems that are involved. The analyst must have knowledge of business processes and how those business processes are automated through the use of integrated systems. The analyst and domain expert are expected to analyze the information requirements and business process requirements needed to fulfill the scope of the project. HL7 Modeling Facilitator The HL7 Modeling Facilitator is knowledgeable in applying the HL7 Requirements Analysis process described in this chapter. This person is responsible for guiding the development of the requirements specification and for coordinating all of the activities associated with the analysis of project requirements. The facilitator is skilled in the use of the UML tools and in creating models and view during requirements analysis and documentation. Roles and Responsibilities

19. Domain Analysis Steps Process Analysis as it relates to interoperability use shared capabilities Order management Person Registry Use Case Analysis Requirements analysis Business use cases Including scenarios

20. Triggers State-change based business triggers Notifications regarding state-changes Expiration notification User-initiated Initiate state-changes renew suspend

21. Triggers State-change based business triggers Notifications regarding state-changes Expiration notification User-initiated Initiate state-changes renew suspend

22. Sample Process Flow Analysis Interoperability Pre-condition Post-condition

23. Shared Information Focal class Properties Associated class Iterative refinement

24. Use Case Analysis Pre-conditions/assumptions Basic flow Alternate flow Post-condition/ outcomes

25. Storyboards vs. Use Cases Business Context as structured narrative May be used to back up use cases For backward compatibility

26. Information Analysis

27. Initiation Analysis Ballot Design

28. Specification Design Process (SDP) DAM as input Specification Design

29. Roles and Responsibilities NameDescription AffiliateHL7 Affiliate organization or consortium that creates designs artifacts localized for a locale or consortium. Committee Stewart Person that represents a project or committee in regards to reference model harmonization requests. Business Analyst This roles requires knowledge of the HDF and domain expertise This person is responsible for collecting interoperability requirements analysis and seeing to their inclusion in the standard specification. This role requires knowledge business rules surrounding the process that is the focus of the specification. The analyst is an individual skilled in the use of the artifacts produced during requirements analysis. HL7 Modeling Facilitator The HL7 Modeling Facilitator is knowledgeable in the HDF, knowing the processes that must be performed to produce an HL7 Requirements Specification. This person is responsible for guiding the development of the standard specification. HL7 Modeling facilitators will that the proper use of the HDF is done consistently across domains and standard specifications. Work group or Project Team The members of the work group (TC or SIG) or project that are involved in validating the contents of design specifications for HL7 standards. Work group chairs are typically involved in validating domain-specific requirements and refinements are correctly represented in a harmonization proposal or design specification.

30. Information Model Design Shared information Controlled Terminology Based on the DAM and using the HL7 references: Reference Information Model (RIM) Structural Vocabulary Used to create standard specifications and runtime artifacts Repeated constrains to a set of common classes in a business area

31. Information Model Design

33. Mapping DAM information Information design is traceable to analysis

34. Design traceability

35. DAM DIM Business-aligned Interoperability-enabled RIM Mapping Domain Analysis Model (DAM) Design Information Model (DIM)

36. Dynamic/Behavioral Design Design interactions Application roles Interfaces Triggers and operations on HL7 reference state machine Act Managed Participation Role Entity

37. Dynamic/Behavioral Design

39. Harmonization RIM and structural vocabulary change control

40. Harmonization RIM and structural vocabulary change control

41. Design Artifacts Overview

42. Allowed States and Transitions

43. Interaction Design

44. Localization

45. Annexes: Sample artifacts

46. Sending process (request initiation)

47. Receiving Process (request fulfillment)

48. operation initiatingresponse Interface = Capability Interface Design

49. Initiation Analysis Ballot Design

50. Ballot Publishing To be defined by Publishing WG Selection of specific designs and analysis models for publication Governance and Operation Manual specifies the high- level process, rules, and principles E.g who may participate HDF specifies the process followed by those who put together the publication

51. Initiation Analysis Ballot Design

52. Implementation Technology Specification Implementation-neutral design ITS specifies mapping the design model to a target implementation technology XML - available Java – available Other possible examples WDSL – service contract BPEL – service orchestration XCML – security and privacy Maintained by the ITS WG

53. Implementation: Specification Profiling Maintained by Implementation and Conformance WG

54. Change Control Process Resolve technical defects Adopt new requirements Timely resolution between ballots Time resolution of industry comments (DSTU)

55. Change Control Process