Database Homework

cyberdreams

hl72boverview.ppt

Home >Computer Science homework help >Database Homework

HL7 Version 3 at NCICB Overview

Session Details
Introduction
Reference Information Model (RIM)
HL7 Modeling Conventions
HL7 Process & Artifacts, Vocabulary & Data Types
HL7 Version 3 at NCI
Web Resources

Session Details

Target Audience:
Developers and Analysts
Adopters
Prerequisites:
Modeling concepts

Session Details:
Presenters and Participants

<Presenter’s name here>
Who is in attendance?
Name
Title
Cancer Center
Reason for Attending

Note:

This training can also be used as a self-paced training. (See notes for each slide)

Instructor: Introduce yourself

The notes provide you with additional information on slide topic.

Session Details:
Training Objectives

Objectives of this training are to:
Provide an overview of HL7 version 3
Define terms and concepts used in HL7
Describe the HL7 modeling methodology
Introduce reason for HL7 version 3 at NCICB

At the end of this training you should:

Understand what HL7 is

Define terms and concepts used in HL7

Read HL7 RIM based models

HL7 at the NCI

Introduction

In this section, we will:
Introduce the HL7 organization and the version 3 standard
Discuss the goal of HL7

In this section, we will:

Goal of HL7

4 Pillars of semantic interoperability

Introduction:
What is HL7?

Heath Level Seven (HL7) is an ANSI-accredited Standards Developing Organization (SDO) operating in healthcare arena
Provides standards for data exchange to allow interoperability between healthcare information systems
HL7 focuses on the clinical and administrative data domains
It is a not-for-profit organization made up of volunteers – providers, payers, vendors, government
Key goal is syntactic and semantic interoperability

The goal of HL7 is

HL7 V3 is a standard for exchanging messages among information systems that implement healthcare applications. To accomplish this, HL7 uses an object-oriented development methodology and is based on a Reference Information Model (RIM) to create messages. The goal of HL7 is semantic interoperability.

What Does the Name HL7 Mean

"Level Seven" refers to the highest level of the International Standards Organization's (ISO) communications model for Open Systems Interconnection (OSI) - the application level. The application level addresses definition of the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application. The seventh level supports such functions as security checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring.

How is HL7 Organized

HL7 is managed by a Board of Directors, which is comprised of eight elected positions and three appointed positions. The organization is comprised of Technical Committees and Special Interest Groups that are responsible for defining the HL7 standard protocol. Each Technical Committee and Special Interest group is chaired by two or more co-chairs. Collectively, the co-chairs comprise the Technical Steering Committee, which votes on issues related to the standard. Votes of the Technical Steering Committee as passed as recommendations to the Board of Directors, who make the final decision. HL7 members are encouraged to participate in all of these committees.

Introduction:
4 Pillars of Semantic Interoperability

The 4 pillars of semantic interoperability are:

A common Reference Information Model (RIM) spanning the entire clinical, administrative and financial healthcare universe

A well-defined and tool-supported process for deriving data exchange specifications ("messages") from the RIM

A formal and robust Data Type Specification upon which to ground the RIM

A formal methodology for binding concept-based terminologies to RIM attributes.

The 4 Pillars:

The following slides will discuss these pillars.

The Reference Information Model (RIM)

The Reference Information Model (RIM) is the cornerstone of the HL7 Version 3 development process. An object model created as part of the Version 3 methodology, the RIM is a large pictorial representation of the clinical data (domains) and identifies the life cycle of events that a message or groups of related messages will carry. It is a shared model between all the domains and as such is the model from which all domains create their messages. Explicitly representing the connections that exist between the information carried in the fields of HL7 messages, the RIM is essential to our ongoing mission of increasing precision and reducing implementation costs.

Data Types

Data types are the basic building blocks of attributes. They define the structural format of the data carried in the attribute and influence the set of allowable values an attribute may assume. Some data types have very little intrinsic semantic content and the semantic context for that data type is carried by its corresponding attribute. However HL7 also defines quite extensive data types such as PNMP, person Name Part, which provides all the structure and semantics to support a person name. Every attribute in the RIM is associated with one and only one data type, and each data type is associated with zero or many attributes.

