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

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

http://hl7projects.hl7.nscee.edu/projects/hdf/

http://www.hl7.org/v3ballot/html/help/hdf/hdf.htm

http://www.hl7.org/v3ballot/html/help/hdf/hdf.htm

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


4. Specification Design Process (SDP): Design, Harmonization, and Localization

4.1 Overview

4.2 Context


4.4 Process and Tasks


4.6 Tools

4.7 Artifacts


8. Ballot Publication Process

8.1 Overview

8.2 Context

8.3 Roles and Responsibil ity

8.4. Process and Tasks


8.6 Tools

8.7 Artifacts


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


5. Standard Profiling Process (SPP): Constraints, Extensions, and Annotations

5.1 Overview

5.2 Context




5.6 Tools

5.7 Artifacts


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.6 Tools

3.7 Artifacts


7. Change Control Process (CCP)

7.1 Overview

7.2 Context




7.6 Tools

7.7 Artifacts


6. Technology Specification Process (TSP)

6.1 Overview

6.2 Context




6.6 Tools

6.7 Artifacts


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


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


Legend


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


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



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



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


• Resolve technical defects

• Adopt new requirements

• Timely resolution between ballots

• Time resolution of industry comments (DSTU)


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

Documents

business process requirements

product development

waterfall slide

project services wg

hl7 project homebase

hdf process overview

business requirements

project insight