hl7 development framework tutorial abdul-malik shakir principal consultant, shakir consulting...

HL7 Development Framework TutorialHL7 Development Framework Tutorial

Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting

October 1, 2002

October 1, 2002 HL7 Development Framework Tutorial 2

Session Overview

• HL7 Development Framework Project Project Introduction Project Background Project Scope and Objectives Project Accomplishments Project Next Steps

• HL7 Development Framework Metamodel UML 2.0 Metamodel UML Metamodel Extension Mechanisms HL7 MDF Metamodel HDF Metamodel and Profile

• HL7 Development Framework Methodology MDF Methodology HDF Methodology


My HL7 Background

Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting, La Verne, CA

HL7 Member since 1991

• Member of the HL7 Board of Directors

• Appointed Chair of the HL7 Education and Implementation Committee

• Member of the HL7 Architectural Review Board

• Co-Chair of the HL7 Modeling and Methodology Technical Committee

• Project Manager for the HL7 Development Framework Project


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 mapping to the UML metamodel

• To introduce the HDF methodology and its relationship to the MDF methodology

• To encourage your participation in designing and developing the HDF methodology.


HL7 Development Framework Project

Project Introduction Project Background Project Scope and Objectives Project Accomplishment Project Next Steps


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 standards specifications.

• The HL7 Development Framework (HDF) project will enable HL7 to:

Maximize the benefits it derives from using the Unified Modeling Language (UML) as a foundation for its model-based approach to standards development;

Expand application of its 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;

Facilitate the participation of HL7 members, subject matter experts, and implementers in the development of HL7 standards.

• The HDF project is sponsored by Health Level Seven, Inc. with partial funding from the Veterans Health Administration (VHA).

• Project management is provided by Shakir Consulting.


Project Background – Health Level Seven

• Health Level Seven (HL7) is an American National Standards Institute (ANSI) Accredited Standards Developer.

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

• The standard provides the layout of messages that are exchanged between two or more applications based upon a particular trigger event.

• It specifies which data elements are to be sent, the data type and suggested length of each element, and indicates whether the data element is required or optional and whether it may repeat.


Project Background – HL7 Standards

• In the years since its founding, HL7 has evolved beyond traditional messaging protocols.

• Today HL7 standards development initiatives include:

standardization of knowledge representation (Arden Syntax);

specification of components for context management (known as CCOW);

support for healthcare data interchange using object request brokers;

standardization of clinical document structures;

specification of robust vocabulary definitions for use in clinical messages and documents; and

work in the area of security, privacy, confidentiality, and accountability.

• In 2001 HL7 modified it mission statement to specifically include standards, guidelines, methodologies, and related services for the management of electronic health records.


Project Background – HL7 V3 Methodology

• In 1992 HL7 made a fundamental shift in the methodology it uses to develop its standards specifications.

• The new methodology, referred to as HL7 Version 3.0 (or V3), is a model-driven methodology based upon modern object-oriented software development practices.

• HL7 spent four years creating the methodology that adapts modern analysis techniques from system building to message design.

• Initially the HL7 Executive Committee chartered an independent task force to establish the broad outline of the approach.

• In January 1996, the Technical Steering Committee agreed to adopt the main features of the approach and take over its management.

• Planning work continued in the Modeling and Methodology Technical Committee.

• In the spring of 1997, all the HL7 Technical Committees began to use the V3 process.


Project Background – HL7 V3 Messaging Standard

• Balloting on an initial set of V3 message specifications began in August 2001.

• This first set of V3 messages provide comprehensive coverage of patient administration, laboratory and pharmacy orders, medical records management, and initial proposals for scheduling.

• A new set of electronic claims messages support a contingent of HL7 international affiliates now working on creating financial transactions to support an e-claims submission process.

• The HL7 Version 3.0 development methodology is a continuously evolving process that seeks to develop specifications that facilitate interoperability between healthcare systems.

• The HL7 Reference Information Model (RIM), vocabulary specifications, and model-driven process of analysis and design combine to make HL7 Version 3.0 an exemplary methodology for development of consensus-based standards for healthcare information system interoperability.


Project Background – Unified Modeling Language

• The models used in the HL7 V3 process are based upon the Unified Modeling Language (UML).

• The UML is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.

• The 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).


Project Background – UML v2.0

• The current version of the UML specification (v1.4) was published in September 2001.

• Under the stewardship of the OMG, the UML has emerged as the software industry’s dominant modeling language.

• It has been successfully applied to a wide range of domains, ranging from health and finance to aerospace.

• Its extensive use has raised numerous application and implementation issues by modelers and vendors.

• Over 500 formal usage and implementation issues have been submitted to the OMG for consideration.

• Many of the issues have been resolved in minor revisions by the OMG UML Revision Task Force.

• Other issues require major changes to the language; consequently, the OMG has issued RFPs to define UML 2.0.


Project Background – XMI and MOF

• The UML is part of OMG’s catalog of modeling specifications. Other OMG modeling specifications with relevance to the HDF project include the XML Meta-Data Interchange (XMI) and the Meta-Object Facility (MOF) specifications.