Data Exchange Specifications

HL7 defines its messages at an abstract level. The "7" in HL7 stands for the Application level of the ISO communication model -- ISO level 7. The V3 abstract message model is based on the RIM. HL7 Version 3 messages can be thought of as the communication of graphs of RIM objects from sender to receiver.

Vocabulary

Within HL7, a vocabulary domain is the set of all concepts that can be taken as valid values in an instance of a coded field or attribute. For example, the Living_subject class has a coded attribute called administrative_gender_code. The administrative_gender_code attribute becomes part of an HMD, and a message instance is subsequently created as part of an implemented interface, one would expect the administrative_gender_code attribute to convey male or female. In this example, male and female are concepts and there may be several coding schemes that contain concepts for male and female.

Reference Information Model (RIM)

In this section, we will:
Discuss the modeling concepts used in HL7 Version 3
Describe the Backbone Classes of the HL7 RIM

Reference Information Model (RIM):
Overview

Reference Information Model (RIM):

Follows object oriented developmental methodology based on a UML model
The fundamental model from which all v3 messages are derived is referred to as the Reference Information Model (RIM)
The RIM is a generic, abstract model that expresses the information content of all the areas of healthcare
Defines all the information from which the data content of HL7 messages are drawn
Forms a shared view of the healthcare domain and is used across all HL7 messages independent of message structure

The Health Level Seven (HL7) Reference Information Model (RIM) is a static model of health and health care information as viewed within the scope of HL7 standards development activities. It is the combined consensus view of information from the perspective of the HL7 working group and the HL7 international affiliates. The RIM is the ultimate source from which all HL7 version 3.0 protocol specification standards draw their information-related content.

What is a information model?

An information model is a structured specification of the information within a specific domain of interest. It expresses the classes of information required and the properties of those classes, including attributes, relationships, constraints, and states. In HL7, the scope of a domain of interest ranges from the domain of the entire system of health services to the specific context of a set of information exchanges to meet a particular identified business purpose. HL7 defines different types of information models to represent the different contexts of interest

Information Model Components

The information model consists of the following components:

classes, their attributes, and relationships between the classes;

data types for all attributes and vocabulary domains for coded attributes;

state transition models for some classes.

HL7 information models are based upon the Unified Modeling Language (UML), and may be represented graphically using the UML style. UML is a modeling language that unifies the object-oriented modeling methods of Grady Booch, Jim Rumbaugh, Ivar Jacobson, and others. The UML is a rich, mainly graphical, means of expressing object-oriented concepts. To obtain more information about UML see http://www.rational.com/uml/ or the book UML Distilled by Martin Fowler (ISBN 0-201-32563-2).

Reference Information Model (RIM):
Backbone Classes

A physical thing, group of physical things or an

organization capable of participating in Acts, while in a role.

A record of something that is being done, has been done, can be done, or is intended or requested to be done.

A competency of the Entity playing the Role as identified, defined, guaranteed, or acknowledged by the Entity that Scopes the Role.

An association between an

Act and a Role with an Entity

playing that Role. Each Entity (in a Role) involved in

an Act in a certain way is linked to the act by one

Participation-instance.

Entity

Role

Participation

Act

A connection between two roles expressing a dependency between those roles.

A directed association between a source act and a target act.

Role Link

Act Relationship

0..1

0..n

0..1

0..n

Note:

RIM model is color coded based on the backbone class.

The HL7 RIM

The HL7 RIM is a critical component of the V3 development process. It is the root of all information models and structures. The HL7 V3 development process is a model-driven methodology. Inter-related models are developed that depict underlying semantics and business rules that govern them. The RIM provides a static view of the information needs of HL7 V3 standards. It includes class and state-machine diagrams and is accompanied by use case models, interaction models, data type models, terminology models, and other types of models.

