HL7 Development Framework Tutorial

1
HL7 Development Framework Tutorial

• Abdul-Malik Shakir
• Principal Consultant, Shakir Consulting
• April 2003

2
My HL7 Background

• Abdul-Malik Shakir
• Principal Consultant, Shakir Consulting, La
  Verne, CA
• HL7 Member since 1991
• Member of the HL7 Board of Directors
• Chair of the Education and Implementation
  Committee
• Member of the Architectural Review Board
• Member of the Process Improvement Committee
• Co-Chair of the Modeling and Methodology
  Committee
• Project Manager for the HL7 Development Framework
  Project

3
Session Objectives

• To raise awareness of the HL7 Development
  Framework (HDF) project.
• To summarize the accomplishments and remaining
  planned activities of the HDF project.
• To introduce the HDF metamodel and its
  relationship to the UML metamodel
• To introduce the HDF methodology and its
  relationship to the MDF methodology
• To encourage your participation in designing and
  deploying the HDF methodology.

4
Session Overview

• Session I
• HL7 Development Framework Project
• Unified Modeling Language Metamodel
• HDF UML Profile and Metamodel
• HDF Model Interchange Format
• Session II
• HL7 Message Development Framework
• HDF Development Methodology
• HDF Pilot Projects
• HDF Developers Guide
• HDF Transition Planning

5

• HL7 Development Framework Project

6
Project Introduction

• The purpose of the Health Level Seven (HL7)
  Development Framework Project is to research,
  analyze, design, and document the processes,
  policies, and artifacts associated with
  development of HL7 published specifications and
  standards.
• The HL7 Development Framework (HDF) project will
• Expand HL7s modeled-based approach for standards
  development beyond messaging to its other
  standards such as structured documents, context
  management, and standards related to electronic
  health records
• Maximize the benefits HL7 derives from using the
  Unified Modeling Language (UML) as a foundation
  for its model-based approach to standards
  development
• Facilitate increased participation of HL7
  members, subject matter experts, and implementers
  in the development of HL7 standards.
• Enable HL7 to remain the industry leader in
  model-driven development of comprehensive
  standards for application interoperability in the
  Health industry.

7
Project Background Health Level Seven

• The mission of HL7 is to provide a comprehensive
  framework and related standards for the exchange,
  integration, storage, and retrieval of health
  information that support clinical practices and
  the management, delivery and evaluation of health
  services.
• HL7 began developing standards in 1987 with the
  publication of its messaging specification - the
  Application Protocol for Electronic Data Exchange
  in Healthcare Environments.
• In the years since its founding, HL7 has evolved
  beyond traditional messaging protocols to include
  clinical document architectures, medical logic
  modules, component specifications, and standards,
  guidelines, and related services for the
  management of electronic health records.

8
The Family of HL7 Specifications and Standards

• Version 2.x and 3.x messaging specifications
• Knowledge representation and clinical decision
  support (Arden Syntax)
• Specification of components for context
  management (CCOW)
• Standardization of clinical document structures
  (CDA)
• Vocabulary definitions for use in clinical
  messages and documents
• Standards, methodologies and services related to
  electronic health records (EHR)
• Informative specifications in the area of
  security, privacy, and accountability.

9
Project Background HL7 V3 Methodology

• In 1992 HL7 made a fundamental shift in the
  method it uses to develop its specifications and
  standards.
• The new methodology, referred to as HL7 Version
  3.0 (or V3), is a model-driven standards
  development methodology based upon modern
  object-oriented software development practices.
• In January 1996, the HL7 Technical Steering
  Committee adopted the model-driven approach and
  the Modeling and Methodology Technical Committee
  assumed primary responsibility for ongoing
  development of the V3 methodology.

10
Project Background HL7 MDF Process Model
11
HL7 Message Development Framework

• The HL7 Message Development Framework (MDF)
  defines the HL7 V3 message development process.
• It identifies the phases, activities, and models
  used in the process of developing HL7 message
  specifications.
• The HL7 MDF was first published in 1997. It has
  undergone two major revisions since then once in
  1998 and again in 1999.