• XMI is a specification enabling easy interchange of metadata between modeling tools and metadata repositories in distributed heterogeneous environments.

• The OMG XMI specification leverages XML (eXtensible Markup Language) technology to support the interchange of meta-data and meta-models between MOF-based meta-data repositories.

• The MOF is a set of standard interfaces used to define and manipulate a set of interoperable metamodels and their corresponding models. It provides a framework that supports the management of metadata.

• The MOF is based upon a four layer meta-modeling architecture. The key feature of this architecture is a meta-meta-modeling layer which provides a common language that defines the meta-models.


Project Background – HL7 MDF

• The HL7 Message Development Framework (MDF) defines the HL7 V3 model-based process of message development.

• It identifies the phases, activities, and models used in the process of developing HL7 message specifications.

• It also includes a meta-model specification of the Reference Model Repository (RMR) used to store and manage the artifacts produced during the message development process.

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

• The HL7 Message Development Framework will be superceded by the HL7 Development Framework, the HDF.


Project Background – HL7 MDF Process Model


Project Background – HL7 Development Framework

• The HL7 Development Framework (HDF) is a replacement for and an extension to the HL7 Message Development Framework (MDF).

• The HDF differs from the MDF in terms of:

Scope of Coverage

Alignment with UML

Maintenance/versioning Procedures

• Companion documents to the HDF are:

The HDF Metamodel Specification

The HDF Practical Guide


Project Scope and Objectives

• Project Scope:

Develop and publish the HDF Metamodel

Develop and publish the initial version of the HDF

Develop a preliminary draft of the HDF Practical Guide

• Project Objectives:

Maximize the benefits HL7 derives from using UML as a foundation for its model-based approach to standards development.

Expand the modeled-based approach for standards development beyond the HL7 messaging standard.

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.


HDF Project Accomplishments

• Project Administration Project initiation

Project Planning

Project monitoring and status reporting

• HDF Metamodel Collect Relevant Metamodel Documentation

Compare MDF and UML Metamodels

Prepare HDF Metamodel and UML Profile

• HDF Methodology Identified HDF Methodology Lifecycle

Identified HDF Methodology Deliverables

Began preparation of the HDF Methodology Specification

• HDF Practical Guide Prepared HDF Tutorial

Began preparation of the HDF Practical Guide Document


HDF Project Next Steps

• Project Administration Phase II Project initiation

Phase II Project Planning

• HDF Metamodel Peer review of the HDF Metamodel specification

Consideration of the UML v2.0 proposal

Examination of the HDF Metamodel tooling implications

• HDF Methodology Completion of v1.0 of the HDF Methodology Specification

Peer review of the HDF Methodology Specification

Consideration of the UN/CEFACT Unified Modeling Methodology

• HDF Practical Guide Examination of the HDF Methodology education and training implications

Completion of v1.0 of the HDF Practical Guide Document

Peer review of the HDF Practical Guide Document


Questions

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]


HL7 Development Framework Metamodel

UML 2.0 Metamodel UML Metamodel Extension Mechanisms

----- Cookie Break -----

HL7 MDF Metamodel HDF Metamodel and Profile


Four Layer Meta-data Architecture

• M0: The user object layer

The user object layer is comprised of the information to be described. This information is typically referred to as “data.”

• M1: The model layer

The model layer is comprised of the meta-data that describes information in the user object layer.

• M2: The meta-model layer

The meta-model layer is comprised of the descriptions (i.e., meta-meta-data) that define the structure and semantics of meta-data. It is the “language” used in the construction of models.

• M3: The meta-meta-model layer

The meta-meta-model layer is comprised of the description of the structure and semantics of meta-meta-data. In other words, it is the “language” used in the construction of meta-models.


One Person’s Model is the Next Person’s Metamodel

MOF UML HDFHL7

ModelHL7 Spec.

HL7Impl.

HealthData

M3 M2 M1 M0 Methodologist’s View

M3 M2 M1 M0 Standards Developer’sView

M3 M2 M1 M0 Implementer’sView

M3 M2 M1 M0 End-User’s View


Methodologist View

• M0: The HL7 Reference Information Model and Domain Specific Design Information Models are example of HL7 models.

• M1: The HDF Metamodel is a collection of model elements that describe the structure, semantics, and constraints of the elements in a well-formed HL7 model.

• M2: The UML Metamodel is a description of the structure, semantics, and constraints of elements in the HDF Metamodel.

• M3: MOF is a description of the structure, semantics, and constraints of elements in the UML Metamodel.


Standard Developer View

• M0: The HL7 v3.0 Laboratory Message Specification is an example of an HL7 standard specification

• M1: The HL7 Reference Information Model and Domain Specific Design Information Models are example of HL7 models. They describe the semantics and constraints of elements in an HL7 standard.

• M2: The HDF Metamodel is a collection of model elements that describe the structure, semantics, and constraints of the elements in a well-formed HL7 model.

• M3: The UML Metamodel is a description of the structure, semantics, and constraints of elements in the HDF Metamodel.


The HDF Metamodel

• This presentation of the HDF metamodel takes the methodologist view.

• The HDF metamodel defines the structure, semantics, and constraints for elements used in creating well-formed HL7 models.