The classes, attributes, state-machines, and relationships in the RIM are used to derive domain-specific information models. The HL7 V3 standard development process defines the rules governing the derivation of domain information models from the RIM and the refinement of those. The rules require that all information structures in derived models be traceable back to the RIM and that their semantic and related business. The RIM therefore is the ultimate source for all information content in HL7 V3 standards.

Examples of Subclasses of Foundation Classes:

Entity

- Organization

- Place

- Person

- Living Subject

- Material

Role

- Patient

- Member

- Healthcare facility

- Practitioner

- Practitioner assignment

- Specimen

- Location

Participation

- Author

- Reviewer

- Verifier

- Subject

- Target

- Tracker

- Performer

Act

- Referral

- Transportation

- Supply

- Procedure

- Consent

- Observation

- Medication

- Administrative act

- Financial act

Reference Information Model (RIM)
Backbone Class: Entity

Entity

classCode : CS

determinerCode : CS

id : SET<II>

code : CE

quantity : SET<PQ>

name : BAG<EN>

desc : ED

statusCode : SET<CS>

existenceTime : IVL<TS>

telecom : BAG<TEL>

riskCode : CE

handlingCode : CE

Entity: a person, animal, organization or thing

A collection of classes related to the Entity class, its specializations and related qualifying classes. The classes represent health care stakeholders and other things of interest to health care.

Entity has the following sub-classes:

Container

Device

LanguageCommunication

LivingSubject

ManufacturedMaterial

Material

NonPersonLivingSubject

Organization

Person

Place

Note: classes are not the only.. The only ones show are the ones that have unique attributes

Definition of Entity:

A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.

Reference Information Model (RIM):
Backbone Class: Role

Role

classCode : CS

id : SET<II>

code : CE

negationInd : BL

addr : BAG<AD>

telecom : BAG<TEL>

statusCode : SET<CS>

effectiveTime : IVL<TS>

certificateText : ED

quantity : RTO

positionNumber : LIST<INT>

...

Roles:

A responsibility or part played by an entity (e.g. Person in a role of patient, employee, etc.) – different faces of an Entity

A collection of classes related to the Role class and its specializations. These classes focus on the roles participants may play in health care.

Role has the following sub-classes:

Access

Employee

LicensedEntity

Patient

Note: classes are not the only.. The only ones show are the ones that have unique attributes

Definition of Role:

A competency of the Entity playing the Role as identified, defined, guaranteed, or acknowledged by the Entity that scopes the Role.

Reference Information Model (RIM):
Backbone Class: RoleLink

RoleLink

typeCode : CS

effectiveTime : IVL<TS>

Role

0..n

outboundLink

0..n

source

0..n

inboundLink

0..n

RoleLink:

A connection between two roles expressing a dependency between those roles.

RoleLink has no sub-classes.

Definition of RoleLink:

A connection between two roles expressing a dependency between those roles.

Examples: A role of assignment or agency depends on another role of employment, such that when the employment role is terminated, the assignments would be terminated as well. This is the dependency of the assignment role with the employment role, or in other words, the assignment is "part of" the employment.

Reference Information Model (RIM):
Backbone Class: Participation

Participation

typeCode : CS

functionCode : CD

contextControlCode : CS

...

sequenceNumber : INT

negationInd : BL

noteText : ED

time : IVL<TS>

modeCode : CE

awarenessCode : CE

signatureCode : CE

signatureText : ED

performInd : BL

substitutionConditionCode : CE

Participation:

An association between an Act and a Role with an Entity playing that Role.

Participation has the following sub-class:

ManagedParticipation

Note: classes are not the only.. The only ones show are the ones that have unique attributes

Definition of Participation:

An association between an Act and a Role with an Entity playing that Role. Each Entity (in a Role) involved in an Act in a certain way is linked to the act by one Participation-instance. The kind of involvement in the Act is specified by the Participation.typeCode.

Reference Information Model (RIM):
Backbone Class: Act

Act

classCode : CS

moodCode : CS

id : SET<II>

code : CD

negationInd : BL