• The current version of the MDF (v3.3), published
  in December 1999, has not been maintained and is
  consequently out of alignment with current
  message development practices.

12
HDF Development Methodology Specification

• The HDF Development Methodology Reference Manual
  is a replacement for and an extension to the HL7
  Message Development Framework (MDF).
• The HDF Development Methodology Reference Manual
  differs from the MDF in terms of
• Scope of Coverage
• Alignment with UML
• Maintenance/versioning Procedures
• Companion documents to the HDF Development
  Methodology Reference Manual are
• The HDF Metamodel Specification
• The HDF Developers Guide

13
HDF Project Scope and Objectives

• Project Scope
• Develop and publish the HDF Development
  Methodology Reference Manual
• Develop and publish the HDF UML Profile and
  Metamodel Specification
• Develop and publish the HDF Developers Guide
• Project Objectives
• Expand the modeled-based approach for standards
  development beyond the HL7 messaging standard.
• Embrace the UML standard, conventions, and
  practices as the foundation for the HL7
  model-based approach to standards development.
• Facilitate the participation of HL7 members,
  subject matter experts, and implementers in the
  development of HL7 standards.
• Enable HL7 to remain the industry leader in
  model-driven development of comprehensive
  standards for application interoperability in the
  Health industry.

14
HDF 2002 Accomplishments

• Defined the HDF project scope and objectives
• Organized project team and team member
  assignments
• Mapped the MDF to the UML metamodel
• Reconciled MDF and UML metamodel discrepancies
• Used UML extension mechanisms to define an HL7
  UML Profile
• Established a broad outline of the HDF
  development process
• Prepared and reviewed initial drafts of the seven
  chapters describing the phases of the HDF
  development lifecycle
• Prepared and presented tutorials on the HDF at
  two HL7 working group meetings

15
HDF 2003 Objectives

• Prepare phase II project charter
• Obtain project approval and funding
• Finalize documentation of the development
  lifecycle
• Conduct pilots of the development process
• Publish release 1 of the HDF Development
  Methodology Reference Manual
• Publish release 2 of the HDF UML Profile and
  Metamodel
• Publish release 1 on the HDF Model Interchange
  Format
• Prepare an initial draft of an HDF Developers
  Guide
• Establish a transition plan for the HDF process
  and metamodel

16
HDF Phase II Subproject Timelines and Task Leaders

• HDF Project Planning and Management
• 01/06/2003 01/05/2004 Abdul-Malik Shakir
• HDF Development Methodology Reference Manual
• 01/06/2003 12/26/2003 Abdul-Malik Shakir
• HDF Metamodel and Model Interchange Format
• 02/03/2003 12/26/2003 Tony Mallia and Lloyd
  Mckenzie
• HDF Pilot Projects
• 01/06/2003 09/05/2003 Charlie Mead
• HDF Developers Guide
• 06/23/2003 12/05/2003 Woody Beeler
• HDF Transition Planning
• 06/23/2003 12/26/2003 Mead Walker

17

• Unified Modeling Language Metamodel

18
Unified Modeling Language Overview

• The models used in the HL7 V3 process are based
  upon the Unified Modeling Language (UML).
• UML is a graphical language for visualizing,
  specifying, constructing, and documenting the
  artifacts of a software-intensive system.
• UML is an Object Management Group standard that
  represents the unification of best practices in
  practical object-oriented modeling.
• Development of the UML began in 1994 when James
  Rumbaugh and Grady Booch of Rational Software
  Corporation began combining the concepts from the
  Object Modeling Technique (OMT) and Booch
  methods, resulting in a unified specification in
  1995.
• In the Fall of 1995, Ivar Jacobson joined
  Rational and the unification effort, merging in
  the Object-Oriented Software Engineering method
  (OOSE).
• The joint work of Rumbaugh, Booch, and Jacobson
  was called the Unified Modeling Language (UML).

19
UML Core Development Team
The following persons were members of the core
development team for the UML proposal or served
on the first or second UML Revision Task Force

