Transcript Document

HL7 Version 3: Developed Globally,
Implemented Locally
Mark Shafarman
HL7 Chair
with additional HL7 “roles” of
past co-chair International Committee
past co-chair Control/Query TC
ex-officio member Architectural Review Board
member Early Adopters Forum
Applications Architect,
Oracle Corporation
[email protected]
1 415 491 8104
24 March, 2004
Copyright 2004, HL7
1
Acknowledgements
With major help from
George W. Beeler, Jr. Ph.D.
Leader, HL7 Version 3
Acceleration Project
Emeritus Staff, Mayo Clinic
CEO, Beeler Consulting LLC
[email protected]
507-254-4810
And some additional contributions from
Peter Schloeffel and Dipak Kalra
And major contributions from the HL7 International
Affiliates
24 March, 2004
Copyright 2004, HL7
2
Agenda
• Introduction to HL7.org
• Why Version 3
• Brief overview of v 3, including support for patient
data: physical measurements
– HL7 RIM – model of clinical information content
– Creating model based message standards with RIM –
Refinement with Constraints
– Producing a simple example
– Lab result example
• How HL7 supports the EHR: Recent trends towards
interoperability.
• Examples of Contributions to version 3 from
International affiliates
24 March, 2004
Copyright 2004, HL7
3
Interoperability & Innovation
• Main Entry: in·ter·op·er·a·bil·i·ty
Function: noun
Date: 1977
: ability of a system (as a weapons system) to use the
parts or equipment of another system
Source: Merriam-Webster web site
• interoperability
: ability of two or more systems or components to
exchange information and to use the information that
has been exchanged.
Source: IEEE Standard Computer Dictionary: A Compilation of
IEEE Standard Computer Glossaries, IEEE, 1990]
Functional
interoperability
24 March, 2004
Copyright 2004, HL7
Semantic
interoperability
4
Interoperability & Innovation
HL7’s mission is clinical interoperability
“To provide a comprehensive framework and related
standards for the exchange, integration, sharing, and
retrieval of electronic health information that supports
clinical practice and the management, delivery and
evaluation of health services. Specifically, to create
flexible, cost effective standards, guidelines, and
methodologies to enable healthcare information system
interoperability and sharing of electronic health
records.” (Source: HL7 Mission statement, revised 2001)
HL7’s strategy is innovation – both by ourselves and by
our users
24 March, 2004
Copyright 2004, HL7
5
Who is HL7?
• Over 500 organizational members, about 1500 total members
• Up to 500 attend Working Group Meetings - including about
100 international attendees at the January 2004 WG)
• 26 International affiliates in (in addition to “HL7/US”)
– Argentina
- Australia
–Canada
- China
– Czech Republic- Denmark
– Germany
- Greece
– Ireland
- Italy
– Korea
- Lithuania
– New Zealand - Poland
– South Africa - Switzerland
– The Netherlands
24 March, 2004
Copyright 2004, HL7
- Brazil
- Croatia
- Finland
- India
- Japan
- Mexico
- Spain
- Taiwan
- The United Kingdom
6
What has HL7 produced?
• Founded in 1987
• Produced Version 1.0 and
2.0 in ‘87 and ‘88
• Approved HL7 message
standards –2.1, 2.2, 2.3, 2.3.1, 2.4 and 2.5
in ‘90, ‘94, ‘97, ‘99 and ’00,
and ’03.
• Approved CCOW
standards
–1.0, 1.1, 1.2, 1.3 in ’99, ’00
and ‘01
• Approved XML-based
Clinical Document
Architecture standard in ’00
• Accredited as an SDO by
ANSI in 1994
–All HL7 approvals since ‘94 are
“American National Standards”
• Published implementation
recommendations for:
–Object broker interfacing ‘98
–Secure messaging via e-mail ‘99
–HIPAA Claims attachments ‘99
–XML encoding of Version 2 ’00
• Approved Arden Syntax
standard in ‘99
2003 -V3 Methodology: RIM + Vocabulary + Tooling
24 March,
2004 Early Adopters,
Copyright
2004, HL7 v3 Core to ANSI status
7
2004
–V3
DSTUs,
In Ballot, December 2003
Version 3 Normative:
Clinical Document Architecture, Rel 2
Version 3: Data Types Rel 1 - Abstract
Specification, XML ITS, UML ITS
XML Implementation Technology
Specification - Structures, Rel 1
Medical Records, Rel 1
Regulated Studies, Rel 1,
– Periodic Reporting of Clinical Trial
Laboratory Data
– Annotated ECG
Public Health Reporting, Rel 1
Scheduling, Rel 1
Claims and Reimbursement, Rel 1
Accounting and Billing, Rel 1
24 March, 2004
Common Message Elements, Rel 1
Infrastructure Management, Rel 1
Shared Messages, Rel 1
HL7 Message Transport Spec.
Version 3 DSTU
Patient Administration, Rel 1
Pharmacy, Rel 1
Version 3 Informative or Draft
for comment
Copyright 2004, HL7
Laboratory, Rel 1
Patient Care, Rel 1
Clinical Genomics
Personnel Management
Regulated Studies: Product
Stability Content
8
In Ballot, December 2003, cont.
Version 3 Informative or Draft for
comment , continued
Version 3 Guide
Version 3 Backbone
Attachments for CDA Release 1
Structured Product Labeling
(Drug/clinical products “inserts”)
24 March, 2004
Copyright 2004, HL7
9
V3 Normative Status
Note: some changes underway as negatives are still being resolved…
•
•
•
•
•
•
•
•
•
•
•
•
RIM (March 03)
Refinement and Localization (March 03)
Datatypes: UML ITS, XML ITS, Abstract (ITS Independent)
XML ITS (Message) Structures
Message Transport Specifications (EBXML, WSDL/SOAP)
CMETS (Common Message Element Types)
Shared Messages (Application Acknowledgments)
Infrastructure Management
CDA Release 2
Patient Administration
Medical Records Management
Scheduling
24 March, 2004
Copyright 2004, HL7
Key: Normative, membership, committee, DSTU
10
V3 Normative Status
Note: some changes underway as negatives are still being resolved…
•
•
•
•
•
•
•
•
•
Patient Administration
Personnel Management
Public Health Reporting (notifiable condition, patient safety)
Regulated Studies (annotated ECG, clinical trial lab
observation)
Accounting and Billing
Claims and Reimbursements –REL 1
Lab observations
Pharmacy
CTS: Common Terminology Services
Key: Normative, membership, committee, DSTU
24 March, 2004
Copyright 2004, HL7
11
In ballot opening 24 March
• Common Terminology Services
• Infrastructure Management, Rel 1
• CMETS (Common Message Element Types), Rel 1
• Shared Messages, Release 1 Transport Specification –
MLLP, Rel 1
• Datatypes: UML ITS, XML ITS, Abstract (ITS
Independent)
• XML ITS (Message) Structures XML Implementation
Technology Specification – Data Types, Rel 1
• XML ITS – Structures, Rel 1
Key: Normative, membership, committee, DSTU, as planned– final
ballot may vary from this list
24 March, 2004
Copyright 2004, HL7
12
In ballot opening 24 March
•
•
•
•
•
•
•
•
•
Claims and Reimbursement, Rel 2
Accounting and Billing, Release 1
Laboratory, Rel 1
Pharmacy, Rel 1
Patient Administration, Rel 1
Personnel Management Rel 1
Drug Stability Reporting, Rel 1
Individual Case Safety Report, Rel 1
Notifiable Condition Report, Rel 1
Key: Normative, membership, committee, DSTU, , as planned– final ballot
may vary from this list
24 March, 2004
Copyright 2004, HL7
13
Related ballots opening March 24
EHR Functional Requirements DSTU
Archetype and Template Architecture (1st committee)
CCOW v 1.5 (1st membership)
GELLO (Common expression language standard) (1st committee)
Structured Product Labeling (1st membership) **
Structured Clinical Trial Protocol (1st committee) **
For comment only:
– HL7 Version 3 Standard: Blood Bank, Release 1
XML Implementation Technology Specification – Guide, Release 1
– Study Data Tabulation Model
– ** Based on CDA rel 2 (still at committee level, and not itself in ballot this
cycle)
24 March, 2004
Copyright 2004, HL7
14
HL7 – Collaboration with other organizations
utilizing/building standards
X12N (US: Edifact)
US FDA and US CDISC/
Pharma
DICOM
US Veterans Hospitals
CEN TC 251
ISO TC 215
NIST (US: Nat’l Institute
for Standards and
Technology)
HIMSS/IHE
UK: NHS National “spine”
and GP-to-GP projects
24 March, 2004
Copyright 2004, HL7
15
Agenda
• Introduction to HL7.org
• Why Version 3
• Brief overview of v 3, including support for patient
data: physical measurements
– HL7 RIM – model of clinical information content
– Creating model based message standards with RIM –
Refinement with Constraints
– Producing a simple example
– Lab result example
• How HL7 supports the EHR: Recent trends towards
interoperability.
• Examples of Contributions to version 3 from
International affiliates
24 March, 2004
Copyright 2004, HL7
16
Background: why standard interfaces?
• Some history:
– Back in the early 80’s, people developing distributed
healthcare application systems noted that the number of
interfaces increases as one half of the square of the number
of systems being interfaced. For example:
2 systems, 1 interface
System A
System B
B
3 systems, 3 interfaces
A
24 March, 2004
C
Copyright 2004, HL7
**standard induction proof available on request…or draw your own
17
Background: why standard interfaces?
B
4 systems, 6 interfaces
A
C
D
B
5 systems,
10 interfaces
A
C
E
24 March, 2004
D
Copyright 2004, HL7
**standard induction proof available on request…or draw your own
18
Background: why standard interfaces?
– Notice that the number of interfaces needed increases much
faster than the number of systems
– Those of you who liked algebra in high school may
remember the formula for the “number of combinations of n
things taken r at a time: n!/(n-r)!r!
– For r=2, and arbitrary n, this is n(n-1)/2, which gives**:
Systems:
Interfaces:
3
3
4
6
5
10
24 March, 2004
Copyright 2004, HL7
**standard induction proof available on request…
19
Background: why standard interfaces?
Systems:
6
8
10
20
30
40
50
100
Interfaces:
15
28
45
190
435
780
1225
4950
2
But n(n-1)/2=(n –n)/2 is not maintainable !
24 March, 2004
Copyright 2004, HL7
20
Background: why standard interfaces?
• Note that large organizations in the U.S., such as
Mayo Fdn or Duke typically have between 50-100
such interfaces. The situation is similar for regional or
national systems in Europe
• At a cost of 50-100k per custom interface, it’s clearly
much cheaper to have an interface standard. This
reduces the number of interfaces for n systems to the
cost of (n-1) interfaces, a huge savings.
• This also allows, in most cases, a single interface to be
changed without impacting the others.
• This last feature enables a practical maintenance
approach, as well as a practical systems evolution
approach.
24 March, 2004
Copyright 2004, HL7
21
Remember our 5 systems with 10 interfaces:
B: a Drug Order management System
A
C: A Lab System
D
E
• This actually means that whatever vendor makes “C”, their
internal lab data structures and vocabulary are mapped into
a common (standard) semantic structure. And systems A,
B, D and E all map the standard-defined semantic lab
structures into their internal lab data structures.
• Interfacing means MAPPING to/from Standard semantic
structures.
24 March, 2004
Copyright 2004, HL7
22
Use case for a Reference Information Model
B1: a Drug Order mgmnt System
A1
C1: A Lab System
Lab RIM
D1
E1
B2:
Drug Order
B3: Drug Order
A2
C2: Lab
A3
D2
24 March, 2004
E2
C3:Lab
Copyright 2004, HL7D3
23
E3
Use case for a Reference Information Model
• In other words, at a particular site, Systems A1…E1, a local lab
standard or reference information model will be developed.
• But if that site needs to interoperate with other sites (site 2:
A2…E2, and site 3: A3…E3), there needs to be an overall lab
reference model that each site can map its information into and
out of.
24 March, 2004
Copyright 2004, HL7
24
Use case for a Reference Information Model
• The same is true for other patient related data:
administrative/encounter management, financial, other types of
clinical information. The overall reference model needs to
accommodate each of these domains, with several additional
constraints:
– Non-clinical healthcare-related domains need to be able to use
clinical domain data without it being stored and maintained in
multiple models/structures.
• Thus the non-clinical domain application may need to map its
lab data needs into and out of the common lab reference
model.
• But this is the same concept as our original 5 systems, just on
a much broader scale.
– Vocabulary and identifiers must be coordinated across local
domains.
24 March, 2004
Copyright 2004, HL7
25
The RIM is important “beyond just messaging”
• The HL7 RIM is a mature version of a common
(reference) healthcare applications information
model
– It supports both interfaces and system design
• See not just MDF (message development framework),
but the HDF (health development framework)
• Not just messages, but CDR/E.H.R. applications,
Structured Documents, templates, rules, etc.
• Not just clinical but patient administrative, financial,
public health, genomics
24 March, 2004
Copyright 2004, HL7
26
Additional reasons for Version 3
• Version 2 has no formal information model; the model is
implicit, not explicit.
• Version 2 models are similar to programming language
“structures”, but without formal operations and without
important OO concepts, such as generalizationspecialization hierarchies.
• Version 2 has no formal binding of standard vocabularies to
structures. The bindings are ad hoc and always site specific.
• Version 2 identifier datatypes are insufficient for large-scale
integration.
24 March, 2004
Copyright 2004, HL7
27
Additional reasons for version 3
• Diminishing returns from increased work on 2.X
• Compatibility with previous versions is getting very
heavy
• The tower of Babel, or a New Dark Age
– “Won’t HL7 go away now that we have XML?”
– Niche groups proposing their own style of XML, and
not understanding the difference between the ability to
create an interface between any two systems, versus
creating an standard on which to base interfaces
between “n” systems.
24 March, 2004
Copyright 2004, HL7
28
New capabilities offered in Version 3….
• New capabilities offered in Version 3….
– Top-down message development emphasizing reuse across
multiple contexts and semantic interoperability
– Representation of complex temporal and non-temporal
relationships
– Formalisms for vocabulary support
– Support for large scale integration
• Solving the identifiers problem
• Solving re-use and interoperability across multiple domain contexts
– Creating a uniform set of models
– Expanded scope to include community medicine, epidemiology,
veterinary medicine, clinical genomics, security, etc.
24 March, 2004
Copyright 2004, HL7
29
Semantic interoperability
To understand the data being received you must know
both:
1. The definition of each element of data, and its
relationship with each of the other elements – you
must have a semantic model of the data
and
2. The terminology to be used to represent coded
elements, including the definitions, and relationships
within the terminology
3. The HL7 V3 RIM and associated methodologies
promote and facilitate semantic interoperability
24 March, 2004
Copyright 2004, HL7
30
In sum, how is V3 “better” than v2?
• A conceptual foundation in a single, common
Reference Information Model to be used across HL7
– RIM is in the process of becoming an ANSI and ISO
standard
• A strong semantic foundation in explicitly defined
concept domains drawn from the best terminologies
– Vocabulary-level interoperability
• An abstract design methodology that technologyneutral – able to be used with whatever is the
technology de jour
– Separation of content and syntax
24 March, 2004
Copyright 2004, HL7
31
Agenda
• Introduction to HL7.org
• Why Version 3
• Brief overview of v 3, including support for patient
data: physical measurements
– HL7 RIM – model of clinical information content
– Creating model based message standards with RIM –
Refinement with Constraints
– Producing a simple example
– Lab result example
• How HL7 supports the EHR: Recent trends towards
interoperability.
• Examples of Contributions to version 3 from
International affiliates
24 March, 2004
Copyright 2004, HL7
32
Why do we need a RIM?
• The creation of a ‘reference information model’
for healthcare supports
– The creation of a standard set of structures (models) to
use for the sharing of healthcare information
• And the ability to bind a set of standard
terminologies to these models supports
– The sharing of these standard structures with standard
(coded) names and also
– The extension of the model via structural (coded)
terminology
24 March, 2004
Copyright 2004, HL7
33
Why do we need a RIM?
• Thus (a formal word!), we can create standard
structures (models) with standard names
(codes)
– An ‘ontology of structures’ can be created
• And if we can create sufficiently generic and
granular models in our ontology of structures,
we can map any healthcare application’s
“domain” model into (and out of) the
“reference” model
24 March, 2004
Copyright 2004, HL7
34
Why do we need a RIM?
• Once we have done this for a given application,
(and we only need to do this one time for a
given application), we can re-use the
information from that application in (any) other
healthcare application. This guarantees both
interoperability and re-use of all healthcare
data.
• But how do we do this…?
24 March, 2004
Copyright 2004, HL7
35
Core concepts of HL7 v3 RIM
• The “Act” class and its specializations represent every action of
interest in health care.
• Specifically –
“an action of interest that has happened, can happen, is
happening, is intended to happen, or is requested/demanded to
happen. An act is an intentional action in the business domain
of HL7. Healthcare (and any profession or business) is
constituted of intentional actions. An Act instance is a record of
such an intentional action.)”
24 March, 2004
Copyright 2004, HL7
36
Core concepts of RIM
• Every happening is an Act
– Procedures, observations, medications, supply, registration,
etc.
• Acts are related through an Act_relationship
– composition, preconditions, revisions, support, etc.
• Participation defines the context for an Act
– author, performer, subject, location, etc.
• The participants are Roles
– patient, provider, practitioner, specimen, healthcare facility
etc.
• Roles are played by Entities
– persons, organizations, material, places, devices, etc.
24 March, 2004
Copyright 2004, HL7
37
RIM Class Diagram V1.16 – July 2002
Language_communication
language_cd : CE
mode_cd : CE
proficiency_level_cd : CE
preference_ind : BL
Entity
class_cd : CS
determiner_cd : CS
id : SET<II>
cd : CE
communicates_withqty : SET<PQ>
nm : BAG<EN>
1 desc : ED
status_cd : SET<CS>
existence_time : IVL<TS>
telecom : BAG<TEL>
risk_cd : CE
1..n handling_cd : CE
importance_status_txt : ED
serves
used_by
0..n
plays
is_played_by
0..1
scopes
0..n
is_scoped_by
0..1
1
Role
class_cd : CS
id : SET<II>
cd : CE
negation_ind : BL
addr : BAG<AD>
telecom : BAG<TEL>
status_cd : SET<CS>
effective_time : IVL<TS>
certificate_txt : ED
qty : RTO
position_nbr : LIST<INT>
0..n
0..n
is_target_for
1
Role_link
has_target type_cd : CS
0..n
effective_time : IVL<TS>
is_source_for
has_source
Participation
type_cd : CS
function_cd : CD
context_control_cd : CS
sequence_nbr : INT
note_txt : ED
time : IVL<TS>
mode_cd : CE
awareness_cd : CE
has_as_participant
signature_cd : CS
signature_txt : ED
0..n
for
has
0..n
1
Participation
participates_in
1
Managed_participation
id : SET<II>
status_cd : SET<CS>
Act
class_cd : CS
mood_cd : CS
id : SET<II>
cd : CD
negation_ind : BL
txt : ED
status_cd : SET<CS>
effective_time : GTS
activity_time : GTS
availability_time : TS
priority_cd : SET<CE>
confidentiality_cd : SET<CE>
repeat_nbr : IVL<INT>
interruptible_ind : BL
context_lock_ind : BL
independent_ind : BL
reason_cd : SET<CE>
language_cd : CE
is_source_for
has_source
1
0..n
is_target_for
has_target
1
0..n
Act_relationship
type_cd : CS
inversion_ind : BL
context_control_cd : CS
sequence_nbr : INT
priority_nbr : INT
pause_qty : PQ
checkpoint_cd : CS
split_cd : CS
join_cd : CS
negation_ind : BL
conjunction_cd : CS
originates_in_context_of
1..*
Living_subject
administrative_gender_cd : CE
birth_time : TS
deceased_ind : BL
deceased_time : TS
multiple_birth_ind : BL
birth_order_nbr : INT
organ_donor_ind : BL
0..*
Entity_heir
Organization
addr : BAG<AD>
standard_industry_class_cd : CE
Entity
Material
form_cd : CE
Manufactured_material
lot_nm : ST
expiration_time : TS
stability_time : IVL<TS>
Place
mobile_ind : BL
addr : AD
directions_txt : ED
position_txt : ED
gps_txt : ST
Person
addr : BAG<AD>
marital_status_cd : CE
education_level_cd : CE
ambulatory_status_cd : CE
disability_cd : CE
living_arrangement_cd : CE
religious_affiliation_cd : CE
special_accommodation_cd : SET<CE>
race_cd : SET<CE>
ethnic_group_cd : SET<CE>
Non_Person_living_subject
taxonomic_classification_cd : CE
breed_cd : CE
strain_txt : ED
gender_status_cd : CE
euthanasia_ind : BL
Device
manufacturer_model_nm : ST
software_nm : ST
local_remote_control_state_cd : CE
alert_level_cd : CE
last_calibration_time : TS
Container
capacity_qty : PQ
height_qty : PQ
diameter_qty : PQ
cap_type_cd : CE
separator_type_cd : CE
barrier_delta_qty : PQ
bottom_delta_qty : PQ
Imaging_modality
pixel_intensity_relationship_cd : CE
spacial_resolution_qty : PQ
pixel_padding_qty : PQ
Role_heir
Employee
job_cd : CE
job_title_nm : ST
job_class_cd : CE
salary_type_cd : CE
salary_qty : MO
hazard_exposure_txt : ED
protective_equipment_txt : ED
Certified_entity
recertification_time : TS
Guarantor
credit_rating_cd : CE
Role
Patient
confidentiality_cd : CE
very_important_person_cd : CE
Access
approach_site_cd : CD
target_site_cd : CD
gauge_qty : PQ
Schedulable_resource
slot_size_increment_qty : PQ
served_by
Enitites
Roles
•
•
•
•
•
Infrastructure (Structured
documents)
5
44
192
7
39
Acts (Clinical)
Acts (Financial)
Infrastructure (Message
control)
Billboard produced by:
Rochester Outdoor Advertising
Device_task
parameter_value : LIST<ANY>
Referral
authorized_visits_qty : REAL
Diagnostic_image
subject_orientation_cd : CE
Control_event
: II
Public_health_case
detection_method_cd : CE
transmission_mode_cd : CE
disease_imported_cd : CE
Act_heir
Financial_act
net_amt : MO
Account
nm : ST
currency_cd : CE
interest_rate_qty : RTO<MO,PQ>
allowed_balance_qty : IVL<MO>
Financial_contract
payment_terms_cd : CE
response_cd : CS
Transmission
creation_time : TS
id : II
is_contained_by security_txt : ST
0..*
1
0..n
1..*
Financial_transaction
credit_exchange_rate_qty : REAL
debit_exchange_rate_qty : REAL
interest_rate_qty : RTO
may_have 1
can_include can_accompany
value
Query_event
query_id : II
1
occurs_with
0..1
Clinical_document
set_id : II
version_nbr : INT
completion_cd : CE
storage_cd : CE
copy_time : TS
has_payload
Sort_control
element_nm : ST
sequence_nbr : INT
direction_cd : CS
Primary Subject Areas
Classes
Attributes
Associations
Generalizations
has
occurs_with
0..1
0..n
Message
accept_ack_cd : CS
application_ack_cd : CS
attachment_txt : ED
interaction_id : II
processing_cd : CS
processing_mode_cd : CS
profile_id : SET<II>
sequence_nbr : INT
version_id : ST
is_for
0..n
1
is_acknowledged_by
Query_ack
query_response_cd : CS
message_query_cd : CE
result_total_qty : INT
result_current_qty : INT
result_remaining_qty : INT
Query_spec
execution_and_delivery_time : TS
initial_qty : INT
has
initial_qty_cd : CE
message_query_cd : CE
1
modify_cd : CS
response_modality_cd : CS
response_priority_cd : CS
response_element_group_id : SET<II>
is_part_of
may_contain
0..n
Parameter
has
nm : ST
is_parameter_of
id : II
0..n
0...
0..1
Parameter_list
Query_by_parameter
Parameter_item
value : ANY
semantics_txt : ST
Query_by_selection
1
0..n
is_for
Selection_expression
has_ex pression
Relational_expression
element_nm : ST
value : ST
relational_operator_cd : CS
Table_cell
rowspan : INT
colspan : INT
abbr : ST
axis : ST
headers : SET<ED>
scope : CS
1
has_right_side
1
has_left_side
is_lhs_for
0..n
Table
rules : CS
cellspacing : ST
cellpadding : ST
summary : ST
width : ST
border : INT
frame : CS
Local_attr
name : ST
value : ST
Query_continuation
continuation_qty : INT
start_result_nbr : INT
acknowledges
0..*
Acknowledgement
type_cd : CS
note_txt : ED
error_detail_cd : CE
expected_sequence_nbr : INT
Table_structure
halign : CS
char : ST
charoff : ST
valign : CS
local_id : ST
Table_column_structure
span : INT
width : ST
Link_html
title : ST
name : ST
href : ED
rel : SET<CE>
rev : SET<CE>
Local_markup
ignore_cd : CS
descriptor : ST
render : ST
is_rhs_for
0..n
Logical_expression
relational_conjunction_cd : CS
Copyright 2004, HL7
Invoice_element
modifier_cd : CE
unit_qty : PQ
unit_price_amt : RTO<MO,PQ>
factor_nbr : REAL
points_nbr : REAL
coverage_source_cd : CE
notify_subject_ind : BL
Financial
Acts
is_communicated_as
Attention_line
key_word_txt : ST
: ST
provides_context_for
Act_context
level_cd : CE
Context_structure
local_id : ST
0..1 structure_type_id
executed_by
executes
0..1
Batch
nm : ST
reference_control_id : II
batch_total_nbr : SET<INT>
batch_comment : SET<ST>
transmission_qty : INT
24 March, 2004
Observation
value : ANY
interpretation_cd : SET<CE>
method_cd : SET<CE>
target_site_cd : SET<CD>
derivation_expr : ST
Infrastructure (Structured documents)
Communication_function
type_cd : CS
telecom : TEL
contains
Working_list
ownership_level_cd : CE
Substance_administration
route_cd : CE
approach_site_cd : SET<CD>
dose_qty : IVL<PQ>
rate_qty : IVL<PQ>
dose_check_qty : SET<RTO>
max_dose_qty : SET<RTO>
potency_qty : PQ
substitution_cd : CE
Clinical
Acts
Procedure
method_cd : SET<CE>
approach_site_cd : SET<CD>
target_site_cd : SET<CD>
Assigned_entity
position_cd : CE
primary_care_ind : BL
0..n
Version reflects RIM changes through Harmonization on
03/07/2002 that were approved for implementation following the
release of the second committee-level ballot of Version 3.
Diet
energy_qty : PQ
carbohydrate_qty : PQ
Message Control
0..*
HEALTH LEVEL 7
REFERENCE INFORMATION MODEL
VERSION 1.15 (RIM_0115)
Supply
qty : PQ
expected_use_time : IVL<TS>
Patient_encounter
acuity_level_cd : CE
admission_source_cd : CE
birth_encounter_ind : BL
discharge_disposition_cd : CE
length_of_stay_qty : PQ
pre_admit_test_ind : BL
referral_source_cd : CE
special_courtesies_cd : SET<CE>
urgency_cd : CE
valuables_desc : ED
valuables_location_desc : ED
38
RIM Core Classes & Attributes
Relationship Link
Act Relationship
Type_CD : CS
Effective_TMR : IVL<TS>
Type_CD : CS
0..1
0..*
Entity
Class_CD : CS
CD : CV
Determiner_CD : CS
Status_CD : CS
ID : II
0..1
0..1
0..*
0..*
Role
1
validates
Class_CD : CS
CD : CV
Effective_TMR : IVL<TS>
Status_CD : CS
ID : II
1
1
0..*
Type_CD : CS
TMR : IVL<TS>
Status_CD : CS
0..*
0..*
Act
plays
0..*
1
Participation
0..1
0..*
Class_CD : CS
CD : CD
Mood_CD : CS
Status_CD : CS
Activity_Time : GTS
ID : II
Six kinds of attributes:
type_cd(class_cd), cd, time, mood(determiner), status, id
24 March, 2004
Copyright 2004, HL7
39
How does HL7 manage this abstraction?
• In older HL7 models, each concept had a visible
(physical) class or association to represent it
• In current RIM:
– only include a class when it adds new attributes and
associations
– for the rest, use coded “structural” attributes – ‘class’ or
‘type’ codes
• Why are these named structural attributes?
– because they use codes to represent concepts that would
previously have been part of the model structure.
24 March, 2004
Copyright 2004, HL7
40
RIM Core Attribute Value Sets
Entity
Class Code
• Living Subject
• Person
• Organization
• Material
• Place
• ...
Entity
• Performer
• Author
• Witness
• Subject
• Destination
• ...
Participation
Type Code
Role
1
Participation
1
Act
plays
0..*
Class_CD : CS
CD : CV
Determiner_CD : CS
Status_CD : CS
• Observation
• Procedure
Act
• Supply
• Substance Adm ClassCode
• Financial
• ...
1
Class_CD : CS
CD : CV
Effective_TMR : IVL<TS>
1
0..*
Type_CD : CS
TMR : IVL<TS>
Status_CD : CS
0..*
validates
Class_CD : CS
CD : CD
Mood_CD : CS
Status_CD : CS
Activity_Time : GTS
0..*
Entity
Determiner
Code
• Kind
• Instance
• (Qualified
Group)
24 March, 2004
Role
Class Code
• Patient
• Employee
• Assigned Entity
• Certified Entity
• Guarantor
• ...
Copyright 2004, HL7
• Definition
• Intent
• Order
• Event
• Criterion
• ...
Act
Mood Code
41
Vocabulary Domains and Codes
• Coded attributes in the RIM must be associated with one
and only one Vocabulary Domain prior to being used in a
message specification.
• 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.”
• Each concept in the vocabulary domain is represented
using a code from a specific vocabulary.
• A vocabulary is a defined set of coded concepts.
• A vocabulary may be specified as an enumerated list of
coded concepts (HL7 defined) or as a reference to an
externally maintained list of coded concepts (e.g.,
SNOMED, LOINC, CPT, . . .).
24 March, 2004
Copyright 2004, HL7
42
Agenda
• Introduction to HL7.org
• Why Version 3
• Brief overview of v 3, including support for patient
data: physical measurements
– HL7 RIM – model of clinical information content
– Creating model based message standards with RIM –
Refinement with Constraints
– Producing a simple example
– Lab result example
• How HL7 supports the EHR: Recent trends towards
interoperability.
• Examples of Contributions to version 3 from
International affiliates
24 March, 2004
Copyright 2004, HL7
43
From abstraction to ‘concrete’ concepts
• How can this “skinny” RIM and its codes
represent the large, sophisticated sets of
concepts that must be communicated to support
modern health care?
• Answer: The RIM is the starting point, the
source or pattern, from which specific models
are constructed to define a particular set of
messages.
• The messages are based on RIM-derivatives
known in HL7-ese as Message Information
Models
24 March, 2004
Copyright 2004, HL7
44
Refinement from RIM to Message
24 March, 2004
Copyright 2004, HL7
45
Agenda
• Introduction to HL7.org
• Why Version 3
• Brief overview of v 3, including support for patient
data: physical measurements
– HL7 RIM – model of clinical information content
– Creating model based message standards with RIM –
Refinement with Constraints
– Producing a simple example
– Lab result example
• How HL7 supports the EHR: Recent trends towards
interoperability.
• Examples of Contributions to version 3 from
International affiliates
24 March, 2004
Copyright 2004, HL7
46
Refined Model of Example in Visio
• Development tools for HL7 design committees
• Automation in Visio exports to repository
• Automation on repository auto-generates
Hierarchical Message Description
• HMD-specific tools support addition of further
constraints
• Automatic expression of HMD in XML
24 March, 2004
Copyright 2004, HL7
• XSL converts HMD to Message schemas
47
Message structure from RMIM
2
1
ObservationOrder
class_cd : CS
mood_cd : CS
id : SET<II>
cd : CD
activity_time : GTS
observationOrder
author
0...
3
Author
type_cd : CS
signature_cd : CS
signature_txt : ED
4
PersonPractitioner
class_cd : CS
determiner_cd : CS
certificate
id : SET<II>
subjectPerson
nm : BAG<EN>
1...
telecom : BAG<TEL>
0...
CertifiedEntity
class_cd : CS
id : SET<II>
1... telecom : BAG<TEL>
origination
certifiedEntity
0...
0...
subject
0...
0...
performer
observationOrder
8
Subject
type_cd : CS
1...
9
Patient
subjectOfclass_cd : CS
id : SET<II>
1...
addr : BAG<AD>
patient
0...
patient
10
healthCareProvider
0...
1...
1...
observationOrder
Performer
type_cd : CS
healthCareProvider
0...
performance
1...
5
24 March, 2004
HealthCareProvider
class_cd : CS
id : SET<II>
telecom : BAG<TEL>
6
Person
class_cd : CS
determiner_cd : CS
id : SET<II>
nm : BAG<EN>
telecom : BAG<TEL>
administrative_gender_cd : CE
birth_time : TS
healthCareOrganization
Organization
class_cd : CS
0...
healthCareProviderLicense
1... determiner_cd
7
: CS
id : SET<II>
nm : BAG<EN>
Copyright 2004, HL7
48
HMD expressed in XML
24 March, 2004
Copyright 2004, HL7
49
Message Instance Fragment
24 March, 2004
Copyright 2004, HL7
50
Agenda
• Introduction to HL7.org
• Why Version 3
• Brief overview of v 3, including support for patient
data: physical measurements
– HL7 RIM – model of clinical information content
– Creating model based message standards with RIM –
Refinement with Constraints
– Producing a simple example
– Lab result example
• How HL7 supports the EHR: Recent trends towards
interoperability.
• Examples of Contributions to version 3 from
International affiliates
24 March, 2004
Copyright 2004, HL7
61
HL7 supports the EHR:
Recent trends towards interoperability
• See: www.hl7.org/ehr/
• Electronic Health Record System Functional Model
and Standard.
– The Electronic Health Record SIG has recognized the need
for a common industry standard for EHR functionality that
will serve to set common benchmarks for the industry, to
inform industry stakeholders (patients, providers,
practitioners, payers, etc.) of vital EHR functions and to
qualify EHR systems in terms of completeness and
readiness for adoption.
– 2nd DSTU ballot just announced
– Significant participation from HL7 International Affiliates
24 March, 2004
Copyright 2004, HL7
62
HL7 supports the EHR:
Recent trends towards interoperability
• HL7 Clinical Document Architecture -- Release 2
– Working towards
• complete interoperability with CEN 13606 extracts and openEHR
documents
• CDA Release 2 RMIM supports EHR document concepts
See CDA Release 2 Committee Level Ballot 1 (available at
www.hl7.org) (TC’s and SIGs->structured documents
->documents)
• Recent related developments
– HL7 UK GP to GP project
– RIM Harmonization proposals add Act.classCode values
needed for formally mapping CEN 13606 and openEHR
into v3 RMIMs
• This allowed the creation of an RMIM for CEN 13606/EHRCom (in
process) as a step in this process
24 March, 2004
Copyright 2004, HL7
63
HL7 supports the EHR:
Recent trends towards interoperability
• HL7 templates harmonization project:
– Testing interoperability between HL7 templates, CEN
Entries, and openEHR archetypes by mapping each into v3
RMIM-based models
– Demonstrating formal interoperability between the
3 approaches.
– Go to “www.hl7.org” and select ‘online balloting’ to
download current ballot document
24 March, 2004
Copyright 2004, HL7
64
Some related references
A Shared Archetype and Template Language Part II (A
Position Paper for HL7, CEN TC251, ISO/TC 215,
openEHR and other organisations)
– Available at:
www.deepthought.com.au/health/archetypes/archetype_languag
e_2v0.6.2.doc
– Also, the Archetype Definition Language (ADL) will be
available at this site, and will have the ability to represent
Archetypes as HL7 v3 RMIMs.
24 March, 2004
Copyright 2004, HL7
65
Interoperability:
CDA,
CEN 13606
& openEHR
Interoperability
between
EHR standards
HL7 CDA (rel.2)
HL7 Templates
Harmonisation:
ShARM
Shared Archetypes
Model/Templates
openEHR
CEN ENV 13606
24 March, 2004
Diagram courtesy Dipak Kalra
Reference model
Archetype model
Copyright 2004, HL7
66
Interoperability between EHR standards
Or…have the v3 RIM at the “center”
openEHR Reference Model
CEN 13606
HL7 V3 RIM
Reference Model
HEALTH LEVEL 7
REFERENCE INFORMATION MODEL
RIM_0100
released January 2001 reflects RIM changes through
Harmonization on 11/17/2000
Enitites
Acts (Services)
Roles
Message_control
Entity
id : SET<II>
type_cd : CC
determiner_cd : CS
importa nce_status_txt : ED
Entity_name
Role-role relationships
Appointments &
scheduling
Healthcare_finances
effective_tmr : IVL<TS>
nm : EN
is_for
purpose_cd : CV
Participation
0..*
1
Role
is_played_by
pl ays_a_role
i s_source _of
i s_target_for
1
1
has qty
has_as_particip ant
pa rticipates_in
type_cd : cc
effective_tmr : IVL<TS>
addr : SET<AD>
telecom : SET<TEL>
sends 1..1
shall_receive 1..*
type_cd : CS
tmr : IVL<TS>
0..*note_text : ED
signature_cd : CV
for
function_cd : CD
awareness_cd : CV
0..*
signature_txt : ED
encounter_accommodation_cd : CV
status_cd : CS
0..1
telecom : SET<TEL>
1 desc
0..*
Billboard produced by:
Rochester Outdoor Adv ertis ing
status_cd : CS
has
1
Military_person
Notary_public
notary_county_cd : CE
notary_state_cd : CE
Healthcare_provider
specialty_cd : CV
military_branch_of_service_cd : CV
military_rank_nm : ST
military_status_cd : CV
Act
id : SET<II>
mood_cd : CS
type_cd : CC
txt : ED
status_cd : CS
activity_time : GTS
critical_time : GTS
confidentiality_cd : SET<CV>
max_repeat_nmr : IVL<INT>
interruptible_ind : BL
priority_cd : SET<CV>
orderable_ind : BL
availability_dttm : TS
is_source_for
has_source
1
0..*
i s_target_for
has_target
1
0..*
Act_relationship
type_cd : CS
inversion_ind : BL
s equence_nbr : INT
priority_nbr : INT
pause_qty : PQ
checkpoint_cd : CS
split_cd : CS
join_cd : CS
negation_ind : BL
c onjunction_cd : CS
o ri ginates_i n_context_of
1..*
Place
gps_txt : ST
position_txt
addr : AD
directions_txt
Health_chart
1
Material
form_cd : CV
danger_cd : CE
effective_tmr : IVL<TS>
handling_cd : CE
Organization
org_nm : SET<ON>
s tandard_industry_class_cd : CE
addr : SET<AD>
0. .*
Healthcare_facility
licensed_bed_nbr : REAL
mobile_ind : BL
1
is_site_f or
1
0..*
has_as_target
Person
disability_cd : CE
ethnic_group_cd : CE
race_cd : CE
ambula tory_status_cd : CV
birth_order_nbr : INT
edu cation_level_cd : CV
living_arrangement_cd : CV
marital_status_cd : CV
religious_affiliation_cd : CV
student_cd : CV
credit_rating_cd : CV
addr : SET<AD>
special_ accomm odation_cd : SET<CV>
Non_Person_living_subject
ta xonomic_classification_cd : CE
breed_cd : CE
strain_txt : ED
euthanasia_ind : BL
production_class_cd : CE
gen der_status_cd : CE
h as_as_source
0..*
has_parts
0..1
Patient_encounter
discharge_disposition_cd : CV
acuity_level_cd : CV
birth_encounter_ind : BL
status_reason_cd : CV
classification_cd : CV
encounter_classification_cd : CV
practice_setting_cd : CV
valuables_desc : ED
pre_admit_test_ind : BL
source_cd : CV
special_courtesies_cd : CV
valuables_location_desc : ED
effective_tmr
uses
Access
gauge_qty : PQ
entry_site_cd : CD
body_site_cd : CD
Specimen
body_site_cd : CE
Manufactured_material
expiration_dttm : TS
lot_nbr : ST
1
com municates_in
0. .*
Person_Language
1
is_specif ied_by
Clinical_document_header
availa bility_status_cd : CV
chan ge_reason_cd : CV
com pletion_status_cd : CV
confidentiality_status_cd : CV
content_presentation_cd : CV
docum ent_creation_dttm : TS
file_nm : ST
las t_edit_dttm : TS
reporting_priority_cd : CE
results_report_dttm : TS
storage_status_cd : CV
transcription_dttm : TS
document_change_cd : CV
version_nbr : INT
version_dttm : TS
Consent
Procedure
entry_site_cd : SET<CD>
method_cd : SET<CV>
body_site_cd : SET<CD>
form_cd : CD
route_cd : CD
dose_qty : PQ
s trength_qty : PQ
rate_qty : PQ
dose_check_qty : PQ
method_cd : SET<CV>
body_site_cd : SET<CD>
subs titution_cd : CV
Document_service
completion_cd : CV
set_id : II
storage_cd : CV
version_nbr : INT
copy_dttm : TS
origination_dttm : TS
energy_qty : PQ
carbohydrate_qty : PQ
effective_tmr : IVL<TS>
reason_cd : CE
status_dttm
Act_context
level_cd
Message_interaction
is_ communi cated_as
Observation
value : ANY
derivation_expr : ST
method_cd : SET<CV>
body_site_cd : SET<CD>
interpretation_cd : SET<CS>
0..1
Healthcare_benefit_product_policy
Diagnostic_related_group_definition
Patient_billing_account
assignment_of_benefits_ind : BL
base_rate_qty : MO
adjustment_cd : CV
benefit_product_desc : ED
capital_reimbursement_qty : MO
certification_required_ind : BL
benefit_product_nm : ST
cost_weight_qty : MO
current_unpaid_balance_qty : MO
benefit_product_type_cd : CE
major_diagnostic_category_cd : CE
expected_insurance_plan_qty : REAL
benefits_coordination_ind : BL
operating_reimbursement_qty : MO
expected_payment_source_cd : CV
cob_priority_nbr : REAL
reimbursement_qty : MO
notice_of_admission_dttm : TS
combine_baby_bill_ind : BL
standard_day_qty : PQ
notice_of_admission_ind : BL
group_benefit_ind : BL
standard_total_charge_qty : MO
patient_financial_class_cd : CV
mail_claim_party_cd : CE
trim_high_day_qty : PQ
price_schedule_id : II
release_information_cd : CE
trim_low_day_qty : PQ
report_of_eligibility_dttm : TS
status_cd : CS
retention_ind : BL
coverage_type_cd : CE
1
def ines
signature_on_file_dttm : TS
agreement_type_cd : CE
special_program_cd : CV
policy_category_cd : CE
is_def ined_by
0. .*
stoploss_limit_ind : BL
access_protocol_desc : ED
suspend_charges_ind : BL
Encounter_drg
total_adjustment_qty : MO
approval_ind : BL
total_charge_qty : MO
confidential_ind : BL
total_payment_qty : MO
cost_outlier_qty : MO
separate_bill_ind : BL
des c : ED
grouper_review_cd : CE
bad_debt_recovery_qty : MO
Champus_coveragebad_debt_transfer_qty : MO
grouper_version_id : II
Practitioner_Certifier
Employee_Employer
Patient_Provider
0..*
Practitioner_provider
position_cd : CV
primary_care_ind : BL
0. .*
is_sited_at
Encounter_facility_association
effective_tmr : IVL<TS>
status_cd : CS
transfer_reason_cd : CV
addr : SET<AD>
hazard_expos ure_txt : ED
job_class_cd : CV
job_title_nm : ST
telecom : SET<TEL>
protective _equipment_txt : ED
s alary_qty : MO
salary_type_cd : CV
status_cd : CS
job_cd : CE
board_certification_type_cd : CV
certification_dttm : TS
recertification_dttm : TS
residency_field_cd : CE
Unmapped_financial_classes
(from R IM_Heal thcare_finances)
Outbreak
tmr
0..1
i s_u sed_by
authori zes
Preauthorization
authorized_encounters_qty : REAL
authorized_period_begin_tmr : IVL<TS>
id : II
issued_dttm : TS
requested_dttm : TS
restriction_desc : ED
status_cd : CS
status _change_dttm : TS
Insurance_certification
certification_duration_qty : PQ
effective_tmr : IVL<TS>
id : II
insurance_verification_dttm : TS
modification_dttm : TS
non_concur_cd : CE
non_concur_effective_dttm : TS
penalty_qty : MO
report_of_eligibility_dttm : TS
report_of_eligibility_ind : BL
0..*
1
has_cov erage_af f irm ed_by
Guarantor_contract
billing_hold_ind : BL
: CE
charge_adjustment_cd : CE
contract_duration_cd : CE
contract_type_cd : CE
effective_tmr : IVL<TS>
interest_rate_nbr : REAL
periodic_payment_qty : MO
priority_ranking_cd : CV
af f irms_insurance_cov erage_f
or
billing_media_cd
Billing_information_item
condition_cd : CE
occurrence_cd : CE
occurrence_dttm : TS
occurrence_span_cd : CE
occurrence_span_from_dttm : TS
occurrence_s pan_thru_dttm : TS
quantity_nbr : REAL
quantity_type_cd : CV
value_amt
value_cd : CE
0..*
HL7 CDA,
Rel 2
24 March, 2004
Diagram courtesy Peter Schloeffel
0..*
File_of_batch
has_payl oad
0..*
has_recipient
Message
sending_application_id : II
0..* id : SET<II>
has_sender
Batch
control_id : II
name : ST
creation_dttm : TS
reference_control_id : II
sending_application_id : II
receiving_application_id : II
security : ST
message_count : INT
0..1batch_totals : SET<INT>
is_contained_by
contains batch_comment : SET<ST>
0..*
creation_dttm : TS
interaction_id : II
version_id : ST
can_i ncl ude
profile_id : SET<OID>
1
process ing_cd : CV
sequence_nbr : INT
reply_to_com : TEL
has
receiving_application_id : SET<II>
processing_mode_cd
1
attachment_txt : ED
1
has
has
0..*
Query
0..1
has
occurs_wi th
1
is_for
0..*
contains
applies_to
Query_by_selection
is_response_with
1
1
has
contains
1
TBL_response_control
h as_response
1
has
0. .*
is _f or
1
has
ret urns_to
has_response
is_response_with
0..*
Tabular_row_data
Copyright 2004, HL7
1
1
Query_spec_message_type
occurs_with
Query_ack
Query_by_parameter
Element_response_control
name : SET<CV>
Query_response_message_type
0. .1
mess age_query_name : CV
query_tag : II
priority : CV
modify_indicator : CV
execution_an d_delivery_time : TS
1
Response_control
q uantity_limited : PQ
respons e_modality : CV
0. .1 acknowledges
1. .*
type_cd : CV
note_txt : ED
error_detail_cd : CV
expected_sequence_nbr : INT
query_tag : II
query_status_cd : CV
mess age_query_name : CV
hit_count_total : INT
hit_count_current : INT
hit_count_remaining : INT
0..*
key_word_txt : ST
value : ST
1
occurs_with
Acknowledgement
1
has
is_contained_by
control_id : II
name : ST
creation_dttm : TS
reference_control_id : II
sending_application_id : II
receiving_application_id : II
contains
security : ST
file_batch_count : INT
0..1
file_comment : SET<ST>
Attention_line
can_accompany
TBL_sort_control
name : ST
direction : CV
1
applies_to
1. .*
0..1
is_fa ther_to
Selection_criteria
0. .*
Response_field
field_id : ST
data_type : CV
length : INT
0. .*
is _f or
Element_sort_control
element_name : ST
direction : CV
Healthcare_benefit_coverage_item
service_category_cd : CV
service_cd : CE
servic e_modifier_cd : CE
authorization_ind : BL
network_ind : BL
assertion_cd : CE
covered_parties_cd : CE
qty : REAL
quantity_qualifier_cd : CE
time_period_qualifier_cd : CE
range_low_qty : PQ
range_high_qty : PQ
range_units_cd : CV
eligibility_cd : CE
policy_source_cd : CE
eligibility_source_cd : CE
copay_limit_ind : BL
handicapped_program_cd : CE
non_avail_cert_on_file_ind : BL
retirement_dttm : TS
s tation_id : II
outlier_days_nbr : REAL
outlier_reimbursement_qty : MO
outlier_type_cd : CV
Public_health_case
de tection_method_cd
trans mission_mode_cd
dis ease_imported_cd
1
manages
is_managed_by
Clinical_document
Supply
qty : PQ
Transportation
Diet
Schedule
Resource_slot
status_cd : CS
time_slot : GTS
Device
manufacturer_model_nm : ST
las t_calibration_dttm : TS
software_nm : ST
local_remote_control_state_cd : CE
alert_level_cd : CE
0..*
1
is_authorized_by
status_cd : CS
slot_s ize_increment_ qty
0. .*
Language_ability
Container
capacty_qty : PQ
height_qty : PQ
diameter_qty : PQ
barrier_delta_qty : PQ
bottom_delta_qty : PQ
s eparator_type_cd : CD
cap_type_cd : CD
is_ut ilized_during
util i zes
i s_ part_of
Inpatient_encounter
mode_cd : CV
proficiency_level_cd : CV
ownership_level_cd
Referral
authorized_vis its _qty : REAL
des c : ED
reason_txt : ED
1
0..*
length_of_stay_qty : PQ
is_comm unicat ed_by
specif ies_abilit y _in
Role_relationship
type_cd : CC
effective_tmr : IVL<TS>
id : SET<II>
status_cd : CS
responsibility_cd : SET<CE>
position_nbr : LIST<INT>
qty : PQ
certificate_txt : ED
Medication
Working_list
is_assessed_against
Health_chart_deficiency
assessment_dttm : TS
desc : ED
level_cd : CV
type_cd : CV
Financial_act
prov ides_context_f
or
0..*
Individual_healthcare_practitioner
fellowship_field_cd : CE
graduate_school_nm : ON
graduation_dttm : TS
board_certified_ind : BL
has_an_assessm ent_of
Living_subject
birth_dttm : TS
deceased_dttm : TS
deceas ed_ind : BL
administra tive_gender_cd : CE
organ_donor_ind : BL
mu ltiple_birth_ind : BL
name : ST
0..*
relational_operator_cd : CV
is_son _of
value : ST
relational_conjunction_cd : CV
67
Financial_transaction
extended_qty : MO
fee_schedule_cd : CE
insurance_qty : MO
posting_dttm : TS
qty : MO
transaction_batch_id : II
unit_qty : MO
unit_cost_qty : MO
Agenda
• Introduction to HL7.org
• Why Version 3
• Brief overview of v 3, including support for patient
data: physical measurements
– HL7 RIM – model of clinical information content
– Creating model based message standards with RIM –
Refinement with Constraints
– Producing a simple example
– Lab result example
• How HL7 supports the EHR: Recent trends towards
interoperability.
• Examples of Contributions to version 3 from
International affiliates
24 March, 2004
Copyright 2004, HL7
68
The v3 Tools Taskforce
• Chaired by Laura Sato
– HL7 UK, formerly HL7 Canada
• Some major contributors from the HL7
Affiliates include:
– Charlie McKay, HL7 UK (VISIO and
documentation extensions)
– Lloyd Mckenzie, HL7 Canada
• HL7 VISIO tools (current)
• MIF (HL7 v3 XML Model Interchange Format)
24 March, 2004
Copyright 2004, HL7
69
V3 tools taskforce
• In process to become a Board-appointed HL7 Tools
Committee with a formal Mission and Charter
statement
• Current projects include papers on:
– An overview of the HL7 tools Model Interchange Format
(MIF)
– A proposal/plan for HL7 Requirements, Configuration and
Deployment Management
– A proposal/plan for HL7 Product Evaluation and
Recommendation
– HL7 Tools Architecture and Policy Framework
24 March, 2004
Copyright 2004, HL7
70
V3 tools taskforce
A major revision (from HL7 UK) to the design
tools will be made available to HL7 in the next
several months, including some (tbd) of:
– Design Repository (with check-in-out functions,
designs in Model Interchange Format)
– Automated model comparison tool (MIF Diff)
– Message Schema Validation
– One-click round trip from VISIO to/from Schema
– Automate Visio validation to test specifications for
completeness
24 March, 2004
Copyright 2004, HL7
71
V3 tools taskforce
– Other affiliate projects include:
• MIF design and implementation (current) (Lloyd
McKenzie and others)
– Allows interoperability with Off The Shelf UML xml-based
tools, plus interoperability between various HL7 v3 tools
(encourages the development of new v3 tools)
• CMET-related features/functionality enhancements
Project
– Lloyd McKenzie and Ben van de Walle, also of HL7 Canada
24 March, 2004
Copyright 2004, HL7
72
Localization & Refinement principles
Once an HL7 specification has been balloted and
formally published, it may be further constrained
for a variety of purposes, including:
– definition of a region-specific profile by an HL7
International Affiliate
– documentation of a profile for use in communities of
interest (for example, a set of collaborating health
care institutions, a community of vendors or an
external standards organization)
– definition of a profile for a specific project
– creation of profiles to define a vendor's capability or
a consumer's requirements
– definition of content templates to be used when
communicating HL7 messages
24 March, 2004
Copyright 2004, HL7
73
“realm” specific “localizations”
• The HL7 Affiliate Organizations, working
through the International Committee,
studied localization and produced a report
entitled "Localizing the HL7 Version 3
Standard."
• This report, which has been reviewed and
adopted by the HL7 Board of Directors for
use by the affiliate organizations, is the
basis for this part of the v3 ballot (and is
now normative).
24 March, 2004
Copyright 2004, HL7
74
realm-specific profiles
• These can be created via an Affiliate process that
includes both the constraint process listed above,
and an extension process that adds new concepts
to the base, balloted message type
– extensions must be produced by the same
constraint processes that generates messages,
CMETS, vocabulary restrictions from the RIM (and
its vocabulary), and datatype constraints (under
development)
– affiliate-level ballot and registration requirements
are defined
• consistent with affiliate agreement and HL7 v3
methodology
• Useful, global concepts are encouraged to be brought
back into ‘global’ HL7 v3
24 March, 2004
Copyright 2004, HL7
75
realm-specific profiles
•
informal extensions are allowed at the
ITS (implementation technology
specification) only.
–
–
–
They cannot alter the intent of the standard message
There must exist a site-specific agreement
The ITS must support their “isolation” within the
message
24 March, 2004
Copyright 2004, HL7
76
Localization & Refinement principles
Summary: For “International” affiliates.
– Vocabulary Realm concepts for
• Vocabulary domains for specific attributes (e.g. Act.code)
– In addition to localizations for
• ‘abstract information artifacts’ such as
– RMIMS
– HMDS (Hierarchical Message Definitions)
– MTs (Message Types)
– A web-based EB-XML registry is being created for both
HL7 “global” and “affiliate” profiles, as well as “early
adopter” profiles
24 March, 2004
Copyright 2004, HL7
77
Early Adopters Forum
• Administered by the Implementation Committee (see
below)
• Encourages v3 early adopters to share experiences
– Lessons learned in specific domains
– Problem-solving for common areas and specific areas
– Suggestions for additions to the v3 global ‘core’
• Includes
– Email list
– Presentations to various TCs and SIGs at the HL7 WG
meetings
– Use of EBXML Registry for conformance artifacts
• Also includes many international affiliate projects (see
below)
24 March, 2004
Copyright 2004, HL7
78
V3 Implementation committee
• A focus is “v3 for implementors”
• Projects being discussed include:
– Creating v3 implementation documents
• Current v3 materials are ‘v3 for message designers’
• focus on how to understand and use the v3 XML-ITS for
message implementors, with examples from Early
Adopters Forum
– creating v3 conformance methodology guide (like
the corresponding v 2.x guide)
• Will include many affiliate projects (see below)
24 March, 2004
Copyright 2004, HL7
79
Contributions from International affiliates
V3 ballot major contributions include
• Infrastructure areas
– Datatypes (Australia), Queries (The Netherlands), EBXML
transport specification (Canada), XML-ITS (UK)
• Claims and reimbursements (e-claims) (Canada)
• Pharmacy messaging and vocabulary (United
Kingdom)
• Vocabulary (“realm” specifications and balloting
procedures) (all affiliates)
• XML ITS (Australia, Canada, Germany, United
Kingdom)
24 March, 2004
Copyright 2004, HL7
80
Contributions from International affiliates
V3 ballot major contributions include
• EHR Functional Requirements
– Affiliates include: UK, Canada, Australia, and
“USA”
• CDA release 1 and 2 (under development)
– Germany, Finland, Greece, “USA”
24 March, 2004
Copyright 2004, HL7
81
AffiliateV3 implementation projects
A partial list:
• Australia:
– patient care and referrals, V3 technical infrastructure
• Canada: e-claims, V3 tools
– BCE Emergis: v3 e-claims live implementation for
Chiro/Physio Claims for WSIB (Ontario Workers Comp),
patient (client) and provider registries, Clinical Pharmacy,
BC Lab Orders/Results (under development),
• UK:
– NPfit: National “Spine” ECR supporting E-booking, Eprescribing, lab requests and reports, images, allergies,
problems, current medications, etc.
• Germany, Finland, the Netherlands, Greece:
– Clinical Document Architecture
24 March, 2004
Copyright 2004, HL7
82
AffiliateV3 standards projects
A partial list:
• Argentina, Mexico, Spain:
– Spanish translation begun, web-based education
• Mexico
– Blood Bank
• The Netherlands:
– Perinatal Project, National Patient Registry, National
Electronic Patient Record, Query and scheduling
infrastructure (under development)
• USA
– Public Health Reporting, Adverse events, Annotated EKG
24 March, 2004
Copyright 2004, HL7
83
Notes on the Transition to v3
• Current ‘lessons learned include
– Existing v 2.x implementations: “if it ain’t broke, don’t fix
it”
– But for new domains, start with v3
– For implementations requiring large scale integration (city,
region, province, nationwide, international), v3 has ‘builtin’ support
• Structural ontology guaranteeing interoperability and re-use: RIM
and datatypes, integrated vocabulary support
• Identifier strategy supporting wide integration
• Model and Tools based design and implementation
– If you need decision support, you’ll need v3
• The same information is represented the same way everywhere
using the RIM with the binding to structural and standard
vocabularies
24 March, 2004
Copyright 2004, HL7
84
Notes on the Transition to v3
• Translation from v 2.x: lessons learned
– It is possible, and often desirable when existing v 2.x data is
needed for a v3-based project
– But it requires resolving the ambiguities inherent in v 2.x
implementations;
– If the MWB conformance profile exists already, that is a
significant advantage, though it will not completely resolve
the v 2.x model and vocabulary ambiguities
– You’ll need to resolve the same wide-scale implementation
issues as needed for v3:
• Vocabulary bindings (structural and standard)
• Datatypes and identifiers
– A quote from the field:
“I never fully understood v2.x until I understood v3”
(in the context of a project mapping a 2.x conformance specification
into a v3 conformance specification)
24 March, 2004
Copyright 2004, HL7
85
Of related international interest:
HL7 and IHE
For HIMSS 2004, HL7 and IHE cooperated on a very
successful joint interoperability demo. There are plans
to internationalize this demo after HIMSS 2004.
URLs:
• On www.hl7.org page under resources, select “HL7
IHE Joint Demo 2004”
• Or go directly to http://129.41.58.87/html/index.htm
24 March, 2004
Copyright 2004, HL7
86
HL7/IHE Joint Demo HIMSS 04
The joint demonstration planned to feature healthcare scenarios
such as:
•
identifying an adverse drug event and preventing medication
errors
•
notifying the Food & Drug Administration and sponsors of
clinical trials
•
viewing clinical reports with links to related images,
•
integrating electronic records with public health reports
•
driving the capture of patient charges, billing and claims
attachments from clinical observations
24 March, 2004
Copyright 2004, HL7
87
…finis…
• Questions?
• Thank you!
24 March, 2004
Copyright 2004, HL7
88
Part II: Using v3
• A practical overview of the RIM and the
version 3 methodology and Design tools.
• Browsing the RIM: Rosetree example,
including Structural Vocabulary
• Alternate representations of the RIM in the v3
ballots:
– Graphical
– Textual
– Vocabulary
24 March, 2004
Copyright 2004, HL7
89
A walk through a version 3 ballot
• Overall organization
– Informative documents on v3
– Where to find things
• Standard Table of contents
• DMIMS and RMIMS, HMDS and Message Types,
Schemas
• Interactions
– A very quick tour of the datatypes
– Common (message) element types -- reusable
model patterns (and their relationships to message
and API models, and to archetypes and templates)
24 March, 2004
Copyright 2004, HL7
90
Visio Designer
• A walk through the Visio tools, featuring:
– A look at an RMIM or two, such as:
• Observation DMIM/CMETS/Event
• CDA-Release 2/Clinical statements
24 March, 2004
Copyright 2004, HL7
91
Questions/Discussion topics
• If time permits:
– When is v3 “done”?
– How do I represent a new domain in v3? (MDF/HDF
process)?
– What changes can an affiliate make to the global standard?
– What about Vocabulary in different countries/jurisdictions?
– What are the implementation/development considerations
– How can I learn from the early adopters program?
24 March, 2004
Copyright 2004, HL7
92
Where can I get these tools?
• See companion notes in:
v3materials.instructions.march.2004.doc
24 March, 2004
Copyright 2004, HL7
93
THANK YOU!
• Are there any last questions?
--send them to:
[email protected]
24 March, 2004
Copyright 2004, HL7
94