derivationExpr : ST

text : ED

title : ST

statusCode : SET<CS>

effectiveTime : GTS

activityTime : GTS

availabilityTime : TS

priorityCode : SET<CE>

confidentialityCode : SET<CE>

repeatNumber : IVL<INT>

interruptibleInd : BL

levelCode : CE

independentInd : BL

uncertaintyCode : CE

reasonCode : SET<CE>

languageCode : CE

Act:

A collection of classes including the Act class and its specializations. These relate to the actions and events that constitute health care services. A record of something that is being done, has been done, can be done, or is intended or requested to be done.

Act has the following sub-classes:

Account

ControlAct

DeviceTask

DiagnosticImage

Diet

FinancialContract

FinancialTransaction

InvoiceElement

Observation

Participation

PatientEncounter

Procedure

PublicHealthCase

SubstanceAdministration

Supply

WorkingList

Note: Sub-classes also include Core Infrastructure, Message Communications Control and Structured Documents classes not shown here.

Note: classes are not the only.. The only ones show are the ones that have unique attributes

Definition of Act:

A record of something that is being done, has been done, can be done, or is intended or requested to be done.

Examples: The kinds of acts that are common in health care are (1) a clinical observation, (2) an assessment of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such as medication, surgery, physical and psychological therapy), (5) assisting, monitoring or attending, (6) training and education services to patients and their next of kin, (7) and notary services (such as advanced directives or living will), (8) editing and maintaining documents, and many others.

Reference Information Model (RIM):
Backbone Class: ActRelationship

ActRelationship

typeCode : CS

inversionInd : BL

contextControlCode : CS

contextConductionInd : BL

sequenceNumber : INT

priorityNumber : INT

pauseQuantity : PQ

checkpointCode : CS

splitCode : CS

joinCode : CS

negationInd : BL

conjunctionCode : CS

localVariableName : ST

seperatableInd : BL

Act

0..n

outboundRelationship

0..n

source

inboundRelationship

0..n

target

ActRelationship:

A directed association between a source Act and a target Act. A point from a later instance to a earlier instance OR point from collector instance to component instance.

ActRelationship has no sub-classes.

Definition of ActRelationship:

A directed association between a source Act and a target Act. ActRelationship on the same source Act are called the "outbound" act relationships of that Act. ActRelationships on the same target Act are called the "inbound" relationships of that Act. The meaning and purpose of an ActRelationship is specified in the ActRelationship.typeCode attribute.

Reference Information Model (RIM):
The Complete RIM

Domain Related

Infrastructure Related

Structured Documents

Understanding the RIM

The RIM uses a abstract modeling style. The back-bone classes of the RIM and their structural attributes are its core. An understanding of these classes and attributes are essential to understanding the RIM.

Defines all the information from which the data content of HL7 messages are drawn
Follows object-oriented modeling techniques, where the information is organized into classes that have attributes and that maintain associations with other classes
Forms a shared view of the information domain used across all HL7 messages independent of message structure
Provides a means for discovering and reconciling differences in data definition

Reference Information Model (RIM):
RIM-UML Instance Scenario

John Doe

Patient

Subject

Entity

Role

Participation

Act

Dr. Smith

HealthCare

Provider

Surgeon*

John Doe

Patient

Subject

Has Pertinent Information

Act Relationship

(Clinical Trial Act)

Protocol ECOG 1112

XYZ Hospital

HealthCare

Facility*

Location

(Procedure Act)

Prostectomy

HL7 Version 3 Process & Artifacts

In this section, we will discuss:
Domain Message Information Model (DMIM)
Refined Message Information Model (RMIM)
Hierarchal Message Definitions (HMDs)
Message Type (MT)

HL7 Version 3 Process & Artifacts:
Overall Process

RIM

D-MIM

R-MIM

1..*

HMD

1..*

Notes about HL7 processes … message are derived from the RIM. Focus on the model methodology of DMIM and RMIM. People will be looking at the RMIM.

Entry points

HL7 Version 3 Process & Artifacts:
Examples

