HDF: HL7 Methodology Ioana Singureanu M&M co-chair, HDF Editor Eversolve, LLC.
Post on 27-Mar-2015
217 Views
Preview:
Transcript
HDF: HL7 Methodology
Ioana SingureanuM&M co-chair, HDF Editor
Eversolve, LLC
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
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 ttp:::www: l::or :v: llot: tml: lp:h h g ba h he hdf
: :: tmhdfh
pkg 1: HDF document structure diagram
Complete
Draft
References
Legend
2. Project Initiation Process (PIP): Initiation, Planning, and Approv al
2.1 Overview
2.2 Context
2.3 Roles and Responsibil ities
2.4. Process and Tasks
2.5 Quality Criteria
2.6. Tools
2.7 Artifacts
(from Healthcare Development Framework (HDF))
HDF Project Site
1. Project Life Cycle for Product Dev elopment (PLCPD)
1.3.1 Project Life Cycle for Product Development (PLCPD)
1.3.2 Project Management Approach
1.3.3 HDF and PLCPD
(from Healthcare Development Framework (HDF))
4. Specification Design Process (SDP): Design, Harmonization, and Localization
4.1 Overview
4.2 Context
4.3 Roles and Responsibil ities
4.4 Process and Tasks
4.5 Quality Criteria
4.6 Tools
4.7 Artifacts
(from Healthcare Development Framework (HDF))
8. Ballot Publication Process
8.1 Overview
8.2 Context
8.3 Roles and Responsibil ity
8.4. Process and Tasks
8.5 Quality Criteria
8.6 Tools
8.7 Artifacts
(from Healthcare Development Framework (HDF))
Annexes
Annex A. Driver's License Example
Annex B. Behavioral/Dynamic Design Examples
Annex C. Document References
Annex D. HL7 Project Homebase Overview
Annex E. Information Model Migration
Annex F. Naming Conventions
(from Healthcare Development Framework (HDF))
5. Standard Profiling Process (SPP): Constraints, Extensions, and Annotations
5.1 Overview
5.2 Context
5.3 Roles and Responsibil ities
5.4 Process and Tasks
5.5 Quality Criteria
5.6 Tools
5.7 Artifacts
(from Healthcare Development Framework (HDF))
http://gforge.hl7.org/gf/project/hdf/: contains the latest HDF documentation, tutorials, etc.
3. Domain Analysis Process (DAP): Analysis and Requirements Documentation
3.1 Overview
3.2 Context
3.3. Roles and Responsibil ities
3.4 Process and Tasks
3.5 Quality Criteria
3.6 Tools
3.7 Artifacts
(from Healthcare Development Framework (HDF))
7. Change Control Process (CCP)
7.1 Overview
7.2 Context
7.3 Roles and Responsibil ities
7.4 Process and Tasks
7.5 Quality Criteria
7.6 Tools
7.7 Artifacts
(from Healthcare Development Framework (HDF))
6. Technology Specification Process (TSP)
6.1 Overview
6.2 Context
6.3 Roles and Responsibil ities
6.4 Process and Tasks
6.5 Quality Criteria
6.6 Tools
6.7 Artifacts
(from Healthcare Development Framework (HDF))
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
act 2: HDF Process Ov erv iew
Change Control Process
Analysis (.7) Design (.8) SpecificationProfiling
TechnologySpecificationProject Initiation/
Approval (.5)
Publication
HDF Processes and Artifacts
Project Lifecycle for Product Development
• Standard development milestones (maintained by theProject Services WG)
act 1.3.1: Project Life Cycle for Product Development
HL7 Protocol Specifications
(.1) Request to enhance or create a new product
(.2)
Request to sunset product (.23)
Requestapproved
(.24)
Sunset Product
(.25)Project sunset
Project Initiation/Approval (.5)
ApprovalReceived
(.6)
Cancel or Withdraw (.4)
Analysis (.7)
Design (.8)
QVSD
QVSD
(.10) SeekComments
Draft Specification (.9)
QVSD
(.11) Comments-Only
Ballot
Ballot type(.12)
DSTU(.13)
DSTU Ballot (.14)
QSVD
Finalize Specification (.17)
Specification and Training
(.15)
QVSDIndustry Use
(.16)
Informative Ballot (.21) QVSD
Normativeor
Informative(.22)
QVSD
Normative Ballot (.18)
Pass(.19) Publication (.20)
QVSD
Project Initiation
Analysis
Design
Ballot
Project Sunset
HL7 Protocol Specification
Legend
HL7 Protocol Specification
Completed
no
yes
yes
no
yes
no
normative
review
failed
no
passed
normative
informative
yes
Project Lifecycle for Product Developmentact 1.3.1: Project Life Cycle for Product Dev elopment
HL7 Protocol Specifications
(.1) Request to enhance or create a new product
(.2)
Request to sunset product (.23)
Requestapproved
(.24)
Sunset Product
(.25)Project sunset
Project Initiation/Approval (.5)
ApprovalReceived
(.6)
Cancel or Withdraw (.4)
Analysis (.7)
Design (.8)
QVSD
QVSD
(.10) SeekComments
Draft Specification (.9)
QVSD
(.11) Comments-Only
Ballot
Ballot type(.12)
DSTU(.13)
DSTU Ballot (.14)
QSVD
Finalize Specification (.17)
Specification and Training
(.15)
QVSDIndustry Use
(.16)
Informative Ballot (.21) QVSD
Normativeor
Informative(.22)
QVSD
Normative Ballot (.18)
Pass(.19) Publication (.20)
QVSD
Project Initiation
Analysis
Design
Ballot
Project Sunset
HL7 Protocol Specification
Legend
HL7 Protocol Specification
Completed
no
yes
yes
no
yes
no
normative
review
failed
no
passed
normative
informative
yes
Analysis
Design
ProfilingProject
Initiation
DSTUBallot
May 2010Nov 29th ,
2009
Mar 21st ,
2010
Analysis
ProjectInitiation
InformativeBallotJan 2010
Oct 2009
Nov 29th, 2009
Initiation
AnalysisBallot
Design
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
pkg 1: HDF document structure diagram
2. Project Initiation Process (PIP): Initiation, Planning, and Approv al
2.1 Overview
2.2 Context
2.3 Roles and Responsibil ities
2.4. Process
2.5 Quality Criteria
2.6. Tools
2.7 Artifacts
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
Initiation
AnalysisBallot
Design
Domain Analysis Process (DAP)
• Analysis Model
• Requirements consensus
• Improve communication between stakeholders from different organizations
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
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
Name Description
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
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
Triggers
• State-change based business triggers
Notifications regarding state-changes
• Expiration notification
• User-initiated
Initiate state-changes
• renew
• suspend
Triggers
• State-change based business triggers
Notifications regarding state-changes
• Expiration notification
• User-initiated
Initiate state-changes
• renew
• suspend
Sample Process Flow Analysis
Interoperability
Interoperability
Pre-condition
Post-condition
Shared Information
Focal class
Properties
Associated class
Iterative refinement
Use Case Analysis
• Pre-conditions/assumptions
• Basic flow
• Alternate flow
• Post-condition/outcomes
Storyboards vs. Use Cases
• Business Context as “structured” narrative
• May be used to back up use cases
• For backward compatibility
Information Analysis
Initiation
AnalysisBallot
Design
Specification Design Process (SDP)
• DAM as input
• Specification Design
Roles and ResponsibilitiesName Description
Affiliate HL7 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.
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
Information Model Design
Information Model Design
Mapping DAM information
• Information design is traceable to analysis
Design traceability
DAM DIM
class A.14: Message Structure
Design Information Model - DIM::Driv ersLicense
- classCode: CS- code: CE = motor vehicle l...- effectiveTime: TS- id: II- statusCode: CS
Design Information Model - DIM::Person
- classCode: CS = person- name: PN
Design Information Model - DIM::DepartmentOfMotorVehicles
- classCode: CS- code: CE = motor vehicle dept- name: ON
Design Information Model - DIM::Serv iceSubject
- typeCode: CS = subject
Design Information Model - DIM::Serv ice
- classCode: CS = act ion- effectiveTime: TS- moodCode: CS = event- code: CE
Design Information Model - DIM::FinancialTransaction
- classCode: CS = financial txn- moodCode: CS = request or event- amt: MO
Design Information Model - DIM::UsesPaymentMethod
- typeCode: CS = uses
Design Information Model - DIM::PaymentMethod
- classCode: CS = payment method- code: CE = act account code- moodCode: CS = event
Design Information Model - DIM::Check
- id: II
Design Information Model - DIM::CreditCard
- classCode: CS = acct- code: CE = creditcard- effectiveTime: TS- id: II- moodCode: CS = event
Design Information Model - DIM::Credits
- typeCode: CS = has credit
Design Information Model - DIM::BankAccountDMV
- balanceAmt: MO- classCode: CS = acct- moodCode: CS = event
Design Information Model - DIM::HolderCustomer
- typeCode: CS = holder
Design Information Model - DIM::HasFinancialTx n
- typeCode: CS = has charge
Design Information Model - DIM::Author
- typeCode: CS = author
Design Information Model - DIM::Driv ersLicenseRenewal
- classCode: CS = drivers l icense...- effectiveTime: TS- moodCode: CS = event
1.. *
+issuer
1
0..1
0..*
1
+holder
1
1
1.. *
1.. *
0..1
1
1
1
1
11
0..*
1
11
1
1
1
1
Business-aligned Interoperability-enabled
RIMMapping
Domain AnalysisModel(DAM)
DesignInformation
Model(DIM)
Dynamic/Behavioral Design
• Design interactions
Application roles
Interfaces
• Triggers and operations on HL7 reference state machine
Act
Managed Participation
Role
Entity
Dynamic/Behavioral Design
Dynamic/Behavioral Design
Harmonization
• RIM and structural vocabulary change control
Harmonization
• RIM and structural vocabulary change control
Design Artifacts Overview
Allowed States and Transitionsstm 4.4.2.1(a): State Transitions
State Transitions
Interaction Designclass 4.4.2.1(d): System Interactions
System Interactions
Localization
Annexes: Sample artifactssd B.1: Interactions
Informer Tracker
1.0 establishconnection()
1.1ORU^R01()
1.2 Parse_Validate():success
1.3 Persist():success
1.4ACK^R01(AA/CA)
1.5send_next()
1.6ORU^R01()
1.7 Parse_Validate():failure
1.8ACK^R01(CE/AE)
1.9log(error)
1.1 0send_next()
1.1 1ORU^R01()
1.12 Parse_Validate():success
1.13 Persist():failure1.1 4
ACK^R01(CR/AR)1.1 5log(error)
1.1 6retry()
Sending process (request initiation)act 4.4.2.1(b): Sending process
Request Sending Proces s
Receiving Process (request fulfillment)class 4.4.2.1(e): Receiv ing Process
Receiv er responsibilities
class 4.4.2.1(c): System Interfaces
Interfaces/System Roles
operation initiating response
Interface = Capability
Interface Design
Initiation
AnalysisBallot
Design
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
Initiation
AnalysisBallot
Design
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
Implementation: Specification Profiling
• Maintained by Implementation and Conformance WG
Change Control Process
• Resolve technical defects
• Adopt new requirements
• Timely resolution between ballots
• Time resolution of industry comments (DSTU)
Change Control Process
top related