• Colorado State University Robert France
• Computer Associates John Clark
• Concept 5 Technologies Ed Seidewitz
• Data Access Corporation Tom Digre
• Enea Data Karin Palmkvist
• Hewlett-Packard Company Martin Griss
• IBM Corporation Steve Brodsky, Steve Cook
• I-Logix Eran Gery, David Harel
• ICON Computing Desmond DSouza
• IntelliCorp and James Martin Co. James Odell
• Kabira Technologies Conrad Bock
• Klasse Objecten Jos Warmer
• MCI Systemhouse Joaquin Miller
• OAO Technology Solutions Ed Seidewitz

• ObjecTime Limited John Hogg, Bran Selic
• Oracle Corporation Guus Ramackers
• PLATINUM Technology Inc. Dilhar DeSilva
• Rational Software Grady Booch, Ed Eykholt, Ivar
  Jacobson, Gunnar Overgaard, Jim Rumbaugh
• SAP Oliver Wiegert
• SOFTEAM Philippe Desfray
• Sterling Software John Cheesman, Keith Short
• Sun Microsystems Peter Walker
• Telelogic Cris Kobryn, Morgan Björkander
• Taskon Trygve Reenskaug
• Unisys Corporation Sridhar Iyengar, GK Khalsa,
  Don Baisley

20
Primary Design Goals of the UML

• Provide users with a ready-to-use, expressive
  visual modeling language to develop and exchange
  meaningful models.
• Furnish extensibility and specialization
  mechanisms to extend the core concepts.
• Support specifications that are independent of
  particular programming languages and development
  processes.
• Provide a formal basis for understanding the
  modeling language.
• Encourage the growth of the object tools market.
• Support higher-level development concepts such as
  components, collaborations, frameworks and
  patterns.
• Integrate best practices.

21
UML Model Views and Diagrams
22
UML Model Diagrams and Views

• Use Case Diagram
• Class Diagram
• Behavior Diagrams
• State-chart Diagram
• Activity Diagram
• Interaction Diagrams
• Sequence Diagram
• Collaboration Diagram
• Implementation Diagrams
• Component Diagram
• Deployment Diagram

23
Packages of the UML Metamodel

• Foundation
• Core
• Datatypes
• Extension Mechanisms
• Behavioral Elements
• Common Behavior
• Collaborations
• State Machines
• Activity Graphs
• Use Cases
• Model Management

24
UML Metamodel - Foundation Core
25
UML Metamodel - Foundation Core

• Models contain Model Elements including the
  generalizable element Classifier.
• Classifiers have structuraland behavioral
  Features such as attributes, operations, and
  methods.

26
UML Metamodel Model Management
27
UML Metamodel Model Management

• A Package forms a Namespace for the model
  Elements it owns.
• A Package may import Model Elements ownedby
  other Packages.
• A model is a type of Package.

28
UML Metamodel Common Behaviors
29
UML Metamodel Common Behaviors

• UML Behavioral specificationsinclude a sequence
  of Actionswith an ordered set of Arguments.
• UML Actions include create, call, return, send,
  terminate, destroy, and uninterpreted actions.

30
UML Metamodel - Extension Mechanisms
31
UML Metamodel - Extension Mechanisms

• The UML Metatmodel isextended by using
• Stereotypes
• Tag Definition
• Constraints
• Tagged Values.

32
UML Extension Mechanisms

• Stereotype
• A stereotype is, in effect, a subclass of an
  existing metamodel element with the same form
  (attributes and relationships) but with different
  intent. A stereotyped element may have
  additional constraints on it from the base
  metamodel class. It may also have tagged values
  that add information needed by elements branded
  with the stereotype.
• Tag Definition
• Tag definitions specify new kinds of properties
  that may be attached to model elements. The
  actual properties of individual model elements
  are specified using Tagged Values. Tag
  definitions are used to define the virtual meta
  attributes of the stereotype to which they are
  attached.