Arrows

Color-coding

Labeling

Directional

color-coded

colors denotes type of backbone class

Red = Act

Blue = Participation

Yellow = Role

Green = Entity

Light red or pink = Act Relationship

Light Yellow = Role Link

Arrows

Participations, Role_Links and Act_Relationships are arrows that are directional have attributes rather than being lines that connect classes like in UML

Entry Point

Each D-MIM diagram will have at least one Entry Point. Entry Points designate the class(es) from which the messages begin for the particular domain. Since the D-MIM encompasses an entire domain, there may be several Entry Points, one for each R-MIM contained in the domain.

Entry Point

RMIMs are directional

All associations flow out from the entry point toward the remaining parts of the message

labeling

HL7 diagrams are a little different in how they label associations (only on distal end, not bi-directional)

Normally in UML diagrams you have a label on both ends of an association and the association can be read both ways, but in an HL7 RMIM the association can only be read one way and thus there is only one label and it's on the distal (far) end of the association

2735.bin

Reference Information Model (RIM):
HL7 Modeling Conventions

Color-coding – colors of classes in the model denote the type of backbone class to which it belongs
Arrows – Participations, ActRelationships and RoleLinks are directional arrows that have rather than being lines that connect classes like in UML
Entry points – where to start reading the model; DMIMs have one or more entry points, RMIMs have one
RMIMs are directional – all associations flow out from the entry point to the remaining parts of the model
Labeling – associations in RMIMs are labeled on the distal end only

HL7 Modeling Conventions

color-coded - colors mean type of backbone class
arrows - participations and actRelationships are arrows that are directional have attributes rather than being lines that connect classes like in UML
entry points - HL7 DMIMs and RMIMs have entry points (boxes with arrow pointing to a class); DMIMs can have more than one, RMIMs can only have one
RMIMs are directional - all associations flow out from the entry point toward the remaining parts of the message
labeling - HL7 diagrams are a little different in how they label associations (only on distal end, not bi-directional)

HL7 Process & Artifacts:
Domain Message Information Model (DMIM)

A DMIM is a refined subset of the RIM that includes a set of class clones, attributes and relationships that can be used to create messages for a particular domain (a particular area of interest in healthcare).

HL7 Process & Artifacts:
Refined Message Information Model (RMIM)

The RMIM is a subset of a DMIM that is used to express the information content for a message or set of messages with annotations and refinements that are message specific.

HL7 Process & Artifacts:
Hierarchal Message Definitions (HMDs)

A Hierarchal Message Definition (HMD) is a serialized version of the RMIM in a specific order.

Hierarchal Message Definitions (HMDs) is a serialize version of the RIM in a specific order

2867.bin

HL7 Process & Artifacts:
Message Type (MT)

The Message Type elements and attributes in an XML message instance correspond to the sequence of data in the HMD

The XML elements and attributes in a message instance correspond one-to-one with individual rows in the HMD. The names of the XML elements and attributes are taken from the "element name" column of the HMD.

2868.bin

Vocabulary & Data Types

In this section, we will discuss:
HL7 Standard Vocabulary
Structural Attributes – prescribed HL7 vocabulary
Non-Structural Attributes – vocabulary chosen by organization
Robust Data Types

Vocabulary & Data Types:
Structural Attributes

Structural attributes are used to specify type and state of each RIM class and what it means when used in a message. They use a standard vocabulary defined and controlled by HL7.

An Act of the Class Observation (OBS) with a Mood of Event (EVN).

classCode and moodCode are both Structural Attributes

Structural attributes

Structural attributes are used to specify more precisely what each RIM class means when used in a message.

For example,

Act has a class code. The class code states what sort of Act this is, such as an observation, an encounter, or the administration of a drug. Mood is analogous to the tense of a verb.

2713.bin

Vocabulary & Data Types :
Non-Structural Attributes

