HL7 Development Framework TutorialHL7 Development Framework Tutorial
Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting
April 2003
April 2003 HL7 Development Framework Tutorial 2
My HL7 Background
Abdul-Malik ShakirPrincipal 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
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 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 Developer’s Guide HDF Transition Planning
April 2003 HL7 Development Framework Tutorial 5
HL7 Development Framework Project
April 2003 HL7 Development Framework Tutorial 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 HL7’s 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.
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 10
Project Background – HL7 MDF Process Model
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 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 Developer’s Guide
April 2003 HL7 Development Framework Tutorial 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 Developer’s 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.
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 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 Developer’s Guide
• Establish a transition plan for the HDF process and metamodel
April 2003 HL7 Development Framework Tutorial 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 Developer’s Guide 06/23/2003 ~ 12/05/2003 – Woody Beeler
• HDF Transition Planning 06/23/2003 ~ 12/26/2003 – Mead Walker
April 2003 HL7 Development Framework Tutorial 17
Unified Modeling Language Metamodel
April 2003 HL7 Development Framework Tutorial 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).
April 2003 HL7 Development Framework Tutorial 19
UML Core Development Team
• 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 D’Souza
• 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
The following persons were members of the core development team for the UMLproposal or served on the first or second UML Revision Task Force:
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 21
UML Model Views and Diagrams
View Description Diagram(s)
Static Models concepts in the application domain, as well as internal concepts invented as part of the implementation of an application.
Class Diagram
Use Case Models the functionality of the system as perceived by outside users.
Use Case Diagram
Implementation Models the software units from which the application is constructed as well as dependencies among components.
Component Diagram
Deployment Models the arrangement of run-time component instances on run-time resources, such as a computer, device, or memory.
Deployment Diagram
State Machine Models the possible life histories of an object of a class.
Statechart Diagram
Activity Models computations and workflows. Activity Diagram
Interaction Models sequences of message exchanges among roles that implement behavior of a system.
Sequence Diagram Collaboration Diagram
Model Management Models the organization of the model itself. Class Diagram
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 23
Packages of the UML Metamodel
• Foundation
Core
Datatypes
Extension Mechanisms
• Behavioral Elements
Common Behavior
Collaborations
State Machines
Activity Graphs
Use Cases
• Model Management
Foundation
Core
(from Foundation)
Data_Types
(from Foundation)
Extension Mechanisms
(from Foundation)
Behavioral_Elements
Common_Behavior
(from Behavioral_Elements)
Collaborations
(from Behavioral_Elements)
State_Machines
(from Behavioral_Elements)
Use_Cases
(from Behavioral_Elements)
Activity_Graphs
(from Behavioral_Elements)
Model_Management
April 2003 HL7 Development Framework Tutorial 24
UML Metamodel - Foundation Core
GeneralizableElement
isRoot : BooleanisLeaf : BooleanisAbstract : Boolean/ generalization : Generalization...
Attribute
initialValue : Expression/ associationEnd : AssociationEnd...
Method
body : ProcedureExpression.../ specification : Operation
Operation
concurrency : CallConcurrencyKindisRoot : BooleanisLeaf : BooleanisAbstract : Booleanspecification : String
n1
+method
n
+specification
1
Namespace
/ ownedElement : ModelElement...
Constraint
body : BooleanExpression/ constrainedElement : ModelElement...
ModelElement
name : Namevisibility : VisibilityKindisSpecification : Boolean/ namespace : Namespace/ clientDependency : Dependency/ constraint : Constraint/ targetFlow : Flow/ sourceFlow : Flow/ comment : Comment/ templateParameter : TemplateParameter......
0..1
n
+namespace0..1
+ownedElement n
n
*
+constraintn
+constrainedElement
* {ordered}
BehavioralFeature
isQuery : Boolean/ parameter : Parameter...
Feature
ownerScope : ScopeKind.../ owner : Classifier
StructuralFeature
multiplicity : Multiplicitychangeability : ChangeableKind...targetScope : ScopeKind...
<<metaclass>>
Parameter
defaultValue : Expressionkind : ParameterDirectionKind/ behavioralFeature : BehavioralFeature.../ type : Classifier
0..1
n
+behavioralFeature
0..1
+parametern
{ordered}
Classifier
/+ feature : Feature/+ powertypeRange : Generalization
n
0..1+feature
n{ordered} +owner
0..1
n
1
+typedFeature
n
+type 1
n
1
+typedParametern
+type
1
April 2003 HL7 Development Framework Tutorial 25
UML Metamodel - Foundation Core
GeneralizableElement
isRoot : BooleanisLeaf : BooleanisAbstract : Boolean/ generalization : Generalization...
Attribute
initialValue : Expression/ associationEnd : AssociationEnd...
Method
body : ProcedureExpression.../ specification : Operation
Operation
concurrency : CallConcurrencyKindisRoot : BooleanisLeaf : BooleanisAbstract : Booleanspecification : String
n1
+method
n
+specification
1
Namespace
/ ownedElement : ModelElement...
Constraint
body : BooleanExpression/ constrainedElement : ModelElement...
ModelElement
name : Namevisibility : VisibilityKindisSpecification : Boolean/ namespace : Namespace/ clientDependency : Dependency/ constraint : Constraint/ targetFlow : Flow/ sourceFlow : Flow/ comment : Comment/ templateParameter : TemplateParameter......
0..1
n
+namespace0..1
+ownedElement n
n
*
+constraintn
+constrainedElement
* {ordered}
BehavioralFeature
isQuery : Boolean/ parameter : Parameter...
Feature
ownerScope : ScopeKind.../ owner : Classifier
StructuralFeature
multiplicity : Multiplicitychangeability : ChangeableKind...targetScope : ScopeKind...
<<metaclass>>
Parameter
defaultValue : Expressionkind : ParameterDirectionKind/ behavioralFeature : BehavioralFeature.../ type : Classifier
0..1
n
+behavioralFeature
0..1
+parametern
{ordered}
Classifier
/+ feature : Feature/+ powertypeRange : Generalization
n
0..1+feature
n{ordered} +owner
0..1
n
1
+typedFeature
n
+type 1
n
1
+typedParametern
+type
1
• Models contain Model Elements including the generalizable element “Classifier”.
• Classifiers have structuraland behavioral Features such as attributes, operations, and methods.
• Models contain Model Elements including the generalizable element “Classifier”.
• Classifiers have structuraland behavioral Features such as attributes, operations, and methods.
April 2003 HL7 Development Framework Tutorial 26
UML Metamodel – Model Management
GeneralizableElement(from Core)
Subsystem
isInstantiable : BooleanModel
Classifier(from Core)
Namespace(from Core)
ModelElement(from Core)
n
0..1
+ownedElement
n
+namespace
0..1
Package
/ elementImport : ElementImport
ElementImport
visibility : VisibilityKindalias : NameisSpecification : Boolean/ package : Package/ importedElement : ModelElement
1
*
+importedElement
1
+elementImport*
1
*
+package
1
+elementImport*
April 2003 HL7 Development Framework Tutorial 27
UML Metamodel – Model Management
GeneralizableElement(from Core)
Subsystem
isInstantiable : BooleanModel
Classifier(from Core)
Namespace(from Core)
ModelElement(from Core)
n
0..1
+ownedElement
n
+namespace
0..1
Package
/ elementImport : ElementImport
ElementImport
visibility : VisibilityKindalias : NameisSpecification : Boolean/ package : Package/ importedElement : ModelElement
1
*
+importedElement
1
+elementImport*
1
*
+package
1
+elementImport*
• 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.
• 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.
April 2003 HL7 Development Framework Tutorial 28
UML Metamodel – Common Behaviors
DestroyAction
UninterpretedAction
ModelElement(from Core)
CreateAction
/ instantiation : Classifier
Classifier(from Core)
*
1
+createAction *
+instantiation1
ReturnAction
TerminateActionCallAction
/ operation : Operation
Operation(from Core)
n
1
+callAction n
+operation 1
SendAction
/ signal : Signal
Signal
n
1
+sendActionn
+signal1
Argument
value : Expression/ action : Action
ActionSequence
/ action : Action
Action
recurrence : IterationExpressiontarget : ObjectSetExpressionisAsynchronous : Booleanscript : ActionExpression/ actualArgument : Argument/ actionSequence : ActionSequence
n
0..1
+actualArgumentn{ordered}
+action0..1
0..1 *
+actionSequence
0..1
+action
*{ordered}
April 2003 HL7 Development Framework Tutorial 29
UML Metamodel – Common Behaviors
DestroyAction
UninterpretedAction
ModelElement(from Core)
CreateAction
/ instantiation : Classifier
Classifier(from Core)
*
1
+createAction *
+instantiation1
ReturnAction
TerminateActionCallAction
/ operation : Operation
Operation(from Core)
n
1
+callAction n
+operation 1
SendAction
/ signal : Signal
Signal
n
1
+sendActionn
+signal1
Argument
value : Expression/ action : Action
ActionSequence
/ action : Action
Action
recurrence : IterationExpressiontarget : ObjectSetExpressionisAsynchronous : Booleanscript : ActionExpression/ actualArgument : Argument/ actionSequence : ActionSequence
n
0..1
+actualArgumentn{ordered}
+action0..1
0..1 *
+actionSequence
0..1
+action
*{ordered}
• UML Behavioral specificationsinclude a sequence of Actionswith an ordered set of Arguments.
• UML Actions include create, call, return, send, terminate, destroy, and uninterpreted actions.
• UML Behavioral specificationsinclude a sequence of Actionswith an ordered set of Arguments.
• UML Actions include create, call, return, send, terminate, destroy, and uninterpreted actions.
April 2003 HL7 Development Framework Tutorial 30
UML Metamodel - Extension Mechanisms
GeneralizableElement(from Core)
Stereotype
icon : GeometrybaseClass : Name/ definedTag : TagDefinition/ stereotypeConstraint : Constraint
Constraint(from Core)
0..1
n
+constrainedStereotype
0..1
+stereotypeConstraint n
TagDefinition
tagType : Namemultiplicity : Multiplicity/ owner : Stereotypen0..1
+definedTag
n
+owner
0..1
ModelElement(from Core)
*
n
+stereotype*
+extendedElement
n
*
n
+constrainedElement *
{ordered}
+constraint n TaggedValue
dataValue : String/ modelElement : ModelElement/ type : TagDefinition/ referenceValue : ModelElement...
1
*
+type
1
+typedValue*
1
n
+modelElement
1
+taggedValuen
*
*
+referenceValue*
+referenceTag *
April 2003 HL7 Development Framework Tutorial 31
UML Metamodel - Extension Mechanisms
GeneralizableElement(from Core)
Stereotype
icon : GeometrybaseClass : Name/ definedTag : TagDefinition/ stereotypeConstraint : Constraint
Constraint(from Core)
0..1
n
+constrainedStereotype
0..1
+stereotypeConstraint n
TagDefinition
tagType : Namemultiplicity : Multiplicity/ owner : Stereotypen0..1
+definedTag
n
+owner
0..1
ModelElement(from Core)
*
n
+stereotype*
+extendedElement
n
*
n
+constrainedElement *
{ordered}
+constraint n TaggedValue
dataValue : String/ modelElement : ModelElement/ type : TagDefinition/ referenceValue : ModelElement...
1
*
+type
1
+typedValue*
1
n
+modelElement
1
+taggedValuen
*
*
+referenceValue*
+referenceTag *• The UML Metatmodel is
extended by using:
• Stereotypes• Tag Definition• Constraints• Tagged Values.
• The UML Metatmodel isextended by using:
• Stereotypes• Tag Definition• Constraints• Tagged Values.
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 33
HL7 Development Framework
Metamodel
April 2003 HL7 Development Framework Tutorial 34
HDF Metamodel Development
MDF Metamodelv1.16
UML Metamodelv1.4
Compare the MDFMetamodel to the UML
MetamodelMDF to UML Comparision
Construct the HDFMetamodel and Profile
Specification
Proposed revisions to thevocabulary portion of the
MDF metamodel
HDF MetamodelSpecification
HDF Metamodel UMLProfile Specification
April 2003 HL7 Development Framework Tutorial 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).
April 2003 HL7 Development Framework Tutorial 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
Model Identification and Scope
Use Case Model
Interaction Model
Reference Information_model
Information Model
(from Reference Information_model)
Vocabulary Domain Model
(from Reference Information_model)Datatype Model
(from Reference Information_model)
Message Specification Model
Design Information Model
(from Message Specification Model)Hierarchical Message Description
(from Message Specification Model)
Application_roles
(from Interaction Model)
Interactions
(from Interaction Model)
April 2003 HL7 Development Framework Tutorial 37
Packages of the UML Metamodel
• Foundation
Core
Datatypes
Extension Mechanisims
• Behavioral Elements
Common Behavior
Collaborations
State Machines
Activity Graphs
Use Cases
• Model Management
Foundation
Core
(from Foundation)
Data_Types
(from Foundation)
Extension Mechanisms
(from Foundation)
Behavioral_Elements
Common_Behavior
(from Behavioral_Elements)
Collaborations
(from Behavioral_Elements)
State_Machines
(from Behavioral_Elements)
Use_Cases
(from Behavioral_Elements)
Activity_Graphs
(from Behavioral_Elements)
Model_Management
April 2003 HL7 Development Framework Tutorial 38
Mapping of the MDF to UML
MDF Metamodel Package UML Metamodel Package
Model Identification and Scope Model Management
Use Case Model Use Cases
Information Model Core
Vocabulary Domain Model Datatype
Datatype Model Datatype
Design Information Model Core
Hierarchal Message Description Core
Application Roles Collaborations
Interactions Collaborations
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 40
MDF: Model Identification and Scope
Project
ANSI_PINS_date : Dateid : IdentifierStringname : NameStringscope : DescriptiveTextTSC_approval_date : Date
Model
description : DescriptiveTextdeveloping_org : Stringlast_modified_date : DatemodelID : NameStringname : NameStringversion_number : VersionNumber
HL7_committee
facilitator : Stringid : IdentifierStringmission : DescriptiveTextname : String
1
0..*
prepares1
prepared_by
0..*
10..*
responsible_for
1
responsibility_of
0..*
April 2003 HL7 Development Framework Tutorial 41
UML Metamodel – Model Management
GeneralizableElement(from Core)
Subsystem
isInstantiable : BooleanModel
Classifier(from Core)
Namespace(from Core)
ModelElement(from Core)
n
0..1
+ownedElement
n
+namespace
0..1
Package
/ elementImport : ElementImport
ElementImport
visibility : VisibilityKindalias : NameisSpecification : Boolean/ package : Package/ importedElement : ModelElement
1
*
+importedElement
1
+elementImport*
1
*
+package
1
+elementImport*
April 2003 HL7 Development Framework Tutorial 42
HDF: Model Management
Package
/+ elementImport : ElementImport
(from Model_Management)
<<metaclass>>
GeneralizableElement
+ isRoot : Boolean+ isLeaf : Boolean+ isAbstract : Boolean<<reference>> /+ generalization : Generalization
(from Core)
ModelElement
+ name : Name+ visibility : VisibilityKind+ isSpecification : Boolean<<reference>> /+ namespace : Namespace<<reference>> /+ clientDependency : Dependency<<reference>> /+ constraint : Constraint<<reference>> /+ targetFlow : Flow<<reference>> /+ sourceFlow : Flow<<reference>> /+ comment : Comment<<reference>> /+ templateParameter : TemplateParameter<<reference>> /+ stereotype : Stereotype<<reference>> /+ taggedValue : TaggedValue
(from Core)
Namespace
<<reference>> /+ ownedElement : ModelElement
(from Core)
n
0..1
+ownedElementn
+namespace0..1
HL7 Package
<<taggedValue>> - developingOrganization : String<<taggedValue>> - lastModifiedDate : Date<<taggedValue>> - responsibleCommitteeID : String<<taggedValue>> - versionNumber : String
<<stereotype>>
Element(from Core)
HL7 ModelElement
<<taggedValue>> - descriptiveText : String<<taggedValue>> - history : String<<taggedValue>> - identifier : String
<<stereotype>>
History and Identifier are needed for internal model management functions. They are not visable to the modeler. They may need to be included in XMI exports.
HL7Vocabulary<<stereotype>>
HL7UsageContext<<stereotype>>
HL7DIM<<stereotype>>
HL7RIM<<stereotype>>
HL7InformationModel<<stereotype>>
HL7HMD<<stereotype>>
HL7DatatypePackage<<stereotype>>
Model(from Model_Management)
<<metaclass>>
HL7 Model<<stereotype>>
Extensions to the UML Metamodel
April 2003 HL7 Development Framework Tutorial 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.
HL7 Stereotypes Stereotype Name Base Class Parent Tags Constraints
lastModifiedDate
versionNumber
responsibleCommitteeID
HL7Package Package N/A
developingOrganization
There is no case that HL7 package should be applied to a package element. Package is a UML element an d therefore it is prefixed with HL7
Tag Definitions Tag Stereotype Type Multiplicity Description
lastModifiedDate HL7Package String 1..1 The date the package was last modified by the model developing organization.
April 2003 HL7 Development Framework Tutorial 44
UML Metamodel - Extension Mechanisms
GeneralizableElement(from Core)
Stereotype
icon : GeometrybaseClass : Name/ definedTag : TagDefinition/ stereotypeConstraint : Constraint
Constraint(from Core)
0..1
n
+constrainedStereotype
0..1
+stereotypeConstraint n
TagDefinition
tagType : Namemultiplicity : Multiplicity/ owner : Stereotypen0..1
+definedTag
n
+owner
0..1
ModelElement(from Core)
*
n
+stereotype*
+extendedElement
n
*
n
+constrainedElement *
{ordered}
+constraint n TaggedValue
dataValue : String/ modelElement : ModelElement/ type : TagDefinition/ referenceValue : ModelElement...
1
*
+type
1
+typedValue*
1
n
+modelElement
1
+taggedValuen
*
*
+referenceValue*
+referenceTag *
April 2003 HL7 Development Framework Tutorial 45
Stereotypes in the HL7 Profile
• Clone
• CodedValue
• CodeSet
• DataTypes
• DIM
• HL7Attribute
• HL7DataType
• HL7Model
• HL7ModelElement
• HL7Package
• RegisteredCodeSystem
• RIM
• UsageContext
• Vocabulary
• VocabularyDomain
April 2003 HL7 Development Framework Tutorial 46
HDF UML Profile Stereotype Specifications
Stereotype Name Base Class Parent Tags Constraints
lastModifiedDate
versionNumber
responsibleCommitteeID
developingOrganization
RIM Package HL7Package
Must have a «prototypes» dependency on one or more DIM or RIM packagesAll classes within the package must be stereotyped as CloneReferences to classes in other packages are not restricted.
HL7Model Model HL7Package
includedVersionHistory
excludedVersionHistory
universalID
predecessorUniversalID
structuredSortName
namingStatus
processingNotation
versionReferenceNotation
designCommentNotation
walkThroughNotation
cueNotation
descriptiveTextThis will be replaced by documentation
The prototypes package is the package on which the DIM package has a «prototypes» dependency.The baseClass is a class in the prototypes package for which the class package has a with same name as the Clone class tagged baseClassName value.The attributes must be a subset of attributes of the prototype.The associations must be a subset of associations of the prototype.The cardinality of a class associations must be more restricted than those of the prototype.The types of attributes must be the same or a specialization of those in the prototype
fixedName The tagged values of the class must be those of the prototype plus the baseClassName.
typeCode
sequence
vocabularyStrength
isStateAttribute
isStructuralAttribute
DataTypes Package HL7Package The name of the package is HL7DataType or the package is a subpackage of HL7DataType
An HL7DataType may have attributes which are stereotyped HL7DataType or are UML DataTypeAn HL7DataType may not have navigable associations.
Vocabulary Package HL7Package
UsageContext Package HL7Package
VocabularyDomain Class HL7DataType Must have an association with ate least one HL7CodeSet and must inherit from the ConceptDescriptor class in the HL7Datatype
CodeSet Class A specific CodeSet is declared in the vocabulary package.
RegisteredCodeSystem Class
designation
isActive
CodedValue EnumeratedLiteral
HL7DataType Classifier HL7ModelElement
HL7Attribute Attribute N/A Constraint applied by the HL7Class stereotype - attributes of an HL7Class must have this tagged value if the typeCode is "CD"
Clone Class HL7ModelElement baseClassName
HL7ModelElement ModelElement N/A
DIM Package HL7Package
HL7Package Package N/A There is no case that HL7 package should be applied to a package element. Package is a UML element an d therefore it is prefixed with HL7
April 2003 HL7 Development Framework Tutorial 47
HDF UML Profile Tag Value Specifications
Tag Stereotype Type Multiplicity Description
lastModifiedDate HL7Package String 1..1 The date the package was last modified by the model developing organization.
versionNumber HL7Package String 1..1 A number showing the release level of the package. The version number, in combination with the name, shall be unique for all public releases of the model.
responsibleCommitteeID HL7Package String 1..1 Links a package to the committee that prepared it.
developingOrganization HL7Package String 1..1 A short form identifier of the organization responsible for the publication and maintenance of the model. . For HL7, this name shall be "HL7."
includedVersionHistory HL7ModelElement String 1..1 Represents the first version of the model in which the model element, as defined, was included.
excludedVersionHistory HL7ModelElement String 0..1 Represents the first version of the model in which the model element, as defined, ceased to be included or valid. (If this value is missing or null, then the element is valid in the current version of the model.)
universalID HL7ModelElement String 1..1 A string representation of the Universally Unique Identifier (UUID) or Globally Unique Identifier (GUID) assigned to this model element.
predecessorUniversalID HL7ModelElement String 0..1 A string representation of the UUID assigned to the model element's predecessor element. A predecessor is usually of the same type as the model element and represents a prior 'version.' A model may not have a predecessor
structuredSortName HL7ModelElement String 0..1 A name, other than the element name that can be processed by a formal sort algorithm to yield a sort sequence other than alphabetic. These need not be unique within the model, because the sort algorithm will use the element name as the final arbiter.
namingStatus HL7ModelElement String 0..1 Since the name for certain elements are algorithmically generated, while those for others are user-determined, it is necessary to document the status (source) of the name for many message elements. The current set of values is: ALGO (algrithmically determined), CMET (HL7-defined by CMET task group), DMIM (name assigned in context of a superior DIM) , NEW (trial name for a newly created clone), OPEN (open to change), USER (user assigned)
processingNotation HL7ModelElement String 0..1 Textual representation of a processing rule for inclusion in an XML schema - should be part of an ITS profile
versionReferenceNotation HL7ModelElement String 0..1 A textual discussion of the reference between this element to prior version standards (2.x) of HL7.
designCommentNotation HL7ModelElement String 0..1 Notation about the design basis or rational for an element.
walkThroughNotation HL7ModelElement String 0..1 A notation, usually at the model (DIM) level that provides a textual explanation of the model by verbally walking through its diagram.
cueNotation HL7ModelElement String 0..1 A notation for display to the implementer that provides a cue as to the usage of an element; an aide memoire
baseClassName Clone String 0..1 Reference to the class from the prototype package from which this class is cloned (replaces Class_cd). If the baseClassName is not unique between the prototype packages, then fully qualified namespace must be used.
fixedName Clone String 0..1 Each clone is assigned a fixed unique name that is not changed when the formal naming algorithm is applied to create a new name for that clone. The fixed name provides for cross-reference between two diagrams where re-naming or user-naming has altered the diagrammed names for one or more clones. Although this may, in some cases be implemented as a defined connection between the two clones, these links may prove fragile, and the provision of a defined unique tag is useful.
typeCode HL7Attribute AttributeTypeKind 1..1 An indication of the form of the attribute, and of its usage. The use of attribute type words in attribute names aids in creating uniformity in the names, helps to avoid unintentional redundancy, and adds clarity to the model.
sequence HL7Attribute Integer 1..1 Identifies the relative sort order of the attribute within the containing class. Lower numbers appear first. In the circumstance where two attributes within a class have the same number, sorting will occur based on alphabetically ascending attribute name.
vocabularyStrength HL7Attribute VocabularyStrengthKind 0..1 The strength is either CWE (coded with exceptions) or CNE (coded, no exceptions). If no value is given, CWE is the default.
isStateAttribute HL7Attribute Boolean 1..1 The state attribute of a class contains a value indicating the current state of the class. In the event that the class has concurrent states, the attribute must be a set of state values.
An attribute of a Class that provides a linkage between that Class and the Concepts (codes) that are used to further define or qualify the class's function within the model and/or to extend the class’s generalization hierarchy.The structural attribute must have a coded data type, and the allowable set of code values is limited to those that have been formally adopted by HL7.
designation EnumeratedLiteral String 1..1 Description of the Code
isActive EnumeratedLiteral String 1..1 Indicates whether the Enumerated Literal is an active member of the Enumeration
isStructuralAttribute HL7Attribute Boolean 1..1
April 2003 HL7 Development Framework Tutorial 48
HDF Metamodel
UML Metamod
el v1.4
HDF UML Profilev1.0
HDF Metamodel v1.0
HDF Metamodel = UML Metamodel + HDF UML Profile
April 2003 HL7 Development Framework Tutorial 49
HDF Model Interchange
Format
April 2003 HL7 Development Framework Tutorial 50
Model Interchange Requirements
Model RepositoryDesign Database / Publication Database
Model RepositoryDesign Database / Publication Database
RationalRose
RationalRose
RoseTreeRoseTree
RMIMDesigner
RMIMDesigner
SchemaGeneratorSchema
Generator
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 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, . . .
April 2003 HL7 Development Framework Tutorial 54
Session I Review
• HL7 Development Framework Project
• Unified Modeling Language Metamodel
• HDF UML Profile and Metamodel
• HDF Model Interchange Format
April 2003 HL7 Development Framework Tutorial 55
Cookie Break – 30 Minutes
April 2003 HL7 Development Framework Tutorial 56
Session II Overview
• HL7 Message Development Framework
• HDF Development Methodology
• HDF Pilot Projects
• HDF Developer’s Guide
• HDF Transition Planning
April 2003 HL7 Development Framework Tutorial 57
HL7 Message Development
Framework
April 2003 HL7 Development Framework Tutorial 58
The MDF Methodology Overview
April 2003 HL7 Development Framework Tutorial 59
Use Case ModelUse Case ModelUse Case ModelUse Case Model
Use Case Diagram
Spec
UCM SpecAssociate Actors and Use Cases
Develop Scope
Identify actors and Use Cases
MDF Models and Process Flow
Message DesignMessage DesignMessage DesignMessage Design
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
h//mt:50”d”………
h//mt:50”d”………
Develop Refined Message Information Model (RMIM)
Specify HMD & METs with constraints
Specify CMET
Information ModelInformation ModelInformation ModelInformation Model
State DiagramClass Diagram Define vocabulary domains and codesDefine states, transitions and triggers
Define classes, attributes, and relationships
Spec
RIM Spec
Interaction ModelInteraction ModelInteraction ModelInteraction Model
Interaction Diagram
Define Application Roles
DefineInteractions
Define Conformance Criteria
Spec
Inter Spec
Story
board
April 2003 HL7 Development Framework Tutorial 60
HL7 V3 Conceptual Model
Exam ple
Restrict
Restrict
Restrict
RIM
D-MIM
R-MIM
HMD
MessageType
Storyboard
StoryboardExample
ApplicationRole
TriggerEvent
Interaction
Instantiate
Sender Receiver
Triggers
Content
References
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 62
Simplified MDF Metamodel
Example
Restrict
Restrict
Restrict
RIM
D-MIM
R-MIM
HMD
MessageType
Storyboard
StoryboardExample
ApplicationRole
TriggerEvent
Interaction
Instantiate
Sender Receiver
Triggers
Content
References
Use Case Modeling
Information Modeling
Interaction Modeling
Message Design
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 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?
April 2003 HL7 Development Framework Tutorial 65
HL7 Development Framework
Methodology
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 68
The HDF Methodology WorkflowProject Initiationand Management
RequirementsGathering and
Analysis
RequirementsNormalization
andHarnonization
SpecificationDesign andPackaging
SpecificationImplementationand Validation
SpecificationRefinement and
Localization
SpecificationPublication and
Balloting
RequirementsSpecification
Project Charter
ReferenceModel
DesignModel
StandardSpecification
TemplateSpecification
ImplementationProfile
ConformanceSpecification
April 2003 HL7 Development Framework Tutorial 69
Eight Work Products of the HDF Methodology
• Project Charter
• Requirements Specification
• Reference Model
• Design Model
• Standard Specification
• Template Specification
• Implementation Profile
• Conformance Specification
April 2003 HL7 Development Framework Tutorial 70
HDF Development Methodology Reference Manual Core Chapters
1. Project initiation and management
• Jane Curry
2. Requirements gathering and analysis
• Charlie Mead
3. Requirements normalization and harmonization
• Abdul-Malik Shakir
4. Specification design and packaging
• Abdul-Malik Shakir
5. Specification publication and balloting
• Karen VanHentenryck
6. Specification refinement and localization
• Jenny Puyenbroek
7. Specification implementation and validation
• Jenny Puyenbroek
April 2003 HL7 Development Framework Tutorial 71
Project Initiation
Project Initiationand Management
Project Charter
• 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
April 2003 HL7 Development Framework Tutorial 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?
April 2003 HL7 Development Framework Tutorial 73
Requirements Gathering and Analysis
RequirementsGathering and
Analysis
RequirementsSpecification
Project Charter• 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.
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 75
Requirements Normalization and Harmonization
RequirementsNormalization
andHarnonization
RequirementsSpecification
ReferenceModel
• 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.
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 77
Specification Design and Packaging
SpecificationDesign andPackaging
RequirementsSpecification
ReferenceModel
DesignModel
• 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.
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 79
Specification Publication and Balloting
SpecificationPublication and
BallotingReferenceModel
DesignModel
StandardSpecification
• 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).
April 2003 HL7 Development Framework Tutorial 80
Committee and Member Level Ballot
• Committee Level Ballot
Announcing your committee’s 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 Chair’s authorization to submit your content for membership ballot
Announcing your committee’s 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
April 2003 HL7 Development Framework Tutorial 81
Specification Refinement and Localization
SpecificationRefinement and
Localization
StandardSpecification
TemplateSpecification
• 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.
April 2003 HL7 Development Framework Tutorial 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.
April 2003 HL7 Development Framework Tutorial 83
Specification Implementation and Validation
SpecificationImplementationand Validation
StandardSpecification
TemplateSpecification
ImplementationProfile
ConformanceSpecification
• 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.
April 2003 HL7 Development Framework Tutorial 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 developer’s 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.
April 2003 HL7 Development Framework Tutorial 85
The HDF Methodology OverviewProject Initiationand Management
RequirementsGathering and
Analysis
RequirementsNormalization
andHarnonization
SpecificationDesign andPackaging
SpecificationImplementationand Validation
SpecificationRefinement and
Localization
SpecificationPublication and
Balloting
RequirementsSpecification
Project Charter
ReferenceModel
DesignModel
StandardSpecification
TemplateSpecification
ImplementationProfile
ConformanceSpecification
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 87
HDFPilot Projects
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 89
HDFDeveloper’s Guide
April 2003 HL7 Development Framework Tutorial 90
Developer’s Guide
• The HDF Developer’s Guide is one of many anticipated companion documents of the HDF Development Methodology Reference Manual
• Content of the HDF Developer’s Guide:
Initiation thru Design ~ Charlie Mead
Design thru Implementation ~ Jennifer Puyenbroek
Tools and Techniques ~ Woody Beeler
• HDF Developer’s Guide Activities
06/23/03 ~ 10/24/03 – Prepare the HDF Developer’s Guide
10/27/03 ~ 12/05/03 – Publish the HDF Developer’s Guide
April 2003 HL7 Development Framework Tutorial 91
HDFTransition Planning
April 2003 HL7 Development Framework Tutorial 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
April 2003 HL7 Development Framework Tutorial 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 Developer’s Guide HDF Transition Planning
April 2003 HL7 Development Framework Tutorial 94
Thank You
Abdul-Malik ShakirPrincipal Consultant
Shakir Consulting1911 Foothill Blvd., Suite 148
La Verne, CA 91750
Office: (909) 596-6790 Mobile: (626) 644-4491
Email: [email protected]
Top Related