• The content of the HDF metamodel is derived from the UML metamodel and takes advantage of the extension mechanisms defined by UML.

• The UML metamodel is the HDF’s meta-model. The meta-meta-model for HL7 models.

• Later in this presentation, when describing the HDF methodology, the perspective will shift to the standards developer’s view.

• In the standards developer’s view the HL7 models are the metamodels for well formed HL7 standard specifications and the HDF metamodel is the meta-meta-model.


UML Metamodel

• Foundation Core

Extension Mechanisms

Datatypes

• Behavior Elements Common Behavior

Collaborations

Use Cases

State Machines

Activity Graphs

• Model Management Package

Subsystem

Model


UML Metamodel Packages

Data_Types<<metamodel>>

(from Foundation)Core

<<metamodel>>

(from Foundation)

Common_Behavior<<metamodel>>

(from Behavioral_Elements)

Use_Cases<<metamodel>>


State_Machines<<metamodel>>


Collaborations<<metamodel>>


Activity_Graphs<<metamodel>>


Model_Management<<metamodel>>

Extension_Mechanism

(from Foundation)

<<metamodel>>


UML Metamodel - Core

Backbone

Classifiers

• Dependencies

Relationships

• Auxilary Elements


UML Metamodel – Core Backbone

Element

GeneralizableElement

isRoot : BooleanisLeaf : BooleanisAbstract : Boolean/ generalization :

Attribute

initialValue : Expression/ associationEnd :

Method

body : ProcedureExpression

Operation

concurrency : CallConcurrencyKind...isRoot : BooleanisLeaf : BooleanisAbstract : Booleanspecification : String

n1

+method

n

+specification

1

Namespace

/ ownedElement : ModelElement...

Constraint

body : BooleanExpression/ constrainedElement :

ModelElement

name : Namevisibility : VisibilityKindisSpecification : Boolean/ namespace : Namespace/ clientDependency : Dependency/ constraint : Constraint/ targetFlow : Flow/ sourceFlow : Flow/ comment : Comment/ templateParameter : ...

0..1

n

+namespace0..1

+ownedElement n

n

*

+constraintn

+constrainedElement