Other attributes don’t have an assigned vocabulary
Organizations can choose any industry standard vocabulary
For example, commonly used ones for Observation Acts are LOINC, SNOMED, MedDRA, etc.
Must specify more than just the code value, other data is needed for semantic interoperability…this is where data types come in

Vocabulary & Data Types :
Data Types

What is a data type?

lengthOfStayQuantity is attribute of the EncounterProcess class.

lengthOfStayQuantity has a data type of Physical Quantity (PQ).

Coded Values

HL7 uses two main types of code. The first type covers the specialized codes used for structural attributes and are defined by HL7 itself. The second type covers externally defined terms and codes such as SNOMED CT (Clinical Terms).

Vocabulary

Vocabulary is the set of allowed values for a coded field.
All attributes with a code data type will have a vocabulary assigned to them.
The ‘code system’ must be identified for any coded value in a message.

NameTypeDescription

Code= The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

codeSystem= Specifies the code system that defines the code.

codeSystemName= A common name of the coding system.

codeSystemVersion= A version descriptor defined specifically for the given code system.

displayName= A name or title for the code, under which the sending system shows the code value to its users.

2869.bin

Vocabulary & Data Types :
Data Types

Data types in HL7 version 3 are complex
Each data type has attributes
Each attribute has a data type of its own

Physical Quantity (PQ) example

The attributes ‘value’ and ‘unit’ are part of the complex data type Physical Quantity (PQ). Value is expressed as the data type of integer (int).

Coded Values

Vocabulary

Vocabulary is the set of allowed values for a coded field.
All attributes with a code data type will have a vocabulary assigned to them.
The ‘code system’ must be identified for any coded value in a message.

NameTypeDescription

Code= The plain code symbol defined by the code system. For example, "784.0" is the code symbol of the ICD-9 code "784.0" for headache.

codeSystem= Specifies the code system that defines the code.

codeSystemName= A common name of the coding system.

codeSystemVersion= A version descriptor defined specifically for the given code system.

displayName= A name or title for the code, under which the sending system shows the code value to its users.

2876.bin

HL7 Version 3 at NCICB

In this section, we will discuss:
Why HL7 at NCICB?
NCICB Clinical Architecture Vision
caAdapter

HL7 Version 3 at NCICB:
Why HL7?

Recommended by the Health and Human Service (HHS) as the messaging standard for electronic exchange of clinical data.
Over 90% of US hospitals have implemented some version of 2.x HL7 messages.
Support for translational research requires integration of research data with the clinical data.
V3 offers the syntactic and semantic interoperability to make this possible

HL7 Version 3 at NCICB:
NCICB Clinical Architecture Vision

HL7 version 3 supports messaging within the

NCICB Clinical Architecture Vision.

FDA

SPONSOR

CTEP

DCP

Other

etc.

Tissues

Labs

JDBC 2

Analytical Applications

Analytical and Reporting Tools (SAS, WebSDM, ToxViewer, I-Review, etc.)

Ad Hoc

Query

Tool

BIO-gopher

Master Index

Message

Exchange

Services

(ebXML)

Translation Service

(CAM/caAdapter)

Electronic

Medical

Record (EMR)

HL7 v3

Excel, Text,

HL7 v2,

etc.

HL7 v3

HL7 Transactional Database (HTB)

Extensions

(CDUS/CTMS)

Base Janus Model

BRIDG

Clinical/Clinical Trials Applications

C3D

caMATCH

C3PR

SAE

Study Specific Analysis Data

Clinical

Data Sources

Patient Identifiable Clinical Environment

caGRID

caBIG

HL7 v3

Secure

Transport

Between

Sites

caBIO/CTOM

HL7 RIM

BRIDG

caBIO/CTOM

HL7 RIM

External

Agencies

HL7 v3

Common Security Module (CSM)

Enterprise Vocabulary Service (EVS)

Data Standards Repository (caDSR)

Secure

Transport

Between

Sites

Excel, Text,

HL7 v1, v2, etc.

De-Identification/

Re-Identification

Service

HL7 v3

eCTD,

Excel,

Text,

HL7 v2,

etc.

Translation Service