• Stereotype Constraint
• Designates constraints that apply to all model
  elements branded by the stereotype to which they
  are attached. A constraint is semantic
  information attached to a model element that
  specifies conditions and propositions that must
  be maintained as true otherwise, the associated
  model element is not well-formed.
• Tagged Value
• A tagged value is a keyword-value pair that may
  be attached to any kind of model element. The
  keyword is called a tag. Each tag represents a
  particular kind of property applicable to one or
  many kinds of model elements.

33

• HL7 Development Framework Metamodel

34
HDF Metamodel Development
35
HL7 Message Development Framework Metamodel

• The MDF metamodel v1.13 is included in the
  December 1999 MDF (v3.3).
• The MDF metamodel was updated in August 2000
  (v1.14) to include major revisions to the message
  design model.
• The MDF metamodel was updated again in May of
  2002 (v1.16) to reflect major revisions to the
  practice of producing design information models
  based upon the RIM.
• The HDF Metamodel is base upon a comparison of
  the UML v1.4 metamodel to v1.16 of the MDF
  metamodel (including proposed revisions to the
  vocabulary portion).

36
Packages of the MDF Metamodel

• Model Identification and Scope
• Use Case Model
• Reference Information Model
• Information Model
• Vocabulary Domain Model
• Datatype Model
• Message Specification Model
• Design Information Model
• Hierarchical Message Description
• Interaction Model
• Application Roles
• Interactions

37
Packages of the UML Metamodel

• Foundation
• Core
• Datatypes
• Extension Mechanisims
• Behavioral Elements
• Common Behavior
• Collaborations
• State Machines
• Activity Graphs
• Use Cases
• Model Management

38
Mapping of the MDF to UML
39
MDF to UML Metamodel Mapping Discrepancies

• Model identification data needs to be expanded to
  include data needed for HL7 model management such
  as responsible HL7 committee and project.
• Provisions are needed to address the MDF
  meta-classes Composite Datatype and Datatype
  Component.
• Significant enhancements to the UML metamodel is
  needed to address the issue of Vocabulary
  domains.
• The concepts introduced by MDF in the Design
  Information Model and Hierarchical Message
  Description packages are completely addressed
  within the UML metamodel however significant
  rethinking of the jargon and processes in this
  area is required.
• The mapping of concepts in the Interaction
  Portion of the MDF metamodel is fairly straight
  forward. Most of the conceptual difficulties
  come as a result of unfortunate homonyms between
  the two metamodels. For example, each model
  includes the terms Interaction but with different
  semantics.
• The UML metamodel features used to express
  constraints will need to be more elaborate than a
  simple Boolean text expression. Constraints are
  a major component of any HL7 standard
  specification.
• The MDF concepts of Receiver Responsibility and
  Trigger Event will need to be resolved with the
  overlapping concepts of Action and Event in the
  UML metamodel.

40
MDF Model Identification and Scope
41
UML Metamodel Model Management
42
HDF Model Management
Extensions to the UML Metamodel
43

• The HL7 UML Profile uses the UML extension
  mechanisms to define HL7 stereotypes and tags.
• Each HL7 Stereotype is associated with a single
  UML base class.
• A list of Tags and Constraints is specified for
  each stereotype.
• A definition is provided for each Tag specified
  for sterotypes.

44
UML Metamodel - Extension Mechanisms
45
Stereotypes in the HL7 Profile

• Clone
• CodedValue
• CodeSet
• DataTypes
• DIM
• HL7Attribute
• HL7DataType
• HL7Model

• HL7ModelElement
• HL7Package
• RegisteredCodeSystem
• RIM
• UsageContext
• Vocabulary
• VocabularyDomain

46
HDF UML Profile Stereotype Specifications
47
HDF UML Profile Tag Value Specifications
48
HDF Metamodel
HDF Metamodel UML Metamodel HDF UML Profile
49

• HDF Model InterchangeFormat

50
Model Interchange Requirements
Rational Rose
Rose Tree
Model Repository Design Database / Publication
Database
RMIM Designer
Schema Generator
51
Model Interchange Format Objectives

• Leverage the technology independent
  characteristic of XML
