HL7 Development Framework Tutorial Abdul-Malik Shakir Principal Consultant, Shakir Consulting April...

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


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.


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


HL7 Development Framework Project


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.


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.


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.


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.


Project Background – HL7 MDF Process Model


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.


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


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.


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


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


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


Unified Modeling Language Metamodel


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


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:


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.


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


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


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)


(from Foundation)

Behavioral_Elements

Common_Behavior

(from Behavioral_Elements)

Collaborations


State_Machines


Use_Cases


Activity_Graphs


Model_Management


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


UML Metamodel - Foundation Core


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.


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*




Subsystem





n

0..1

+ownedElement

n

+namespace

0..1

Package


ElementImport


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.


UML Metamodel – Common Behaviors

DestroyAction

UninterpretedAction


CreateAction

/ instantiation : Classifier


*

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 Metamodel – Common Behaviors

DestroyAction

UninterpretedAction


CreateAction

/ instantiation : Classifier


*

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.


UML Metamodel - Extension Mechanisms


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


*

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 *




Stereotype



0..1

n


0..1


TagDefinition


+definedTag

n

+owner

0..1


*

n

+stereotype*

+extendedElement

n

*

n


{ordered}



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.


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.


HL7 Development Framework

Metamodel


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


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


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)


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)


(from Foundation)

Behavioral_Elements

Common_Behavior


Collaborations


State_Machines


Use_Cases


Activity_Graphs


Model_Management


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


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.


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




Subsystem





n

0..1

+ownedElement

n

+namespace

0..1

Package


ElementImport


1

*

+importedElement

1

+elementImport*

1

*

+package

1

+elementImport*


HDF: Model Management

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

Extensions to the UML Metamodel


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




Stereotype



0..1

n


0..1


TagDefinition


+definedTag

n

+owner

0..1


*

n

+stereotype*

+extendedElement

n

*

n


{ordered}



1

*

+type

1

+typedValue*

1

n

+modelElement

1

+taggedValuen

*

*

+referenceValue*

+referenceTag *


Stereotypes in the HL7 Profile

• Clone

• CodedValue

• CodeSet

• DataTypes

• DIM

• HL7Attribute

• HL7DataType

• HL7Model

• HL7ModelElement

• HL7Package

• RegisteredCodeSystem

• RIM

• UsageContext

• Vocabulary

• VocabularyDomain


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


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


HDF Metamodel

UML Metamod

el v1.4

HDF UML Profilev1.0

HDF Metamodel v1.0

HDF Metamodel = UML Metamodel + HDF UML Profile


HDF Model Interchange

Format


Model Interchange Requirements

Model RepositoryDesign Database / Publication Database

Model RepositoryDesign Database / Publication Database

RationalRose

RationalRose

RoseTreeRoseTree

RMIMDesigner

RMIMDesigner

SchemaGeneratorSchema

Generator


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


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


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


Session I Review

• HL7 Development Framework Project

• Unified Modeling Language Metamodel

• HDF UML Profile and Metamodel

• HDF Model Interchange Format


Cookie Break – 30 Minutes


Session II Overview

• HL7 Message Development Framework

• HDF Development Methodology

• HDF Pilot Projects

• HDF Developer’s Guide

• HDF Transition Planning


HL7 Message Development

Framework


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


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


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.


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


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


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?


HL7 Development Framework

Methodology


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


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.


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


Eight Work Products of the HDF Methodology

• Project Charter

• Requirements Specification

• Reference Model

• Design Model

• Standard Specification

• Template Specification

• Implementation Profile

• Conformance Specification


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


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


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?


Requirements Gathering and Analysis


Analysis


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.


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


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


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.


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


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


Specification Publication and Balloting


BallotingReferenceModel

DesignModel


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


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


Specification Refinement and Localization


Localization



• Specification refinement involves the application of additional restrictions to balloted specifications to constrain the standard for use in a particular context.

• Specification localization is a privilege available only to HL7 international affiliates.

It includes specification refinement and RIM-based extensions to the content of balloted HL7 standards.


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.


Specification Implementation and Validation






• Standard specifications, templates, and localizations are input to the specification implementation and validation phase.

• New and/or revised template specifications are output from the implementation and validation phase.

• Implementation profiles and conformance specifications are the primary outputs of the specification and validation phase.


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.


The HDF Methodology OverviewProject Initiationand Management


Analysis


andHarnonization




Localization


Balloting


Project Charter

ReferenceModel

DesignModel






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


HDFPilot Projects


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


HDFDeveloper’s Guide


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


HDFTransition Planning


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


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


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]

HL7 Development Framework Tutorial Abdul-Malik Shakir Principal Consultant, Shakir Consulting April...

Documents

Transcript of HL7 Development Framework Tutorial Abdul-Malik Shakir Principal Consultant, Shakir Consulting April...