(CAM/caAdapter)

HL7 v3

caPRI

FIREBIRD

CRIX Data Repository

HL7 v3 Messaging Standard at NCICB

NCI’s Clinical Trials Architecture vision supports open sharing of clinical and research data across the cancer research and clinical care communities. Clinical systems supply trial data to a message exchange, using the HL7 Software Development Kit (SDK) to build HL7 V3 messages to carry the data. [NCICB Clinical Architecture Vision]

HL7 Version 3 at NCICB:
Highlights of the NCICB Clinical Architecture Vision

caAdapter – Open source toolkit which facilitates v3 message building, parsing and validation
Message Exchange – Service supporting message transmission and routing
HL7 Transactional Database - HL7 RIM-based transactional database and data access service
De-identification Service – Service for de-identifying patient information from HL7 messages
Analytical Applications - Applications for querying, reporting, mining clinical data
Cancer Data Standards Repository (caDSR) - Shared metadata repository
Enterprise Terminology Services (EVS) - Terminology service for hosting controlled vocabulary, including HL7 registered terminology

HL7 Version 3 at NCICB:
caAdapter

Facilitates the building, parsing, and validation of HL7 v3 messages
Components include:
HL7 v3 Message Parser – parses HL7 version 3 messages to RIM object graph
HL7 v3 Message Builder – builds HL7 version 3 messages from the RIM object graph
HL7 v3 Artifacts – implements RIM objects, data types and metadata objects
Metadata Loader – represents HL7 version 3 metadata in-memory
Validation Services – integrates with NCICB caCORE components such as Enterprise Vocabulary Service (EVS) and W3C XML schema validation services
Mapping Tool – maps clinical data to the HL7 version 3 message specification currently, with extensible mapping and data transformation in the near future
caAdapter API – uses mappings to generate HL7 version 3 messages
Message Service – integrates with message exchange services (future plans)

HL7 Version 3 at NCICB:
caAdapter

A platform to enable clinical applications to build and parse HL7 v3 messages based on specific schema definitions.
Capability to perform vocabulary validation of the RIM structural attributes.
An open source solution for implementing an international messaging standard allowing data to be exchanged between disparate systems.
Integration with NCI metadata repository (caDSR) and terminology services (EVS)
Facilitating the building and parsing of HL7 v3 messages from source clinical systems will promote data exchange in a standards based common format.

Recommended Resources

Health Level Seven

www.hl7.org

HL7 Reference Information Model

https://www.hl7.org/library/data-model/RIM/C30202/rim.htm

HL7 Vocabulary Domains

http://www.hl7.org/library/data-model/RIM/C30123/vocabulary.htm

HL7 Version 3 Standard

http://www.hl7.org/v3ballot/html/welcome/environment/index.htm

NCICB caAdapter Project Site

trials.nci.nih.gov/projects/infrastructureProject/caAdapter

HL7 Version 3: Driving Interoperability & Transforming Healthcare Information Management - Charles Mead, MD, MSc

NIHSeminar_Charlie Mead.ppt

Observation

...

SubstanceAdministration

routeCode : CE

...

Procedure

...

Supply

...

Diet

...

Document

...

Container

capacityQuantity : PQ

heightQuantity : PQ

diameterQuantity : PQ

capTypeCode : CE

...

Access

approachSiteCode : CD

...

Device

manufacturerModelName : SC

softwareName : SC

localRemoteControlStateCode : CE

...

Employee

jobCode : CE

jobTitleName : SC

jobClassCode : CE

salaryTypeCode : CE

...

LivingSubject

administrativeGenderCode : CE

...

birthTime : TS

deceasedInd : BL

deceasedTime : TS

...

Material

formCode : CE

...

LicensedEntity

recertificationTime : TS

...

Place

mobileInd : BL

addr : AD

directionsText : ED

...

ManufacturedMaterial

lotNumberText : ST

...

NonPersonLivingSubject

...

Patient

...

Organization

...

Account

...

Person

addr : BAG<AD>

...