• Establish stability in the format of files used
  to exchange model artifacts between tools
• Facilitate the validation of model interchange
  files
• Facilitate the exchange of model artifacts with
  external entities
• Prepare for implementation of registries,
  templates, and conformance profiles

52
MIF Schema Specifications

• mifBase.xsd
• mifConformanceProfile.xsd
• mifDatatype.xsd
• mifDynamicElements.xsd
• mifExtendedMarkup.xsd
• mifGlossary.xsd
• mifImplementationElements.xsd
• mifPackage.xsd

• mifPatternTypes.xsd
• mifStaticBase.xsd
• mifStaticModelBase.xsd
• mifStaticModelFlat.xsd
• mifStaticModelSerialized.xsd
• mifTemplateElements.xsd
• mifVocabularyElements.xsd
• pubDisplayMarkup.xsd

53
Planned MIF Activities

• Conduct a peer-review of the MIF schema
  specifications
• Align relevant portions of the MIF schema
  specifications with the HDF metamodel
• Migrate existing tooling interfaces to use the
  MIF schemas
• Use the MIF schema specifications for definition
  of an HL7 artifact registry
• Extend the MIF schema specifications for use in
  conformance, templates, localizations, . . .

54
Session I Review

• HL7 Development Framework Project
• Unified Modeling Language Metamodel
• HDF UML Profile and Metamodel
• HDF Model Interchange Format

55
Cookie Break 30 Minutes
56
Session II Overview

• HL7 Message Development Framework
• HDF Development Methodology
• HDF Pilot Projects
• HDF Developers Guide
• HDF Transition Planning

57

• HL7 Message Development Framework

58
The MDF Methodology Overview
59
MDF Models and Process Flow
Storyboard
60
HL7 V3 Conceptual Model
61
HL7 V3 Conceptual Model

• An Application Role is the sender or receiver of
  one or more Interaction.
• An Interaction fulfills a information exchange
  requirement defined in Storyboards and
  exemplified in Storyboard Examples.
• An Application Role sends an Interaction in
  response to a Trigger Event or as part of its
  receiver responsibility.
• A Trigger Event is associated with a state
  transition of a Reference Information Model (RIM)
  class or with a temporal event.
• An Interaction contains one or more Message Type
  defined in an Hierarchal Message Description
  (HMD).
• An HMD is a constrained tabular view of
  hierarchically ordered data structures from a
  Refined Message Information Model (R-MIM).
• A R-MIM is a constrained refinement of a Domain
  Message Information Model (D-MIM).
• A D-MIM is a domain specific instantiation of a
  subset of classes, attributes, and relationships
  derived from the RIM.

62
Simplified MDF Metamodel
Information Modeling
Interaction Modeling
Message Design
Use Case Modeling
63
MDF Methodology in a nut shell

• Use Case Modeling
• Produce a storyboard example
• Generalize the storyboard example into a
  storyboard
• Information Modeling
• Define classes, attributes, datatypes, and
  relationships
• Define vocabulary domains, value sets, and code
  systems
• Define states, trigger events, and transitions
• Interaction Modeling
• Define application roles
• Define interactions
• Message Design
• Define D-MIM, R-MIM, and CMETs
• Define HMD and Message Types

64
HL7 V3 Methodology (in English)

• What application interface problem are we trying
  to solve?
• What application systems are within the scope of
  the problem domain?
• What information needs to be communicated between
  the in-scope applications?
• What is the definition, format, and
  interrelationship of the information to be
  communicated?
• What events initiate communication between
  applications?
• How should the information to be communicated
  between applications be structured and packaged?

65

• HL7 Development Framework Methodology

66
Seven Phases of the HDF Methodology

1. Project initiation and management
2. Requirements gathering and analysis
3. Requirements normalization and harmonization
4. Specification design and packaging
5. Specification publication and balloting
6. Specification refinement and localization
7. Specification implementation and validation

67
HDF Methodology Phases

• Project Initiation and Management Prepare
  project charter and define the scope, objective,
  and approach for the project.