*{order...

BehavioralFeature

isQuery : Boolean/ parameter :

Feature

ownerScope : ScopeKind

StructuralFeature

multiplicity : Multiplicitychangeability : ChangeableKindtargetScope : ScopeKindordering : OrderingKind

Parameter

defaultValue : Expressionkind : ParameterDirectionKind/ behavioralFeature : BehavioralFeature

0..1

n

+behavioralFeature

0..1

+parametern

{order...

Classifier

/+ feature : Feature/+ powertypeRange : Generalization...

n

0..1+feature

n

{order...

+owner

0..1

n

1

+typedFeature

n

+type 1

n

1

+typedParametern

+type

1


UML Metamodel – Core ClassifiersClassifier

/ feature : Feature/ powertypeRange :

Class

isActive : Boolean...

DataType

Interface

Primitive

Enumeration

/ literal : EnumerationLiteral

EnumerationLiteral

/ enumeration : Enumeration1 1..*

+enumerat...

1

+lite...

1..*{order...

ProgrammingLanguageDataType

expression : TypeExpressionModelElement

Node

/ deployedComponent : Component...

ElementResidence

visibility : VisibilityKind/ resident : ModelElement

1

*

+resident1

+elementReside...*

ArtifactComponent

/ deploymentLocation : Node/ residentElement : ElementResidence

n

n

+deploymentLocat...n

+deployedCompon...n1

n

+container1

+residentElementn

** +implementat... *

+implementationLocat...

*


UML Metamodel – Core Relationship

AssociationClass

Class

isActive : Boolean

Relationship

Association

/ connection : AssociationEnd...

Attribute

initialValue : Expression/ associationEnd :

AssociationEnd

isNavigable : Booleanordering : OrderingKindaggregation : AggregationKindtargetScope : ScopeKindmultiplicity : Multiplicitychangeability : ChangeableKind/ association : Association/ qualifier : Attribute

2..*

1+connection

2..*

{order...

+association

1

n

0..1+qualifier

n{order... +associationEnd

0..1


isRoot : BooleanisLeaf : BooleanisAbstract : Boolean/ generalization :

Classifier

/ feature : Feature/ powertypeRange :

1 n

+participant

1

+association

nnn

+specifiedEndn

+specificationn

Generalization

discriminator : Name/ child : GeneralizableElement/ parent :

n 1

+generalization

n

+child

1

1n

+parent

1

+specialization

n

0..1

n

+powertype 0..1

+powertypeRangen

Flow

/ target : ModelElement

ModelElement

n

n

+sourceFlow

n

+source n

n

n

+targetFlow

n

+target n


UML Metamodel – Use Case

UseCaseInstance

Actor

Classifier(from Core)

Instance(from Common_Behav ior)

1..* *

+classifier

1..*

+instance

*

ModelElement(from Core)

Include

/ addition : UseCase

UseCase

/ extend : Extend/ include : Include/ extensionPoint :

n

1

+includer

n

+addition1

n

1

+includen

+base1

ExtensionPoint

location : LocationReference

n

1 +extensionPoint

n+useCase

1

Extend

condition : BooleanExpression/ base : UseCase/ extension : UseCase/ extensionPoint : ExtensionPoint

1

n

+base1

+extendern

1

n

+extension

1

+extendn

1..n

n

+extensionPoint 1..n{order...

n

Relationship(from Core)


UML Metamodel – State Machine

Pseudostate

kind : PseudostateKind...

SimpleState

SynchState

bound : UnlimitedInteger...

StubState

referenceState : Name...

FinalState

SubmachineState

/ submachine : StateMachine...


CompositeState

isConcurrent : Boolean/ subvertex :

Guard

expression : BooleanExpression

Event

/ parameter : Parameter...

Action(from Common_Behavior)...)

State

/ entry : Action/ exit : Action/ deferrableEvent : Event/ internalTransition : Transition/ doActivity : Action

0..n

0..n

0..n

+deferrableEvent

0..n

0..1

0..1

0..1 +entry

0..10..1

0..1

0..1 +exit

0..1

0..1

0..1

0..1 +doActivity

0..1

StateMachine

/ context : ModelElement/ top : State/ transitions : Transition/ submachineState :

1

0..1

+top1

+stateMachine 0..1

n

1

+submachineStaten

+submachine

1

n

0..1

+behavior n

+context0..1

StateVertex

/ container : CompositeState/ outgoing : Transition0..n

0..1

+subvertex

0..n

+container

0..1

Transition

/ guard : Guard/ effect : Action/ trigger : Event/ source : StateVertex/ target : StateVertex/ stateMachine :

1

0..1

+transition1

+guard0..1

0..1

n

+trigger 0..1

+transition

n

0..1

0..1

+effect0..1

+transition0..1n

0..1

+internalTransit... n

0..1

n

0..1

+transitions n

0..1

1 n

+source

1

+outgoing

n

1 n

+target

1

+incoming

n


UML Metamodel – Model Management

GeneralizableElement(from Core)

Subsystem

isInstantiable : Boolean...Model

Classifier(from Core)

Namespace(from Core)


n

0..1

+ownedElem...

n

+namespace

0..1

Package

/ elementImport : ElementImport

ElementImport

visibility : VisibilityKindalias : NameisSpecification : Boolean/ package : Package/ importedElement :

1

*

+importedElem...

1

+elementImp...*

1

*

+pack...

1

+elementImp...*


UML Metamodel - Extension Mechanisms

GeneralizableElement(from Core)

Stereotype

icon : GeometrybaseClass : Name/ definedTag : TagDefinition/ stereotypeConstraint :

Constraint(from Core)

0..1

n

+constrainedStereotype

0..1

+stereotypeConstraint n

TagDefinition

tagType : Namemultiplicity : Multiplicity/ owner : Stereotype

n0..1

+definedTag

n

+owner

0..1


*

n

+stereot...*

+extendedElement

n

*

n

+constrainedElement *

{ordered}

+constraint n TaggedValue

dataValue : String/ modelElement : ModelElement/ type : TagDefinition/ referenceValue : ModelElement

1

*

+type

1

+typedValue*

1

n

+modelElem...

1

+taggedValuen

*

*

+referenceValue*

+referenceTag *


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.


Cookie Break – 30 Minutes


HDF Development Process

MDF Metamodelv1.16

UML Metamodelv1.14

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


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.

• Proposed revisions to the Vocabulary model portion of the MDF metamodel are being developed by the Vocabulary Technical Committee.

• An preliminary version of the proposed vocabulary portion of the MDF metamodel was formally reviewed by the Modeling and Methodology Technical Committee in July 2002.

• The HDF Metamodel is base upon a comparison of the UML metamodel to v1.16 of the MDF metamodel ( including the proposed revisions to the vocabulary portion).


Packages of the HL7 MDF Metamodel

Model Identification and Scope

Use Case Model

Information Model

Datatype Model

Vocabulary Domain Model

Design Information Model

Hierarchical Message Description

• Interaction Model


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


HDF: Model Identification and Packaging

Package

/+ elementImport : ElementImport

(from Model_Management)

<<metaclass>>


+ 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>>


MDF: Use Case Model

Actor

description : DescriptiveTexthistory : CompoundHxname : NameString

Use_case_category

name : NameStringdescription : DescriptiveTexthistory : CompoundHx

1..1

0..*

nests

1..1

nested_in0..*

0..* 0..*

included_in

0..*

includes

0..*

Use_case_relationship

stereotype : Stringhistory : CompoundHx

Use_case

description : DescriptiveTexthistory : CompoundHxidentifier : IdentifierStringname : NameString

1..*

0..*

participates_in

1..*

involves

0..* 0..*

0..*

included_in0..*

includes0..*

0..*

1

links_target

0..*is_target_in

1

0..*1links_source

0..*

is_source_for

1


HDF: Use Case Model

Actor(from Use_Cases)



(from Core)

ModelElement


(from Core)

Namespace


(from Core)

n

0..1

+ownedElementn

+namespace

0..1

Include

<<reference>> /+ addition : UseCase<<reference>> /+ base : UseCase

(from Use_Cases)

Extend

+ condition : BooleanExpression<<reference>> /+ base : UseCase<<reference>> /+ extension : UseCase<<reference>> /+ extensionPoint : ExtensionPoint

(from Use_Cases)

UseCase

<<reference>> /+ extend : Extend<<reference>> /+ include : Include<<reference>> /+ extensionPoint : ExtensionPoint

(from Use_Cases)1

n

+addition1

+includern

1

n

+base1

+includen n

1

+extendern

+base1

n

1

+extendn

+extension

1


Association

<<reference>> /+ connection : AssociationEnd

(from Core)

Classifier

/+ feature : Feature/+ powertypeRange : Generalization...

(from Core)

<<metaclass>>

AssociationEnd

+ isNavigable : Boolean+ ordering : OrderingKind+ aggregation : AggregationKind+ targetScope : ScopeKind+ multiplicity : Multiplicity+ changeability : ChangeableKind<<reference>> /+ association : Association<<reference>> /+ qualifier : Attribute<<reference>> /+ participant : Classifier<<reference>> /+ specification : Classifier

(from Core)

2..*1

+connection

2..*{ordered}

+association

1{1}

n

1

+associationn

+participant

1n

n

+specificationn

+specifiedEnd

n

Package




MDF: Information Model

Association

name : NameStringinverse_name : NameStringsource_multiplicity : MultiplicityStringdestination_multiplicity : MultiplicityString

Generalization_relationship

Composite_aggregation

Structural_attribute

Subject_area


0..10..* nests0..1

is_nested_in

0..*

Relationship

description : DescriptiveTexthistory : CompoundHx

Class

name : NameStringdescription : DescriptiveTextisAbstract : Booleanhistory : CompoundHx

1..*0..1

primarily_resides_in

1..*

holds

0..1

0..*

1..*includes

0..*

appears_in 1..*

10..*

is_destination

1

has_destination0..*

1

0..* is_source

1has_source

0..*

Attribute

name : NameStringdescription : DescriptiveTextinclusion : Booleanrepeatability : Booleansequence : Integerhistory : CompoundHx

1

0..*

has 1

in0..*

Subject_class

1

0..1

is_state_attribute_for1

has_state_attribute0..1

State_transition

label : NameStringdescription : DescriptiveTexthistory : CompoundHx

State

name : NameStringpredicate : Stringdescription : DescriptiveTexthistory : CompoundHx

0..1

0..*

has_substate

0..1

is_substate_of

0..*

1

0..*

has

1

in0..*

0..*

1

ends_in

0..*

ends

1

0..*

1

starts_from

0..*

is_start_of

1


HDF: Information Model ~ Class/Attribute

Class

+ isActive : Boolean

(from Core)

<<metaclass>>

ModelElement


(from Core)

Namespace


(from Core)

n

0..1

+ownedElement

n

+namespace

0..1

HL7Class

<<taggedValue>> - prototypeClass : Class

<<stereotype>>

Attribute

+ initialValue : Expression<<reference>> /+ associationEnd : AssociationEnd

(from Core)

HL7Attribute

<<taggedValue>> - typeCode : AttributeTypeKind<<taggedValue>> - sequence : Integer<<taggedValue>> - vocabularyStrength : VocabularyStrengthKind<<taggedValue>> - isStateAttribute : Boolean<<taggedValue>> - isStructuralAttribute : Boolean

<<stereotype>>



(from Core)

Feature

+ ownerScope : ScopeKind<<reference>> /+ owner : Classifier

(from Core)

StructuralFeature

+ multiplicity : Multiplicity+ changeability : ChangeableKind+ targetScope : ScopeKind+ ordering : OrderingKind<<reference>> /+ type : Classifier

(from Core)

<<metaclass>>

Generalization

+ discriminator : Name<<reference>> /+ child : GeneralizableElement<<reference>> /+ parent : GeneralizableElement<<reference>> /+ powertype : Classifier

(from Core)n

1

+generalization

n

+child 1n

1

+specializationn

+parent

1

Classifier

/+ feature : Feature/+ powertypeRange : Generalization

(from Core)

<<metaclass>>

n

0..1

+feature

n{ordered}

+owner0..1

1

n

+type

1

+typedFeaturen

n

0..1

+powertypeRange

n

+powertype0..1 Package




HDF: Information Model ~ Relationship

Class


(from Core)

ModelElement

+ name : Name+ visibility : VisibilityKind+ isSpecification : Boolean/+ namespace : Namespace/+ clientDependency : Dependency/+ constraint : Constraint/+ targetFlow : Flow/+ sourceFlow : Flow/+ comment : Comment/+ templateParameter : TemplateParameter/+ stereotype : Stereotype/+ taggedValue : TaggedValue

(from Core)


Association

/+ connection : AssociationEnd

(from Core)

AssociationEnd

+ isNavigable : Boolean+ ordering : OrderingKind+ aggregation : AggregationKind+ targetScope : ScopeKind+ multiplicity : Multiplicity+ changeability : ChangeableKind/+ association : Association/+ qualifier : Attribute/+ participant : Classifier/+ specification : Classifier

(from Core)

2..*

1

+connection2..*{ordered}

+association1 {1}

Classifier


(from Core)

n1

+association

n

+participant

1

n n

+specification

n

+specifiedEnd

n

Generalization

+ discriminator : Name/+ child : GeneralizableElement/+ parent : GeneralizableElement/+ powertype : Classifier

(from Core)

n

0..1

+powertypeRange

n

+powertype0..1


+ isRoot : Boolean+ isLeaf : Boolean+ isAbstract : Boolean/+ generalization : Generalization

(from Core)

n

1

+generalizationn

+child 1

n

1

+specializationn

+parent1


HDF: Information Model ~ States

CompositeState

+ isConcurrent : Boolean<<reference>> /+ subvertex : StateVertex

(from State_Machines)

StateVertex

<<reference>> /+ container : CompositeState<<reference>> /+ outgoing : Transition<<reference>> /+ incoming : Transition


0..n

0..1

+subvertex

0..n

+container

0..1

Event

<<reference>> /+ parameter : Parameter


Guard

+ expression : BooleanExpression/+ transition : Transition


ModelElement


(from Core)

State

<<reference>> /+ entry : Action<<reference>> /+ exit : Action<<reference>> /+ deferrableEvent : Event<<reference>> /+ internalTransition : Transition<<reference>> /+ doActivity : Action<<reference>> /+ stateMachine : StateMachine


<<metaclass>>

0..n

0..n

+deferrableEvent

0..n

+state

0..n

Transition

<<reference>> /+ guard : Guard<<reference>> /+ effect : Action<<reference>> /+ trigger : Event<<reference>> /+ source : StateVertex<<reference>> /+ target : StateVertex<<reference>> /+ stateMachine : StateMachine


n0..1

+internalTransition

n

+state

0..1

1

n

+source

1

+outgoingn

1

n

+target1

+incoming

n

0..1

n

+trigger

0..1

+transitionn 1

0..1

+transition1

+guard0..1

StateMachine

/+ context : ModelElement/+ top : State/+ trasitions : Transition/+ submachineState : SubmachineState


0..1n

+context

0..1

+behavior

n

0..1

1

+stateMachine0..1

+top1

n

0..1

+transitions

n

+stateMachine

0..1


MDF: Datatype Model

Data_type

type_code : Stringname : NameStringis_internal : Booleandescription : DescriptiveTexthistory : CompoundHx

Composite_data_type

Data_type_generalization

stereotype : Enumerateddescription : DescriptiveTexthistory : CompoundHx

Generic_type_parameter

value : StringData_type_component

name : NameStringis_reference : Booleandescription : DescriptiveTexthistory : CompoundHx

1..1

1..*

contains1..1

belongs_to1..*

Attribute_type

name : NameStringshort_name : NameStringusage : DescriptiveTexthistory : CompoundHx

0..*

0..1

has_instance_type

0..*

types0..1

0..*

1..1

has_subtype

0..*

is_subtype1..1 0..*

1..1has_supertype

0..*

is_supertype

1..1

0..*

0..*

has_allowed_types

0..*

allowed_for

0..*

0..*

1..1

defines

0..*

defined_by1..1

0..*

1..1

is_of_type

0..*

types

1..1

0..1

1..*

implements0..1

implemented_by1..*

Data_type_category


0..*

0..*

resides_in

0..*

contains

0..*

0..10..*nests

0..1is_nested_in

0..*


HDF: Datatype Model



(from Core)

ModelElement


(from Core)

HL7 DatatypeProperty

- isReference : Boolean

<<stereotype>>

Feature


(from Core)

StructuralFeature


(from Core)

<<metaclass>>

BehavioralFeature

+ isQuery : Boolean<<reference>> /+ parameter : Parameter

(from Core)

Classifier


(from Core)

<<metaclass>>

n0..1

+feature

n{ordered}

+owner

0..1

1

n

+type1

+typedFeature

n

Parameter

+ defaultValue : Expression+ kind : ParameterDirectionKind<<reference>> /+ behavioralFeature : BehavioralFeature<<reference>> /+ type : Classifier

(from Core)

n

0..1

+parameter

n

{ordered}

+behavioralFeature0..1

1n

+type1

+typedParameter

n

HL7Datatype

<<taggedValue>> - mnemonic : String<<taggedValue>> - isInternal : Boolean<<taggedValue>> - isComposite : Boolean<<taggedValue>> - isGeneric : Boolean

<<stereotype>>


MDF: Vocabulary Model (proposed)


HDF: Vocabulary Model

HL7 VocabularyDomain<<stereotype>>

EnumerationLiteral

/+ enumeration : Enumeration

(from Core)

Enumeration

/+ literal : EnumerationLiteral

(from Core)

1..*

1

+literal 1..* {ordered}

+enumeration1

HL7 CodedValue

- designation : String- isActive : Boolean

<<stereotype>>

DataType(from Core)

Classifier


(from Core)

<<metaclass>>

ModelElement

+ name : Name+ visibility : VisibilityKind+ isSpecification : Boolean/+ namespace : Namespace/+ clientDependency : Dependency/+ constraint : Constraint/+ targetFlow : Flow/+ sourceFlow : Flow/+ comment : Comment/+ templateParameter : TemplateParameter/+ stereotype : Stereotype/+ taggedValue : TaggedValue

(from Core)


+ isRoot : Boolean+ isLeaf : Boolean+ isAbstract : Boolean/+ generalization : Generalization

(from Core)

Class


(from Core)

<<metaclass>>

HL7CodeSet<<stereotype>>

HL7Datatype

- mnemonic : String- isInternal : Boolean- isComposite : Boolean- isGeneric : Boolean

(from HDF DatatypeModelProfile)

<<stereotype>>

HL7ConceptDiscriptor<<stereotype>>


MDF: Design Information Model

DIM_other_row

otherType : Enumerated

In a C-DIM, this cardinality becomes 1..1 (mandatory)

DIM_attribute_domain_constraint

strength : Enumerated

DIM_attribute_row

0..1

0..*

constrains 0..1

constrained_by0..*

DIM_notation

type : Enumerated

Design_information_model

identifier : IdentifierStringname : NameStringtype : EnumeratedwalkThrough : DescriptiveTextfirst_node_id : IdentifierStringhistory : CompoundHx

0..*0..1 derives_from 0..*

further_constrains

0..1

DIM_relationship_row

blocked : Boolean

0..11..1has_other_half

0..1is_other_half

1..1

DIM_row

cardinality : MultiplicityStringconformance : Enumeratedconstraint : DescriptiveTextdefault_update_mode : Stringdefault_value : DescriptiveTextmandatory : Booleannext_sibling_ID : IdentifierStringprevious_sibling_id : IdentifierStringname : NameStringshort_name : NameStringupdate_mode_set : Stringhistory : CompoundHx

0..*

1..1

has_parent

0..*

is_parent

1..1

0..1

0..*

further_constrains

0..1

derives_from

0..*

1..1

0..* has_notation

1..1annotates

0..*

1..*

1..1

part_of 1..*

contains 1..1

DIM_class_row

first_relation_row_id : IdentifierStringfirst_attribute_row_id : IdentifierString

0..*

0..1

has_distal_class 0..*

is_related_by 0..1

1..1

0..*

is_true_parent

1..1

has_true_parent

0..*

0..*

1..1

has_active_parent

0..*

is_active_parent

1..1

DIM_state_row


HDF: Information Model ~ Class/Attribute

Class


(from Core)

<<metaclass>>

ModelElement


(from Core)

Namespace


(from Core)

n

0..1

+ownedElement

n

+namespace

0..1

HL7Class

<<taggedValue>> - prototypeClass : Class

<<stereotype>>

Attribute

+ initialValue : Expression<<reference>> /+ associationEnd : AssociationEnd

(from Core)

HL7Attribute

<<taggedValue>> - typeCode : AttributeTypeKind<<taggedValue>> - sequence : Integer<<taggedValue>> - vocabularyStrength : VocabularyStrengthKind<<taggedValue>> - isStateAttribute : Boolean<<taggedValue>> - isStructuralAttribute : Boolean

<<stereotype>>



(from Core)

Feature


(from Core)

StructuralFeature


(from Core)

<<metaclass>>

Generalization

+ discriminator : Name<<reference>> /+ child : GeneralizableElement<<reference>> /+ parent : GeneralizableElement<<reference>> /+ powertype : Classifier

(from Core)n

1

+generalization

n

+child 1n

1

+specializationn

+parent

1

Classifier


(from Core)

<<metaclass>>

n

0..1

+feature

n{ordered}

+owner0..1

1

n

+type

1

+typedFeaturen

n

0..1

+powertypeRange

n

+powertype0..1 Package




HDF UML Profile SpecificationStereotype Base Class Parent Tags

HL7 ModelElement ModelElement N/A descriptiveTexthistoryidentifier

HL7 Package Package N/A developingOrganizationlastModifiedDateresponsibleCommitteeIDversionNumber

HL7 Model Model HL7 Package N/A

HL7 Vocabulary Package HL7 Package N/A

HL7 UsageContext Package HL7 Vocabulary N/A

HL7 InformationModel Package HL7 Package N/A

HL7 RIM Package HL7 InformationModel N/A

HL7 DIM Package HL7 InformationModel N/A

HL7 HMD Package HL7 InformationModel N/A

HL7 DatatypeModel Package HL7 Package N/A

HL7 Class Class N/A prototypeClass

HL7 Attribute Attribute N/A typeCodesequencevocabularyStrengthisStateAttributeisStructuralAttribute

HL7 Datatype Classifier N/A mnemonicisInternalisCompositeisGeneric

HL7 DatatypeProperty StructuralFeature N/A isReference

HL7 ConceptDiscriptor Classifier HL7 Datatype N/A

HL7 VocabularyDomain Class HL7 ConceptDiscriptor N/A

HL7 CodeSet Class N/A N/A

Stereotype Base Class Parent TagsHL7 ModelElement ModelElement N/A descriptiveText

historyidentifier

HL7 Package Package N/A developingOrganizationlastModifiedDateresponsibleCommitteeIDversionNumber

HL7 Model Model HL7 Package N/A

HL7 Vocabulary Package HL7 Package N/A

HL7 UsageContext Package HL7 Vocabulary N/A

HL7 InformationModel Package HL7 Package N/A

HL7 RIM Package HL7 InformationModel N/A

HL7 DIM Package HL7 InformationModel N/A

HL7 HMD Package HL7 InformationModel N/A

HL7 DatatypeModel Package HL7 Package N/A

HL7 Class Class N/A prototypeClass

HL7 Attribute Attribute N/A typeCodesequencevocabularyStrengthisStateAttributeisStructuralAttribute

HL7 Datatype Classifier N/A mnemonicisInternalisCompositeisGeneric

HL7 DatatypeProperty StructuralFeature N/A isReference

HL7 ConceptDiscriptor Classifier HL7 Datatype N/A

HL7 VocabularyDomain Class HL7 ConceptDiscriptor N/A

HL7 CodeSet Class N/A N/A


HDF Metamodel Development Next Steps

• The HDF UML Profile Specification also includes complete tag definitions and stereotype constraint specifications.

• Additional work is required to complete the specification of the HDF UML Profile and Metamodel specification to reflect the needs of Design Information Models and Hierarchical Model Descriptions.

• Work on the Interaction Model portion of the HDF Metamodel and Profile will be addressed in Phase II of the HDF project.

• The Phase I HDF Metamodel specification and UML Profile will undergo peer review within the Modeling and Methodology committee.

• MnM will be conducting a peer review of the HDF metamodel during the Q1 and Q2 of Wednesday, October 2, 2002.


HL7 Development Framework Methodology

MDF Methodology HDF Methodology


The MDF Methodology Overview


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


Simplified MDF Data Model

Exam ple

Restrict

Restrict

Restrict

RIM

D-MIM

R-MIM

HMD

MessageType

Storyboard

StoryboardExample

ApplicationRole

TriggerEvent

Interaction

Instantiate

Sender Receiver

Triggers

Content

References


MDF Methodology in a nut shell

1. Domain specialists define the essentials of their messaging requirements. Visio RMIM tooling is available as is a Publications database to document storyboards, interactions and application roles.

2. Specialist prepares a design R-MIM using Rosetree and then builds a preliminary HMD by “walking the graph”

3. Committee reviews HMD content. Revise as necessary.

4. Working with spreadsheets of the HMD (or directly using Rosetree), the committee maps out the constraints on the HMD that constitute the specific message types

5. The resulting databases are assembled and processed with publication tooling to include in the ballot package

• Steps 1-4 are iterative as the Committee clarifies the specifications


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


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


Requirements Gathering and Analysis


Analysis


Project Charter

• Prepare storyboards that elaborate upon the project scope statement.

• Conduct an analysis of the storyboards to identify major Actors and potential Use Cases.

• Construct a Use Case and Activity model 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.

• Update the Project Charter as needed.


Requirements Normalization and Harmonization


andHarnonization


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 unmapped requirements.

• Follow the reference model harmonization process to adjudicate the proposed changes to Reference Models.

• Apply approved changes to the HL7 Reference Models.

• Revise the Requirements Specification as needed and its mapping to the Reference Models.


Specification Design and Packaging



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 model packages and design models.

• Construction of the design model may lead to new discoveries that result in required enhancements to the reference models.


Specification Publication and Balloting


BallotingReferenceModel

DesignModel


• Design model content is 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 ballot specification 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).


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 other in the community defined by the context of the template may access it for use as an extension to the standard specification.

• Each Template Specification is entirely conformant with the standard specification on which it was based. A Template Specification is a context specific rendering of the standard.


Localization




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 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 the HL7 standard specifications.


The HDF Methodology OverviewProject Initiationand Management


Analysis


andHarnonization




Localization


Balloting


Project Charter

ReferenceModel

DesignModel






HDF Methodology Next Steps

• The HDF Methodology Specification is still a work-in-progress.

• The principal drivers behind the design of the HDF methodology are:

Maximize the effective use of subject matter experts in shaping the standard

Exploit the power of the Unified Modeling Language and the Model-Driven Architecture

Establish a methodology that is applicable to all the areas in which HL7 intends to establish standards

Maintain a model-driven, technology-neutral, and international perspective

• The HDF Project will have a phase II in which additional issues will be addressed such as:

Consideration of the impact of UML v2.0

Consideration of the UN/CEFACT UMM project

Consideration of the OMG MDA activities

• The MnM Technical Committee will be meeting on Thursday, October 3, 2002 during Q2 and Q3 to begin planning Phase II of the HDF Project.


Questions



La Verne, CA 91750

Office: (909) 596-6790 Mobile: (626) 644-4491



Thank You



La Verne, CA 91750

Office: (909) 596-6790 Mobile: (626) 644-4491


hl7 development framework tutorial abdul-malik shakir principal consultant, shakir consulting...

Documents

hl7 modeling

hl7 education

mission of hl7

comprehensive framework

participation of hl7

related standards

project management

evaluation of health