maritalStatusCode : CE

...

WorkingList

ownershipLevelCode : CE

...

PublicHealthCase

...

PatientEncounter

preAdmitTestInd : BL

admissionReferralSourceCode : CE

lengthOfStayQuantity : PQ

dischargeDispositionCode : CE

specialCourtesiesCode : SET<CE>

...

Other

Acts

Infrastructure (Structured documents)

HEALTH LEVEL 7

REFERENCE INFORMATION MODEL

VERSION 1.23 (RIM_0123)

Reflects changes to RIM in RIM Harmonization Meeting 03/20/2003.

Billboard produced by:

Rochester Outdoor Advertising

Roles

DiagnosticImage

subjectOrientationCode : CE

...

QueryAck

...

QueryContinuation

...

Table

summary : ST

...

TableStructure

...

TableColumn

Structure

spa

n :

TableCell

scope : CS

...

LocalAttr

...

LocalMarkup

...

LinkHtml

...

ContextStructure

localId : ST

Infrastructure (Structured

documents)

Infrastructure

(Communications)

Enitites

Message Control

FinancialTransaction

...

InvoiceElement

modifierCode : SET<CE>

...

FinancialContract

paymentTermsCode : CE

...

RoleHeir

EntityHeir

SortControl

sequenceNumber : INT

...

QuerySpec

modifyCode : CS

responseElementGroupId : SET<II>

...

responseModalityCode : CS

responsePriorityCode : CS

...

0..n

RelationalExpression

...

QueryBySelection

SelectionExpression

0..n

LogicalExpression

relationalConjunctionCode : CS

...

0..n

0..1

userAsRight

0..n

rightSide

0..1

0..n

0..1

userAsLeft

0..n

leftSide

0..1

QueryByPa

rameter

ParameterList

Paramet

id : II

0..n

0..1

0..n

0..1

0..n

0..1

0..n

ParameterItem

...

DeviceTask

parameterValue : LIST<ANY>

...

ManagedParticipation

...

ActHeir

ActRelationship

typeCode : CS

inversionInd : BL

...

contextControlCode : CS

...

contextConductionInd : BL

...

Act

classCode : CS

moodCode : CS

id : SET<II>

code : CD

negationInd : BL

derivationExpr : ST

...

0..n

inboundRelationship

0..n

target

0..n

outboundRelationship

0..n

source

Participation

typeCode : CS

functionCode : CD

contextControlCode : CS

sequenceNumber : INT

negationInd : BL

noteText : ED

time : IVL<TS>

modeCode : CE

...

0..n

RoleLink

...

Role

classCode : CS

id : SET<II>

code : CE

negationInd : BL

addr : BAG<AD>

telecom : BAG<TEL>

statusCode : SET<CS>

...

0..n

outboundLink

0..n

source

0..n

inboundLink

0..n

target

LanguageCommunication

languageCode : CE

modeCode : CE

...

AttentionLine

...

Batch

referenceControlId : II

name : SC

...

Entity

classCode : CS

determinerCode : CS

id : SET<II>

code : CE

quantity : SET<PQ>

name : BAG<EN>

desc : ED

statusCode : SET<CS>

...

0..n

0..1

playedRole

0..n

player

0..1

0..n

0..1

scopedRole

0..n

scoper

0..1

0..n

Transmission

id : II

...

0..n

0..1

0..n

0..1

0..n

Communicatio

nFunction

typeCode : CS

telecom : TEL

1..n

0..*

1..n

0..*

1..*

0..*

1..*

0..*

InfrastructureRoot

...

QueryEvent

...

ControlAct

...

0..1

Message

versionId : ST

interactionId : II

profileId : SET<II>

processingCode : CS

processingModeCode : CS

acceptAckCode : CS

applicationAckCode : CS

...

0..1

0..n

0..1

payload

0..n

Acknowledgement

...

0..n

acknowledgedBy

0..n

acknowledges

0..1

conveyedAcknowledgement

0..1

conveyingMessage

AcknowledgementDetail

...

0..n