• Requirements Gathering and Analysis Prepare a
  requirement specification with models of the
  static, behavioral, and business rule
  requirements of the standards to be developed.
• Requirements Normalization and Harmonization
  Normalize the requirements models to adhere to
  the structure and style of the HL7 reference
  models and reconcile variances between the
  requirements models and the HL7 reference models.
  
• Specification Design and Packaging Derive
  specification design models from HL7 Reference
  Models guided by the contents of the requirements
  specification.
• Specification Publication and Balloting
  Assemble the specification designs into ballot
  packages and conduct committee and membership
  level ballots. Publish the membership approved
  specification as a standard.
• Specification Refinement and Localization
  Define context sensitive refinements of balloted
  standards and register the refined specification
  as a usage template for the standard. Refine and
  extend balloted specifications to accommodate
  unique local requirements within the jurisdiction
  of HL7 international affiliates.
• Specification Implementation and Validation
  Prepare and register implementation profiles
  describing the implementation of the HL7
  specification within a particular application or
  vendor product line. Prepare a conformance
  profile documenting the adherence of a particular
  implementation to standard, template, or
  localization specifications.

68
The HDF Methodology Workflow
69
Eight Work Products of the HDF Methodology

• Project Charter
• Requirements Specification
• Reference Model
• Design Model
• Standard Specification
• Template Specification
• Implementation Profile
• Conformance Specification

70
HDF Development Methodology Reference Manual Core
Chapters

• Project initiation and management
• Jane Curry
• Requirements gathering and analysis
• Charlie Mead
• Requirements normalization and harmonization
• Abdul-Malik Shakir
• Specification design and packaging
• Abdul-Malik Shakir
• Specification publication and balloting
• Karen VanHentenryck
• Specification refinement and localization
• Jenny Puyenbroek
• Specification implementation and validation
• Jenny Puyenbroek

71
Project Initiation

• Define the project scope and objectives
• Identify project assumptions and constraints
• Identify major project deliverables
• Identify project resource requirements
• Develop project plan with timeline for project
  phases, activities, and tasks
• Obtain required project approvals

72
Project Charter Content

• What is the name and description of the project?
• Who are the stakeholders involved? What are their
  roles?
• Why is the project necessary? What benefit or
  value will it produce?
• What are the objectives of the project? What are
  the expected outputs?
• What will need to be done to accomplish the
  objectives? What skills are needed? What tools
  will be used?
• Is this project dependent on the output or
  decisions of other work?
• What is the expected duration of the project?
  What is the expected work effort? What are the
  expected costs?
• What are the possible risks, both technical and
  organizational, in undertaking this project?
• What are the assumptions or constraints that must
  be accommodated?

73
Requirements Gathering and Analysis

• Prepare storyboards and storyboard examples that
  elaborate upon the project scope statement.
• Conduct an analysis of the storyboards to
  identify potential Actors, Activities, and Use
  Cases.
• Construct Use Case and Activity models depicting
  the behavioral component of the requirements.
• Identify information requirements and construct
  an information model depicting the static
  component of the requirements.
• Prepare Collaboration and Sequence diagrams to
  depict the interaction requirements.
• Document relevant business rules and constraints
  governing models, diagrams, and specifications.
• Update the Project Charter as needed.

74
Requirements Specification Content

• A dynamic description (via UML Activity Diagram)
  of the healthcare business process(es) driving
  the required data/information exchange
• A static description (via UML Class Diagram) of
  the concepts involved in the business process
  (including the structure and relationships of the
  data/information to be exchanged in the course of
  the business process)
• A glossary which carefully and completely defines
  each of the concepts (and concept attributes)
  depicted in the static diagram
• A Use Case model which identifies the system
  involved in the actual HL7 data/information
  exchange and the Conformance-based Application
  Roles that govern this conformance

75
Requirements Normalization and Harmonization

• Map models from the Requirements Specification to
  Reference Models.
• Revise models in the Requirements Specification
  based upon discoveries made during the mapping
  process.
• Document proposed changes to Reference Models to
  accommodate previously unidentified
  requirements.
