1 / 55

HDF: HL7 Methodology

HDF: HL7 Methodology. Ioana Singureanu M&M co-chair, HDF Editor Eversolve, LLC. HL7 Methodology . Intended Audience: volunteers involved in standards development, facilitators, implementers Description:

mervyn
Download Presentation

HDF: HL7 Methodology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HDF: HL7 Methodology Ioana SingureanuM&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/ • 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

  4. 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

  5. HDF Processes and Artifacts

  6. Standard development milestones (maintained by theProject Services WG) Project Lifecycle for Product Development

  7. Project Lifecycle for Product Development

  8. Profiling ProjectInitiation May 2010 Nov 29th, 2009 Analysis DSTUBallot Mar 21st , 2010 Design

  9. ProjectInitiation Oct 2009 Analysis Nov 29th, 2009 InformativeBallot Jan 2010

  10. Initiation Analysis Ballot Design

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

  12. Project Initiation Process (PIP) • Roles used as “lifelines” (“swim lane”) • Steps assigned to roles • Process steps details • Decisions • Used to initiatenew standard specificationsor implementation guides

  13. Initiation Analysis Ballot Design

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

  15. 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

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

  17. Roles and Responsibilities

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

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

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

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

  22. Shared Information Iterative refinement Focal class Associated class Properties

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

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

  25. Information Analysis

  26. Initiation Analysis Ballot Design

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

  28. Roles and Responsibilities

  29. 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 Information Model Design

  30. Information Model Design

  31. Information Model Design

  32. Mapping DAM information • Information design is traceable to analysis

  33. Design traceability

  34. DAM  DIM Interoperability-enabled Business-aligned RIMMapping Design Information Model (DIM) Domain Analysis Model (DAM)

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

  36. Dynamic/Behavioral Design

  37. Dynamic/Behavioral Design

  38. RIM and structural vocabulary change control Harmonization

  39. RIM and structural vocabulary change control Harmonization

  40. Design Artifacts Overview

  41. Allowed States and Transitions

  42. Interaction Design

  43. Localization

  44. Annexes: Sample artifacts

  45. Sending process (request initiation)

  46. Receiving Process (request fulfillment)

  47. Interface = Capability Interface Design initiating response operation

  48. Initiation Analysis Ballot Design

  49. 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

More Related