• Follow the reference model harmonization process
  to adjudicate the proposed changes to Reference
  Models.
• Revise the Requirements Specification as needed
  and its mapping to the Reference Models.

76
Requirements Normalization and Harmonization

• Requirements Normalization
• A cross-reference between static requirements and
  HL7 reference models
• An updated requirements specification document
• A collection of proposed enhancements to the HL7
  reference models.
• Requirements Harmonization
• Adjudicated Reference Information Model change
  proposals
• An updated Reference Information Model
• A re-expression of the static requirements using
  terms and structures from the updated Reference
  Information Model.

77
Specification Design and Packaging

• The Requirements Specification is used to drive
  the transformation of Reference Models into
  Design Models.
• The HDF UML Profile provides constraints to aid
  in ensuring that design models are well-formed
  and depict the requirements in a way that remains
  consistent and traceable back to harmonized
  reference models.
• The contents of design models are organized into
  interdependent packages that partition the design
  space by domain, sub-domain, and target standard
  type (message, document, component).
• Common or reusable design artifacts are packaged
  in a way that makes them assessable across design
  models and design model packages.

78
Specification Design and Packaging

• Specification Design
• Information Structure Design
• Behavioral Features Design
• Business Rules Design
• Specification Packaging
• Packaging Reusable Specifications
• Packaging According to Specification Type
• Packaging Normative And Informative Specifications

79
Specification Publication and Balloting

• Design model content from multiple committees are
  merged and re-packaged in preparation for
  publishing.
• Conflicts and inconsistencies among design models
  are resolved, including the resolution of
  artifact identifiers and inter-model references.
• A publication package is assembled for each
  specification to be balloted and a committee
  level ballot is conducted.
• Multiple committee level ballots may be required
  to resolve negative comments received during
  balloting.
• A full membership ballot is conducted and upon
  successful completion the design specification
  becomes an HL7 standard.
• At the discretion of the HL7 Board selected HL7
  balloted standards are submitted for publication
  as national or international standards (i.e.,
  ANSI or ISO).

80
Committee and Member Level Ballot

• Committee Level Ballot
• Announcing your committees plans to ballot
• Submitting your committee ballot content
• Monitoring the ballot responses
• Resolving negative votes submitted against your
  TC/SIG content
• Advising the submitters of negative
  votes/comments of the disposition of their
  vote/comment
• Member Level Ballot
• Obtain the TSC Chairs authorization to submit
  your content for membership ballot
• Announcing your committees plans for a
  membership ballot
• Monitoring the ballot responses
• Building membership consensus on the disposition
  of the negative votes/comments
• Advising the submitters of negative
  votes/comments of the disposition of their
  vote/comment
• Appealing the disposition of their votes/comments

81
Specification Refinement and Localization

• Specification refinement involves the application
  of additional restrictions to balloted
  specifications to constrain the standard for use
  in a particular context.
• Specification localization is a privilege
  available only to HL7 international affiliates.
• It includes specification refinement and
  RIM-based extensions to the content of balloted
  HL7 standards.

82
Specification Refinement and Localization

• The balloted HL7 Standard is designed to serve
  the needs of a large and diverse population of
  users. It is sometimes necessary to defined
  additional refinements and constraints to the
  standard to facilitate its use in a particular
  context.
• Context for used of a standard might be
  influenced by uniqueness in the jurisdiction,
  region, or clinical discipline for which the
  standard is to be applied.
• Because of the international nature of the HL7
  standard the need for regional or local
  refinements is anticipated and the process for
  localization of the standard is formalized in the
  HDF.
• Refinements are applied to the standard
  specification much in the same way as the
  iterative refinement that occurred during design.
  
• Each refinement may further constrain
  multiplicities and optionality specified in the
  standard and may include allowed datatype or
  vocabulary domain substitutions.
• The resulting refined/localized standard is a
  template specification. The template may be
  registered with HL7 where others in the community
  defined by the context of the template may access
  it for use as an extension to the standard
  specification.

83
Specification Implementation and Validation

• Standard specifications, templates, and
  localizations are input to the specification
  implementation and validation phase.
• New and/or revised template specifications are
  output from the implementation and validation
  phase.
• Implementation profiles and conformance
  specifications are the primary outputs of the
  specification and validation phase.

84
Specification Implementation and Validation

• Implementation of the standard involves mapping
  the information component of the standard to data
  structures in a particular application and
  incorporating the behavior aspects of the
  standard into the behavior of the application.
• The standard specification or localization along
  with template specifications are used by
  implementers to develop an implementation profile
  that describes the design of a particular
  implementation.
• The implementation profile includes documentation
  of the use of extension mechanisms built into the
  standard, the resolution of choice and optional
  structures, and a statement of the adherence of
  the application to sender and receiver
  responsibilities defined in the standard or
  template.
• An Implementation Profile may be used to
  represent the capabilities of a particular
  developers application or it may be used to
  represent the implementation specific
  requirements of a potential consumer of a vendor
  product.
• A conformance specification documents the
  implementation profile in a format that can be
  validated against the standard. The conformance
  specification once validated would highlight
  those portions of the Implementation Profile that
  are non-conformant with HL7 standard
  specifications and localizations.

85
The HDF Methodology Overview
86
HDF Methodology Tasks and Timeline

• 01/06/03 03/07/03 Complete preliminary version
  of core chapters
• 03/10/03 04/04/03 Review preliminary version
  of core chapters
• 03/31/03 06/20/03 Finalize core chapters
• 05/26/03 06/20/03 Prepare ancillary chapters
• 06/16/03 07/25/03 Prepare HDF master document
• 07/28/03 11/28/03 Review and finalize the HDF
  methodology reference manual
• 12/01/03 12/26/03 Publish release 1 of the HDF
  development methodology reference manual

87

• HDFPilot Projects

88
Pilot Projects

• The objectives of HDF pilot projects are to
• Aid in process definition and the discovery of
  best practices
• Validate assumptions concerning the development
  processes
• Demonstrate the development methodology processes
• Exemplify deliverables of the methodology
• Roster of project pilots
• NICTIZ Perinatology Project Irma Jongeneel
• X12N-TG3-WG2 Kathleen Connors
• IDPH Trauma Registry Export Abdul-Malik Shakir
• Pilot Project Activities
• 01/06/03 03/28/03 Identify projects to use as
  pilots
• 03/31/03 08/01/03 Apply the HDF process to
  the pilot projects
• 05/05/03 09/05/03 Document pilot outcomes and
  process feedback

89

• HDFDevelopers Guide

90
Developers Guide

• The HDF Developers Guide is one of many
  anticipated companion documents of the HDF
  Development Methodology Reference Manual
• Content of the HDF Developers Guide
• Initiation thru Design Charlie Mead
• Design thru Implementation Jennifer Puyenbroek
• Tools and Techniques Woody Beeler
• HDF Developers Guide Activities
• 06/23/03 10/24/03 Prepare the HDF Developers
  Guide
• 10/27/03 12/05/03 Publish the HDF Developers
  Guide

91

• HDFTransition Planning

92
HDF Transition Planning

• Communication
• Awareness Raising
• Soliciting Support
• Managing Expectations
• Validating Assumptions
• Retaining Motivation
• Coordination
• Within the project team
• Between Committees
• Between Projects
• With External Activities
• Education
• Practitioners
• Administrators
• Implementers

93
Session Overview

• Session I
• HL7 Development Framework Project
• Unified Modeling Language Metamodel
• HDF UML Profile and Metamodel
• HDF Model Interchange Format
• Session II
• HL7 Message Development Framework
• HDF Development Methodology
• HDF Pilot Projects
• HDF Developers Guide
• HDF Transition Planning

94
Thank You

• Abdul-Malik Shakir
• Principal Consultant
• Shakir Consulting
• 1911 Foothill Blvd., Suite 148
• La Verne, CA 91750
• Office [phone] Mobile [phone]
• Email AbdulMalik_at_ShakirConsulting.com