Transcript No Slide Title

Version 3 Intermediate Tutorial Working the HL7 Version 3 Methodology
George W. Beeler, Jr., Ph.D.
Past-Chair, Health Level Seven Board
Chapter editor, HL7 Version 3 methodology
Division Chair
Information Services
Mayo Clinic
Rochester, MN USA
[email protected]
May 16, 2000
© 2000, HL7
1
Where are we going?
Objective: Present the material needed to be able to “walk
the walk” in Message Design from end-to-end.
1. Data types
Refresher
- Why do we care?
2. Vocabulary
Reading
a UML model
3. Structure of
a message
Vocabulary,
codes
and terminology
4. Reading
UML model
Data
types, astructure
and objectives
5. Readingofan
R-MIM and an HMD.
Structure
a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
2
Our agenda
Refresher - Why do we care?
Version 3 basics
Overview of RIM
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
3
What is computer interoperability?
• Although an intuitive answer is easy, a specific
response is more complex
• Institute of Electrical and Electronics Engineers (IEEE)
dictionary:
"The ability of two or more systems or components
to exchange information and to use the information
that has been exchanged.”
[IEEE Standard Computer Dictionary: A Compilation of IEEE Standard
Computer Glossaries, IEEE, 1990]
Functional
interoperability
May 16, 2000
Semantic
interoperability
© 2000, HL7
4
What must be specified for communication?
HL7 specifications
Nouns
Adjectives
Verbs
Things or entities that are
being communicated.
Descriptors and
relationships of the nouns.
Actions being requested
or communicated.
The semantics of the communication
The semantics convey the actual "meaning" of the message. The semantics is conveyed
via a set of symbols contained within the communication. An external "dictionary",
thesaurus, or terminology explains the meaning of the symbols as they occur.
A syntax for communication
The syntax defines the structure and layout of the communication. Common syntax
representations include ASN.1, XML, X.12, HL7, IDL, etc.
Services to accomplish the communication
Examples include the post office, a telephone switchboard, SMTP, FTP, Telnet, RPC, ORB
services, etc.
A channel to carry the communication
Examples of channels include written documents, telephones, network connections, satellite links,
etc.
May 16, 2000
© 2000, HL7
5
HL7 Version 3 Characteristics
• Design based on consensus Reference
Information Model - ties message elements to
explicit semantic definitions
• Adaptable to current and future technology
bases - requires abstract expression of
standard data structure
• Vocabulary-level interoperability - requires
robust data type(s) for coded data
• Explicit conformance model - means that
optional elements in the specification must be
eliminated where ever possible
May 16, 2000
© 2000, HL7
6
HL7 Version 3 Methodology in words
1. Define a consensus reference information model (RIM) that defines
the data of interest in the healthcare domain.
2. Assemble the terminologies and data types necessary to express the
attributes of the RIM
3. Apply the model, vocabulary and types to:
messages, patient record DTDs, medical logic modules,
component specifications, etc.
4. For any particular application, draw from the RIM to construct an
abstract message structure - the Hierarchical Message Description
(HMD)
5. For any particular implementation technology, HL7 will define an
implementation technology specification (ITS) for mapping the
HMD to that technology.
6. When the message (or equivalent) is sent, the HMD is used to
marshal the data, and the ITS is used to format the data for
communication.
May 16, 2000
© 2000, HL7
7
RIM Class Diagram - v0.96
Legend
Stakeholders Patient Encounters
Data Types
types
Data
Stakeholder
Scheduling
Organizations
Affiliations
Appointments
Insurance
Person
Patient
USAM
USAM
Encounter
Service Provider
Service
Message
Message
control
Episode
Accounting
Finance
May 16, 2000
Doc.
Document
Roles
Location
Material
Material
Material
© 2000, HL7
8
RIM Class Diagram - v0.96
Stakeholders Patient Encounters
Legend
Stakeholder
Scheduling
Organizations
Affiliations
Data types
Appointments
Insurance
Person
Patient
USAM
Encounter
Service Provider
Service
Message
control
Episode
Accounting
Finance
.
May 16, 2000
Doc.
Document
Roles
Location
Material
Material
© 2000, HL7
9
Current 0.96 RIM Statistics
• 110 Classes
• 532 Attributes
• 167 Association Relationships
• 30 Inheritance Relationships
• 2 Aggregation Relationships
• 37 Subject Areas
– 18 Domain, 8 Work-in-Progress, 12 Administrative
• 43 Data types
• Maintained in an Access database, expressed in UML, and
annotated with a literary expression.
May 16, 2000
© 2000, HL7
10
Our agenda
Refresher - Why do we care?
Reading the RIM
HL7’s use of UML
Unified Service Action Model (USAM) in the RIM
USAM structural codes
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
11
Information Modeling Language
• Class defines things
Name “compartment” of class
Patient
name
: PN
DOB
: Date
address : AD
May 16, 2000
– represents important concepts
of your domain
– concepts = things and ideas that
exist in your business
– important = subject of multiple
transactions
– like the definition of a data base
“record”
Attribute “compartment” of class
• attributes are the data we record about
the things of interest
• attributes are values that exist only with
with respect to the class.
• attributes have a name and a data type
• like the definition of a data field in a data
base record
© 2000, HL7
12
Information Modeling Language
• Class defines things
• Objects are instances
– individuals of which classes are
a definition
– have values assigned to
attributes
– have identity that’s invariant
when other values change
– like the “records” of a data base
Patient
name
: PN
DOB
: Date
address : AD
May 16, 2000
Patient
name = John Doe
Patient DOB = 10-Apr-1966
address
= Calgary
name = Jane
Smith
DOB = 1-Oct-1956
Patient
address = Toronto
name = Bart Simpson
DOB = 5-Sep-1975
address = Springfield
© 2000, HL7
13
Information Modeling Language
• Class defines things
• Objects are instances
“Association role name”
• Associations relate things
– describe the way things relate
to other things
Patient
name
: PN
DOB
: Date
address : AD
0..*
provides care for
Doctor
name
: PN
1..* specialty : CD
phone
: TEL
seeks care at
cardinality or “multiplicity”
• specifies how many such association instances
each object instance can/must have
May 16, 2000
© 2000, HL7
14
Information Modeling Language
• Class defines things
• Objects are instances
• Associations relate things
– describe the way things relate
to other things
“Reading” associations in plain English:
Patient
name
: PN
DOB
: Date
address : AD
0..*
provides care for
Doctor
name
: PN
1..* specialty : CD
phone
: TEL
seeks care at
“Every Patient … seeks care at … 1 to many … Doctors”
“Every Doctor … provides care for ... zero to many … Patients”
May 16, 2000
© 2000, HL7
15
Information Modeling Language
• Class defines things
• Objects are instances
• Associations relate things
• Associative classes add
properties to relationships
– attributes about association
– more relationships
Patient
name
: PN
DOB
: Date
address : AD
0..*
provides care for
Doctor
name
: PN
1..* specialty : CD
phone
: TEL
seeks care at
Encounter
type
: CV
time
: IVLTS
reason : CD
May 16, 2000
© 2000, HL7
16
Information Modeling Language
• Class defines things
• Objects are instances
• Associations relate things
• Associative classes add
properties to relationships
– attributes about association
– more relationships
Patient
name
: PN
DOB
: Date
address : AD
May 16, 2000
0..*
1
Encounter
type
: CV
time
: IVLTS
reason : CD
© 2000, HL7
1
1..*
Doctor
name
: PN
specialty : CD
phone
: TEL
17
Information Modeling Language
• Class defines things
• Objects are instances
Person
name
: PN
DOB
: Date
address : AD
• Associations relate things
• Associative classes
• Generalization classes
Patient
gender : CD
donor : BL
V.I.P.
: BL
0..*
1
Encounter
type
: CV
time
: IVLTS
reason : CD
1
1..*
Doctor
specialty : CD
phone
: TEL
privileges: CV
• Generalization classes can simplify the model
– through reuse of common concepts
– express logical truths of the application domain
– work the other way as “specialization classes”
May 16, 2000
© 2000, HL7
18
Information Modeling Language
• Class defines things
• Objects are instances
Person
name
: PN
DOB
: Date
address : AD
• Associations relate things
• Associative classes
• Generalization classes
• Reflexive associations
Patient
gender : CD
donor : BL
V.I.P.
: BL
0..*
1
Encounter
type
: CV
time
: IVLTS
reason : CD
1
1..*
Doctor
specialty : CD
phone
: TEL
privileges: CV
0..1
follow-up
0..1
• Reflexive associations structure instances of one class
– chain (predecessor-successor,) hierarchy (parent-child,) or network
May 16, 2000
© 2000, HL7
19
last_modified_date : Date
modelID : NameString
1
name : NameString
1
version_number : VersionNumber
TSC_approval_date : Date
Version 3 Meta-model for RIM
maintains 0..1
1
has
has
has
http://www.hl7.org/library/data-model/met/modelpage.html
has
1
in
0..*
maintained_by 0..*
includes
0..*
holds
0..1
0..*
is_nested_in
Association
name : NameString
inverse_name : NameString
source_multiplicity : MultiplicityString
target_multiplicity : MultiplicityString
description : DescriptiveText
history : CompoundHx
1
0..*
has_source
0..*
has_target
in
1
0..*
Application_role
in
0..*
1..*
Subject_area
description : DescriptiveText
history : CompoundHx
name : NameString
0..1
nests
0..*
has
in
in
0..*
Class
included_in
0..*
includes
1..* name : NameString
1
0..*
Trigger_eve
primarily_resides_in
description : DescriptiveText
Use_case
is_super_type
1 isAbstract : Boolean
relates_to
1
is_source
history : CompoundHx
1..*
0..1
is_subtype
0..* 0..*
1
1
is_target
identifies aff
describes describes
1
1
1
0..1 has
is_composite
has_subtype has_super_type
is_part
0..*
0..*
has_alias
Generalization_relationship 1
0
include
description : DescriptiveText
included_in
history : CompoundHx
names
MIM_class
appears_in
0..*
Alias_name
name : NameString
use : Enumerated
history : CompoundHx
subject_of
subject_of
1 0..1
has_composite
Subject_class has
Composite_aggregation
included_in
0..*
1
composite_to_part_phrase : NameString 0..*
captured_in identified_b
has_part
names
is_start_of
starts_from
1
0..1
description : DescriptiveText
0..*
0..1
is_driven_by
1..*
0..*
0..* in
1
history : CompoundHx
State_transition
part_multiplicity : MultiplicityString
has_state_attribute
State
part_to_composite_phrase : NameString
description : DescriptiveText
description : DescriptiveText
has_alias
history : CompoundHx
history : CompoundHx
0..1
0..*
label : NameString
name
:
NameString
1
predicate : String
Attribute
0..*
included_in
is_substate_of
0..*
in
name : NameString
1
0..1
is_state_attribute_for
description : DescriptiveText
1
1
ends_in
ends
has_substate
inclusion : Boolean
1
0..* MIM_attribute
included_in
included_in
history : CompoundHx
includes
based_on
repeatability : Boolean
0..*
constrained_by
constrains
0..*
Attribute_domain_constraint
is_of_type
types
0..1
0..*
0..1
0..*
0..*
is_source_for
Attribute_type
is_of_type
Data_type
0..*
types
implemented_by implements
had_V23_type
1..*
1..1
V23_fields
0..1
V23_data_type
typed
1
May 16, 2000
Single inheritance only
Mutually exclusive inheritance
No association classes
Associations named in each direction
© 2000, HL7
20
Our agenda
Refresher - Why do we care?
Reading the RIM
HL7’s use of UML
Unified Service Action Model (USAM) in the RIM - basics
USAM structural codes
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
21
USAM
• USAM
– is the Unified Service Action Model
– has been introduced to the RIM in stages over the last 24
months
– binds the core concepts underlying clinical care and patient
management into a unified set of classes
– defined by classes plus “structural codes” -- coded attributes
that represent what otherwise might be a RIM structural
relationship
– published in RIM and document “The Unified Service Action
Model -- Documentation for the clinical Area of the HL7
Reference Information Model”
http://www.hl7.org//Library/data-model/Support_material/Usam_2_6.pdf
May 16, 2000
© 2000, HL7
22
Health Care Services are:
• what patients seek, to improve or maintain health
• what physicians, nurses, and other providers offer
• what produces information (observation!)
• what produces costs (accounting!)
• what requires resources (scheduling!)
• what influences/produces outcome (studying!)
• what quality management is about (controlling!)
The service brings patient, provider, resources, outcome,
and cost together.
The Service is the center of our universe.
May 16, 2000
© 2000, HL7
23
Service_list
id : SET<II>
type_cd : CV
name : ST
desc : ED
RIM Class Diagram - v0.96
1
0..*
0..*
Service_list_item
sequence_nmb : REAL
priority_nmb : REAL
note_txt : ED
Stakeholders
Legend
Patient Encounters
1
0..*
Stakeholder
Service_relationship
type_cd : CV
inversion_ind : BL
sequence_nmb : INT
priority_nmb : INT
pause_qty : PQ
checkpoint_cd : CV
split_cd : CV
join_cd : CV
negation_ind : BL
conjunction_cd : BL
1
Service
id : SET<II>
mood_cd : CV
service_cd : CD
txt : ED
status_cd : CV
activity_time : GTS
critical_time : GTS
method_cd : CD
body_site_cd : CD
interpretation_cd : SET<CV>
confidentiality_cd : SET<CV>
max_repeat_nmb : INT
interruptible_ind : BL
substitution_cd : CV
priority_cd : CV
orderable_ind : BL
availability_dttm : TS
0..*
Scheduling
Organizations
1
Affiliations
Service_actor
type_cd : CV
tmr : IVL<TS>
note : ED
signature_cd : CV
function_cd : CD
0..*
1
Referral
authorized_visits_qty
desc
reason_txt
Person
Procedure
entry_site_cd : CD
Appointments
1
Insurance
Data types
Transportation
Patient
Diet
energy_qty : PQ
carbohydrate_qty : PQ
Service_target
type_cd : CV
tmr : IVL<TS>
awareness_cd : CV
Service Provider
Responsibility
type_cd : CV
tmr : IVL<TS>
material_id : SET<II>
0..*
Finance
.
May 16, 2000
1
Device
slot_size_increment_qty : PQ
Doc.
Document
Roles
0..1
Container
capacty_qty : PQ
height_qty : PQ
diameter_qty : PQ
barrier_delta_qty : PQ
bottom_delta_qty : PQ
seperator_type_cd : CD
cap_type_cd : CD
1
Material_relationship
type_cd : CV
inversion_ind : BL
tmr : IVL<TS>
position_nbr : LIST<INT>
qty : PQ
Encounter
0..*
Accounting
Observation
value : ANY
derivation_expr : ST
Condition_node
Medication
form_cd : CD
route_cd : CD
dose_qty : PQ
strength_qty : PQ
rate_qty : PQ
dose_check_qty : PQ
Consent
USAM
0..*
0..1
Supply
qty : PQ
0..*
1
Material
id : SET<II>
type_cd : CD
form_cd : CV
danger_cd : CD
qty : PQ
desc : ED
status_cd : CV
extent_tmr : IVL<TS>
lot_nbr : ST
handling_cd : CD
0..*
1
Service
Document_service
completion_cd : CV
set_id : II
storage_cd : CV
version_nbr : INT
Message
control
Episode
Location
Material
Material
takes_on_role 1
1
1
1
Access
gauge_qty : PQ
entry_site_cd : CD
body_site_cd : CD
1
0..1
0..1
0..1
Specimen
body_site_cd : CD
Food
preference_cd : CD
Therapeutic_agent
© 2000, HL7
0..1
0..1
24
The Service Action Oriented Perspective
Service_target
type_cd : CV
tmr : IVL<TS>
awareness_cd : CV
• Covers all health care
related services.
• Unifies all services in a
common “super-class.”
• Models the detail in
specializations of the
service.
– observation: value
– medication: dose, form, route
• Relates to actors, targets,
and other services through
the super-class.
May 16, 2000
© 2000, HL7
– tracking of responsibilities
– tracking of resources
– tracking of reason, etc.
25
Service and Context
• who is the actor?
• provider, individual or organization
• patient, relative, neighbors in home health
• what is the service?
• observation, judgement, medication, surgery, physiotherapy
• consents, advanced directives, education, consultation
• on whom or what (recipient)?
• people: patient, relative, neighbor (caring person), community
• things: specimen, food, environmental samples
– indirect recipient, beneficiary (“for whom”)
• patient, community (population)
• when?
• where? (facility, location)
• with what? (material resources)
May 16, 2000
© 2000, HL7
26
Service
to Stakeholder
1
0..1
1
0..*
0..*
Service_list_item
sequence_nmb : REAL
priority_nmb : REAL
note_txt : ED
1
0..*
1
1
0..*
1
Device
slot_size_increment_qty : PQ
Service_list
id : SET<II>
type_cd : CV
name : ST
desc : ED
Service_actor
type_cd : CV
tmr : IVL<TS>
note : ED
signature_cd : CV
function_cd : CD
0..*
Service_target
type_cd : CV
tmr : IVL<TS>
awareness_cd : CV
to Person/Living subject
to Stakeholder
Material
Responsibility
type_cd : CV
tmr : IVL<TS>
material_id : SET<II>
Service
id : SET<II>
mood_cd : CV
service_cd : CD
txt : ED
status_cd : CV
activity_time : GTS
critical_time : GTS
method_cd : CD
body_site_cd : CD
interpretation_cd : SET<CV>
confidentiality_cd : SET<CV>
max_repeat_nmb : INT
interruptible_ind : BL
substitution_cd : CV
priority_cd : CV
orderable_ind : BL
availability_dttm : TS
Service_relationship
type_cd : CV
inversion_ind : BL
sequence_nmb : INT
priority_nmb : INT
pause_qty : PQ
checkpoint_cd : CV
split_cd : CV
join_cd : CV
negation_ind : BL
conjunction_cd : BL
Material
id : SET<II>
type_cd : CD
form_cd : CV
danger_cd : CD
qty : PQ
desc : ED
status_cd : CV
extent_tmr : IVL<TS>
lot_nbr : ST
handling_cd : CD
Material_relationship
type_cd : CV
inversion_ind : BL
tmr : IVL<TS>
position_nbr : LIST<INT>
qty : PQ
0..*
1
takes_on_role 1
1
Container
capacty_qty : PQ
height_qty : PQ
diameter_qty : PQ
barrier_delta_qty : PQ
bottom_delta_qty : PQ
seperator_type_cd : CD
cap_type_cd : CD
1
1
Access
gauge_qty : PQ
entry_site_cd : CD
body_site_cd : CD
1
0..1
0..1
Food
preference_cd : CD
0..1
Roles!
0..*
Specimen
body_site_cd : CD
Therapeutic_agent
0..1
0..1
1
Specializations
Referral
authorized_visits_qty
desc
reason_txt
Procedure
entry_site_cd : CD
Transportation
Supply
qty : PQ
Diet
energy_qty : PQ
carbohydrate_qty : PQ
Observation
value : ANY
derivation_expr : ST
Condition_node
Medication
form_cd : CD
route_cd : CD
dose_qty : PQ
strength_qty : PQ
rate_qty : PQ
dose_check_qty : PQ
Consent
Document_service
completion_cd : CV
set_id : II
storage_cd : CV
version_nbr : INT
Core attributes
actor
type_cd
responsibility
type_cd
serv’rel’ship
mat’rel’ship
type_cd
type_cd
Material
type_cd (name)
id
description
form_cd
extent_tmr
May 16, 2000
target
type_cd
© 2000, HL7
Service
service_cd (name)
id
txt
mood_cd
status_cd
critical_time
28
Ref
Our agenda
Refresher - Why do we care?
Reading the RIM
HL7’s use of UML
Unified Service Action Model (USAM) in the RIM - basics
USAM structural codes
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
29
Service
Material
• What happens?
• With what, where?
• Actions
• Subjects of actions
• Procedure
• Devices, tools
• Measurements
• Specimen
• Medication
• Pharmaceutical product
• Outcome
• Product
• Change
• Persistence
Ref
– add orders to specimen
– maintain access/drain
May 16, 2000
© 2000, HL7
30
Service class & Mood code
Ref
• A service is an intentional action ... A Service instance
is a record of such an intentional action.
• The mood of an action tells whether the action
represents a fact (event) an order, a plan (intent), a goal,
a risk, a potential (definition) or the like.
• A service instance represents an action in one and only
one such mood. Thus, service definitions (master),
orders, plans, and performance records (events) are all
represented by an instance of class Service.
• Any instance of a Service assumes one and only one
mood and will not change its mood along its life cycle.
... the mood of a service instance is static and not part
of the state.
May 16, 2000
© 2000, HL7
31
Service mood codes (1)
Ref
Concept
Implies Code Definition
Completion track moods. These are moods describing activities
as they progress in the functional cycle, from defined, through
planned and ordered to completed.
definition
DEF A definition of a service ("master".)
intent
INT An intention or plan to perform a service.
order
INT
ORD An order for a service is an intent directed from
a placer (intent author) to a filler (service
performer.)
event
EVN A service that actually happens, may be an
ongoing service or a documentation of a past
service.
May 16, 2000
© 2000, HL7
32
Service mood codes (2)
Ref
Concept
Implies Code
Definition
Predicate moods. Any of the above service moods (e.g., event,
intent, or goal) can be turned into a predicate used as a
criterion to express conditionals (or queries.)
event criterion
EVN.CRT A criterion or condition that must apply for an
associated service to be considered.
option
OPT
An option is an alternative set of propertyvalue bindings. Options specify alternative
sets of values, typically used in definitions or
orders to describe alternatives. An option can
only be used as a group, that is, all assigned
values must be used together.
May 16, 2000
© 2000, HL7
33
Ref
Service states
held
hold
suspend
ed
release
suspend
temporary interruption
resume
end
new
new
cancel
begin
active
abort
end
complete
d
normal path
supercede supercede
exceptional termination
cancelle
d
aborted
supercede
d
Figure 1: Simple unified state-transition diagram valid for all moods.
May 16, 2000
© 2000, HL7
34
Service actors and targets
Ref
• Services have actors and targets. Examples for actors
are nurses, doctors, family members, notary publics,
and service organizations -- every entity that is capable
of independent decisions and can thus be responsible
(and liable) for the actions performed.
• Target participants may include the patient, the patient's
spouse, family, or community, a specimen drawn from
the patient or from any object of interest. As patients do
play active roles in their own healthcare, the patient can
be both an active participant and a target participant at
the same time (self-administered or reflexive services.)
• A service_event can have multiple active participants
and multiple target participants …
May 16, 2000
© 2000, HL7
35
Types of actors
Actor.type_cd
Ref
• performer: principle actor
• e.g., surgeon, anesthesist
• people with accountability : responsible actor
• e.g., head of department, attending surgeon,
anesthesiologist.
• authors & originators of information
• placer / filler
• placer: the orderer
• filler: the performer of the ordered service
• lots more …
May 16, 2000
© 2000, HL7
36
Types of targets
Target.type_cd
Ref
• direct vs. indirect target
– direct: who/what is acted on?
• subject, recipient
• device, consumable, product
– indirect: on behalf of whom?
• patient in teaching the spouse
• patient
– what’s a patient anyway?
– mother–baby; donor
• location
– service location
• remote location
– origin, destination, via
May 16, 2000
© 2000, HL7
37
Responsibility type_cd
Ref
• A party responsible for defects (someone to sue for)
– owner, holder, manufacturer, distributor, retailer, …
• A party responsible for caring about the “thing”
– holder, trainer (of animals)
– mother/father of unborn child
May 16, 2000
© 2000, HL7
38
Service Relationship
type_cd
Ref
• composition
– whole - part
– genus - species
• conditioning
– precondition, trigger
• outcome, goal, risk
• knowledge
– conclusion - evidence
– cause - effect
– recommendation
• revision
– amendment, order revision
– condition thread
• options and defaults
May 16, 2000
© 2000, HL7
39
Material Relationship
type_cd
Ref
• composition
– whole - part
– mixture - ingredient
•
•
•
•
base, additive
active ingredient
preservative, stabilizer
flavor, color
• presence
– thing “located” at thing
• e.g., book in shelve
• generalization
– and specialization
May 16, 2000
© 2000, HL7
40
Examples of service in USAM
• Examples for services in health care are:
– a clinical test,
– an assessment of health condition (such as problems and
diagnoses),
– the setting of healthcare goals,
– the performance of treatment services (such as medication,
surgery, physical and psychological therapy,)
– assisting, monitoring or attending,
– training and education services to patients and their nexts of
kin,
– notary services, such as advanced directives or living will,
– etc.,
– etc.
May 16, 2000
© 2000, HL7
41
Examples of constructs enabled by USAM
• Condition Node and Condition Thread
– Managing patient problems collaboratively and continuously.
• Representing Knowledge
– Defining service concepts and semantic relationships
– Take a stab at the vocabulary problem
• Workflow Management
– Defining and managing collaborative processes.
– Timed and conditioned care plans and clinical guidelines.
• Accountability, security, privacy
– Application layer-based approaches
– Integrated in the information model
May 16, 2000
© 2000, HL7
42
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Vocabulary & Version 3
Vocabulary domains
Vocabulary domain definition data base
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
43
Information Modeling Language
• Class defines things
• Objects are instances
Person
name
: PN
DOB
: Date
address : AD
• Associations relate things
Coded attributes
• Associative classes
• Generalization
classes
Over 40% of RIM attributes
are coded!
• Reflexive associations
Patient
gender : CD
donor : BL
V.I.P.
: BL
0..*
1
Encounter
type
: CV
time
: IVLTS
reason : CD
1
1..*
Doctor
specialty : CD
phone
: TEL
privileges: CV
0..1
follow-up
0..1
• Reflexive associations structure instances of one class
– chain (predecessor-successor,) hierarchy (parent-child,) or network
May 16, 2000
© 2000, HL7
44
Goals of Vocabulary Technical Committee
• Decrease time and cost of implementations
• Approach “plug-and-play”
• Enable data sharing
– Mergers due to managed care
– Regional or national clinical studies
– Disease prevention and control
• Enable sharing of decision support modules
– Alerts
– Protocols
– Clinical pathways
May 16, 2000
© 2000, HL7
45
HL7 Vocabulary Development Strategy
• Reference existing vocabularies
• Collaborate with other SDO’s
– DICOM
– ASTM
– X12
• Add value by creating linkage between HL7
messages and existing vocabularies
• Only add items that do not already exist
• Collaborate with vocabulary developers
May 16, 2000
© 2000, HL7
46
HL7 Message Development Framework (MDF)
• Describes how to develop Version 3 Messages
• MDF-99 includes a vocabulary chapter for the
first time
• MDF focuses on processes and methods for
producing ballotable Version 3 messages
• MDF-99 is available in the V3 resource area at
www.hl7.org
May 16, 2000
© 2000, HL7
47
Outline of MDF Vocabulary Chapter
• Vocabulary domains
• Structure of coded elements in messages
• The general process of maintaining domain
specifications
• Good vocabulary practices
• Use of external terminologies in HL7 standards
• The use of local vocabularies in coded elements
• HL7 vocabulary and the UMLS Metathesaurus
May 16, 2000
© 2000, HL7
48
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Vocabulary & Version 3
Vocabulary domains
Vocabulary domain definition data base
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
49
Vocabulary Domains
• Introduction
• Vocabulary Domains and Vocabulary Domain
Specifications
• Specialization of Vocabulary Domains
– Rules for specializing vocabulary domains
– The syntax for constraining vocabulary domains in
the domain specification database
• Validating Vocabulary Domain Specifications
and Constraints
• The Domain Specification Database
May 16, 2000
© 2000, HL7
50
Vocabulary domain
• “The set of all concepts that can be taken as
valid values in an instance of a coded field or
attribute.”
• Concept - “A unit of thought constituted through
abstraction on the basis of characteristics
common to a set of objects.” ISO 1087
• Each concept in the domain can be represented
using a specific vocabulary/terminology
May 16, 2000
© 2000, HL7
51
Each coded attribute must have a domain specification
Class: Patient
Description: A person who may receive, is
receiving, or has received healthcare services.
Associations
is_a_role_of (1,1) :: Person
is_source_for (0,n) :: Specimen_sample
Attributes
birth_order_number
birth_dttm (from Person)
gender_cd <Gender, Ext:CWE>
May 16, 2000
© 2000, HL7
52
Vocabulary Domain Specification
• One and only one for each coded RIM attribute
• General form:
– <domain name, list of domain qualifiers>
– <Gender, Ext:CWE>
• Currently two types of domain qualifiers
– Extensibility (Extensibility)
• CNE - Coded No Exceptions
• CWE - Coded With Exceptions
– Realm (RealmOfUse)
•
•
•
•
May 16, 2000
Universal
USA?
Europe?
Others
© 2000, HL7
53
Specialization (constraint) of Domains
• Used in specifying message
– MIM, MET, CMET, HMD, Clinical Templates(?)
• Example:
– MyGender = (“Gender:USA:HL7” - “Other:USA:HL7-001”)
• General Form
– “value set name” <set operator> “value set name”
• Value set name
– “Domain name:Realm:Terminology”
• Allowed set operators
– “+” Union ()
– “-” Difference (sometimes represented as “\”)
– “*” Intersection ()
May 16, 2000
© 2000, HL7
54
Local Vocabulary Use
• Can only be used with qualifier Strength:CWE
• The complete domain is a union of standard domain
plus local concepts (as a union of the two)
• Rules
– Local concept can not replace standard concept
– Local code system names must start with “99”
– Local codes should be submitted to HL7 for inclusion in
standard domain and forwarded to terminology developers
May 16, 2000
© 2000, HL7
55
General process of maintaining domains
• Follows pattern of RIM harmonization
• Vocabulary TC appoints facilitators
• Message development TCs have stewardship
– Ultimate authority for domain contents
– Follow RIM harmonization rules
• Vocabulary Facilitators
– Insure that good vocabulary practices are followed
– Actual maintenance of domain specification database
– Submit new concepts to vocabulary providers
May 16, 2000
© 2000, HL7
56
Domain specification table maintenance (plan)
• Available on HL7 web site
– All members can read tables
• Edit Permissions table
– who can edit which domains
– vocabulary co-chairs maintain permissions table
• Assigned persons make edits (proposed status)
• Entries reviewed by Vocab Review Committee
• Reports presented to RIM harmonization process
• Approved changes reflected by status changes
• HL7 standard versions synch’ed with edit versions
May 16, 2000
© 2000, HL7
57
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Vocabulary & Version 3
Vocabulary domains
Vocabulary domain definition data base
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
58
The domain specification database
• This is only the first version. There will be future
enhancements to domain specifications and to the table
design
• Requirements:
–
–
–
–
–
–
–
–
–
May 16, 2000
Unique, non-sense identifier
Unique textual name
Description/definition
Edit note
Version tracking
Can be specific to a realm of use
Each “leaf” set is from a single vocabulary
Domains can be recursively defined
Set notation will be used to describe relationships
© 2000, HL7
59
Domain specification data base - meta-model
Coded_term
table
0..*
code
0..*
contains
represents
Terminology a coding
system and
its terms
Concept
id
represents
1
0..*
1
Code_system
name
1
1
1..*
includes
Value_set
realm_of_use 0..*
draws from
0..*
Value set - the subset of concepts
from a domain that apply in a given
Realm and Code System
External_value_set
defining_expression
May 16, 2000
Concept - unit of thought
constituted through
abstraction on the basis of
characteristics common to
a set of objects.
1 Domain
includes
Domain - set of all
concepts that can
be taken as valid
values in an instance
of a coded field
HL7_value_set
0..*
© 2000, HL7
60
Domain specification data base - meta-model
has
1
has
1
Domain_version
Provides version
control
parameters for
HL7 domain
tables.
Code_system
Sources of
coded terms.
has
0..*
in_version
Unique concepts
identified by HL7.
May exist as
domains, value sets
or leaf-level
concepts. Each may
0..1
has_basis_in be coded. Value
is_basis_for
0..* sets are based on a is_contained_concept
single code system.
1
1..1
has_terms 1..1
0..*
Vocabulary_concept
is_represented_by 1..1
1..1
is_containing_concept
is_part_of
Coded_term
Individual coded
terms. Each
represents a single
concept and is
in_version drawn from one
0..* particular code
system, system
version and system
set or table.
0..*
links_content
Concept_relationship
represents
0..*
Links: value sets
into domains; and
has_container concepts and value
0..* sets into value
sets. (Linkage
may include or
exclude.)
0..* in_version
May 16, 2000
© 2000, HL7
61
Domain specification data base - meta model
has
1
has
1
Domain_version
version : Integer
has
edit_dttm : DateTime
editor_id : String
1
for_whom_id : String
comment : DescriptiveText
Arbitrary integer
0..*
Vocabulary_concept
in_version concept_id : Integer
Signify: Domain,
HL7 value set,
External value
set, Concept
type_cd : Enumerated
name : String
realm_of_use : Enumerated
Required for
description : DescriptiveText
value set
defining_expression : String
preference : Integer
Code_system
0..1
has_basis_in edit_note : DescriptiveText
systemName : String
status : CodedElement
0..*
organization : String is_basis_for
is_contained_concept
version_out : Integer
1..1
has_terms 1..1
is_represented_by 1..1
1..1
is_containing_concept
0..* is_part_of
Coded_term
code : String
displayName : String
definition : DescriptiveText
setName : String
tableID : String
in_version system_version_in : String
represents
0..*
0..* system_version_out : String
language_cd : Enumerated
mapping_quality : Enumerated
edit_note : DescriptiveText
status : CodedElement
version_out : Integer
Links as:
Abstract set,
Specializable set,
Leaf concept
0..*
links_content
Concept_relationship
generality : Enumerated
operator : Enumerated
sequence : Integer
Operator has_container type_cd : Enumerated
0..* edit_note : DescriptiveText
includes (+) or
excludes (-) the
status : CodedElement
version_out : Integer
linked concept
0..* in_version
May 16, 2000
© 2000, HL7
62
Domain specification data base - physical model
VOC_ObsID_link
domainConceptID
observationCode
systemName
setName
tableID
sysVersionIn
sysVersionOut
status
versionIn
versionOut
editNote
code = observationCode
systemName = systemName
setName = setName
tableID = tableID
sysVersionIn = sysVersionIn
sysVersionOut = sysVersionOut
LongInteger
Text(50)
Text(50)
Text(50)
Text(10)
Text(16)
Text(16)
Text(10)
LongInteger
LongInteger
Memo
versionIn = versionIn
versionIn = versionIn
conceptID = domainConceptID
conceptID = conceptID
VOC_version
versionIn
LongInteger
editDttm
DateTime
editorID
Text(50)
forWhomID
Text(50)
comment
Memo
VOC_concept
conceptID
LongInteger
conceptType
Text(10)
conceptName
Text(50)
systemName
Text(50)
realm
Text(50)
description
Memo
definingExpress
Text(250)
preference
Text(10)
status
Text(10)
versionIn
LongInteger
versionOut
LongInteger
editNote
Memo
versionIn = versionIn
conceptID = contentConceptID
conceptID = containingConceptID
VOC_coded_term
code
systemName
setName
tableID
sysVersionIn
sysVersionOut
displayName
definition
language
conceptID
mapQuality
status
versionIn
versionOut
editNote
May 16, 2000
Text(50)
Text(50)
Text(50)
Text(10)
Text(16)
Text(16)
Text(50)
Memo
Text(10)
LongInteger
Text(10)
Text(10)
LongInteger
LongInteger
Memo
systemName = systemName
VOC_relationship
containingConceptID
contentConceptID
relationType
generality
operator
sequence
status
versionIn
versionOut
editNote
LongInteger
LongInteger
Text(10)
Text(10)
Text(10)
LongInteger
Text(10)
LongInteger
LongInteger
Memo
systemName = systemName
VOC_code_system
systemName
Text(50)
organizationName
Text(50)
versionIn = versionIn
© 2000, HL7
63
Domain Specification Database Tables
• Concept Definition Table (VOC_Concept)
– Domains (type: D)
– Value sets (types: H and E)
– Concepts (type: C)
• Concept Relationship Table (VOC_Relationship)
• Code System Table (VOC_Code_system)
• Coded Term Table (representation) (VOC_Coded_term)
• Version Tracking Table (VOC_Version)
• Edit Permissions Table (not shown)
• Observation Identifier to Value Set Linking Table
(VOC_ObsID_link)
May 16, 2000
© 2000, HL7
64
Value Set Definitions (from VOC_Concept)
concept
ID
Domain Name
1 Gender
5 Race
10001 MyGender
AmericanIndian
OrAlaskaNative
20002 Asian
BlackOrAfrican
20003
American
NativeHawaiian
20004
OrPacificIslander
20005 WhiteRace
30001 AmericanIndian
30002 AlaskaNative
50005 Race
50006 Race
60001 ClinicalDiagnosis
20001
Realm
Code
System
Root
Root
HL7
HL7
Root
HL7
USA
HL7
USA
USA
USA
USA
USA
USA
USA
UK
USA
60002 ClinicalDiagnosis
USA
70001 BillingDiagnosis
USA
May 16, 2000
description
Defining Expression
Current
Vin Vout
Status
Gender:Root:HL7
Race:Root:HL7
A
A
1
1
("Gender:Root:HL7" - "O:HL7-0001")
A
1
AmericanIndianOrAlaskaNative:USA:HL7
A
1
HL7
The gender of a person.
The race of a person.
The gender of a person. Does not
allow Unknown or Other.
American Indian or Alaska Native
Race
Asian Race
Asian:USA:HL7
A
1
HL7
Black or African American Race
BlackOrAfricanAmerican:USA:HL7
A
1
NativeHawaiianOrPacificIslande:USA:HL7
A
1
WhiteRace:USA:HL7
AmericanIndian:USA:HL7
Alaska Native:USA:HL7
Race:USA:HL7
ChildrenOf("Race")
ChildrenOf("D*")
A
A
A
A
P
A
1
1
1
2
1
3
SubTypes("1278")
A
3
Any("ICD-9CM")
A
2
Native Hawaiian or Pacific Islander
Racer
HL7 White Race
HL7 American Indian Race
HL7 Alaska Native Race
HL7 The race of a person.
RC A person's race.
SNM3 A clinical diagnosis or syndrome.
Diagnosis or syndrome that best
MED
explains the patient's symptoms.
The billing diagnosis for third party
IC9
reimbursement purposes.
HL7
© 2000, HL7
65
Value Set Definitions (content 1)
concept
Domain Name
ID
1 Gender
Realm
Root
Code
description
Defining Expression
System
HL7 The gender of a person.
Gender:Root:HL7
The gender of a person. Does not
HL7
("Gender:Root:HL7" - "O:HL7-0001")
allow Unknown or Other.
10001 MyGender
Root
60001 ClinicalDiagnosis
USA
SNM3 A clinical diagnosis or syndrome. ChildrenOf("D*")
60002 ClinicalDiagnosis
USA
MED
70001 BillingDiagnosis
USA
IC9
Diagnosis or syndrome that best
SubTypes("1278")
explains the patient's symptoms.
The billing diagnosis for third
party reimbursement purposes.
Any("ICD-9CM")
• A single row is a value set
– Each Value Set gets a unique concept ID
– Key for value sets consists of Domain Name, Realm, Code System
• The union of all value sets with the same Domain Name is a
domain
May 16, 2000
© 2000, HL7
66
Value Set Definitions (content 2)
concept
Domain Name
ID
1 Gender
Realm
Root
Code
description
Defining Expression
System
HL7 The gender of a person.
Gender:Root:HL7
The gender of a person. Does not
HL7
("Gender:Root:HL7" - "O:HL7-0001")
allow Unknown or Other.
10001 MyGender
Root
60001 ClinicalDiagnosis
USA
SNM3 A clinical diagnosis or syndrome. ChildrenOf("D*")
60002 ClinicalDiagnosis
USA
MED
70001 BillingDiagnosis
USA
IC9
Diagnosis or syndrome that best
SubTypes("1278")
explains the patient's symptoms.
The billing diagnosis for third
party reimbursement purposes.
Any("ICD-9CM")
• Two kinds of mutually exclusive domains
– Domains maintained by HL7
– Domains maintained by external terminology providers
• An HL7 maintained domain can not have value sets defined
by reference to an external terminology
May 16, 2000
© 2000, HL7
67
Value Set Definitions (content 3)
concept
Domain Name
ID
1 Gender
Realm
Root
Code
description
Defining Expression
System
HL7 The gender of a person.
Gender:Root:HL7
The gender of a person. Does not
HL7
("Gender:Root:HL7" - "O:HL7-0001")
allow Unknown or Other.
10001 MyGender
Root
60001 ClinicalDiagnosis
USA
SNM3 A clinical diagnosis or syndrome. ChildrenOf("D*")
60002 ClinicalDiagnosis
USA
MED
70001 BillingDiagnosis
USA
IC9
Diagnosis or syndrome that best
SubTypes("1278")
explains the patient's symptoms.
The billing diagnosis for third
party reimbursement purposes.
Any("ICD-9CM")
• Expression contains the information that can be used to resolve
the value set to its individual elements
• The expression would be sent to a terminology service
• The semantics of the expression are specific to the terminology
service
May 16, 2000
© 2000, HL7
68
Version Tracking - (value sets as example)
concept
Domain Name
ID
1 Gender
10001 MyGender
60001 ClinicalDiagnosis
60002 ClinicalDiagnosis
70001 BillingDiagnosis
Code Current
Realm
Vin Vout
System Status
Root
HL7
A
1
Root
HL7
A
1
USA SNM3
A
3
USA
MED
A
3
USA
IC9
A
2
• An entry gets a Vin number when it first becomes a part
of the table
• An entry gets a Vout number when it becomes inactive
• An entry with a blank Vout is currently active
May 16, 2000
© 2000, HL7
69
Version Tracking Table (VOC_Version)
versionIn
editDttm
editorID
forWhomID
1
4/14/99 10:00 PM
1234
4359
2
4/16/99 10:00 AM
1234
922
3
5/18/99 12:00 PM
8765
2566
comment
Created entries for all composite race vocabulary
domains
After testing and review, changed the status of the race
domain to active.
Release of Version 2.3.1 of the standard.
• A new version get created each time there is a new
editing session
• The version number becomes part of each domain
specification table as edits are made
• A permissions table (not shown) controls who can edit
which value sets
May 16, 2000
© 2000, HL7
70
Value Set Relationships (from VOC_Relationship)
ValueSet
conceptID
50005
50005
50005
50005
50005
20001
20001
ValueSet Name
Race:USA:HL7
Race:USA:HL7
Race:USA:HL7
Race:USA:HL7
Race:USA:HL7
AmericanIndian OrAlaskaNative
:USA:HL7
AmericanIndian OrAlaskaNative
:USA:HL7
Include
Include
Include
Include
Include
Abstract
Specializable
Abstract
Abstract
Specializable
content
conceptID
20001
20002
20003
20004
20005
Include
Specializable
30001
AmericanIndian
Include
Specializable
30002
AlaskaNative
Operator
Generality
Content conceptName
AmericanIndian OrAlaskaNative
Asian
BlackOrAfrican American
NativeHawaiian OrPacificIslander
WhiteRace
• Value Set Name and Concept Name are only shown for
purposes of illustration
• Operator can be Include or Exclude
• Generality says whether to include the node itself in the
value set
May 16, 2000
© 2000, HL7
71
Source Vocabulary Representation (VOC_coded_term)
HL7
Concept
ID
40001
40002
40003
40004
40005
40001
40002
40003
40004
40005
Code
System
CR
CR
CR
CR
CR
HL7
HL7
HL7
HL7
HL7
Source
Domain
Name
Sex
Sex
Sex
Sex
Sex
Gender
Gender
Gender
Gender
Gender
Code
Table ID System
Vin
220
6
220
6
220
6
220
6
220
6
1
2.3.1
1
2.3.1
1
2.3.1
1
2.3.1
1
2.3.1
Code
Lang
1
2
3
4
9
M
F
O
T
U
en
en
en
en
en
en
en
en
en
en
displayName
Male
Female
Other
(Hermaphrodite)
Transsexual
Not
Stated/Unknown
Male
Female
Other
Transsexual
Unknown
• HL7 Concept ID asserts HL7’s view of synonyms
• HL7 Concept ID could be replaced by universal concept
identifier (UMLS CUI?)
• Supports multiple languages
May 16, 2000
© 2000, HL7
72
Observation Id to Value Set Linking Table
Code
System
LN
Observation
displayName
Identifier
11882-8
Fetal Gender
ValueSet
ValueSet name
ConceptID
1
Gender:Root:HL7
• Used to connect value sets to observation identifiers when
used in name-value pairs like an OBX segment
• LOINC gives only examples, and is not prescriptive
• Allows for strong constraints when OBX like structures are
used in messages
May 16, 2000
© 2000, HL7
73
Using the Domain Specification Database
• Look at Value Set Definition in VOC_concept Table
– Use domain name, realm, and code system (type: E)
– Find and remember the Expression
• Pass the Expression to a terminology server (TQS)
• Knowledge of how to resolve HL7 Value Sets to
individual elements is available in the Relationship
Table and the Coded Term Table
• Knowledge of how to resolve external Value Sets is the
responsibility of the terminology provider
May 16, 2000
© 2000, HL7
74
Proposing HL7 Code Sets - Template
Action TableName
Row
action:
Add
Update
Delete
A
A
A
ID
Textual table
Numeric.
identifier for HL7 Set table
table
row.
Formula
increments
CopyBlock
CopyBlock
CopyBlock
123320
123321
123322
Parent
RowType
ID nmbr
or Code
of parent
Value Set
Dom Abs
Spec Code
Rec
123320
123320
D
C
S
Oper
ValueSetName
Realm
Operator ValueSetName required for all rows
'+' or '-' except types C & R.
(Default
is '+')
Concept
Code for the Print name for the term
realm of the or value set.
value set.
Req'd for
VS.
Code
Definition
Code for term or Definition of the concept. May
Value Set. Do be provided for all but Recode
entries.
not code
Abstract value
or domains.
AppliesTo HowApply TxtPar
Which mood
or target a
relationship
code applies
to (OPT).
How the
relation code
is used with
column to left.
Formula
converts
'Parent'
column
DummySourceRows
CopyPasteThisRowManyTimes
concept one
concept two
C1
C2
First copy whole block.
123320
Then copy/paste this rowColumns provide special 123320
to form basic block for notations for relationship
table to be defined.
type codes. Information is
appended to the definition
in Access.
A textual definition of all rows should be provided to guide
the user in selecting the proper code and/or domain.
Template with Instructions
Codes must be provided for all S, C, and R rows. Enter numeric codes as
text in Excel. (Preface entry with apostrophe).
The 'Print Name' for the concept should be provided for all terms that have a code (C and S).
Each Value Set (row of type A or S) must include a realm specification (code).
Formula conversion of 'Parent'
D rows will be assigned to the 'root' realm.
used by Access
A Value Set Name must be provided for all D, A, and S rows. It should be unique within HL7
Operator value '+' (the default) includes' the concept in the parent set. '-' excludes the concept or the entire referenced set from the parent.
Each row has a type code. Domain applies only to the first row in each table. Abstract and Specializable are rows that are Value Sets (contain other rows). Specializable
sets have codes, abstract do not. Coded entry rows are terms, or codes, for the table. Recode rows are ones which provide an alternate code for a given concept. (Note
the concept ID repeats for Recode terms.)
Each row in the table, except the top level domain, must reference its 'parent' Value Set. For plain code tables, this is the ID of the table itself. For more complex tables reference
either the ID number or the Code, if available, of the parent. Numeric references should be references so that the parent reference will be renumbered if the table is assigned a new
starting number. For Delete or Update actions enter the Concept ID from the HL7 Vocabulary data base.
Concept ID is managed by Vocab TC. It must be unique within HL7. To define a table, enter an arbitrary starting number in the first row of the table, and use formulas to reference to this for all
other entries. (Formulas in dummy source table do this.) For Delete or Update actions enter the Concept ID from the HL7 Vocabulary data base.
Table name must be unique within HL7. Entered in the first row of the table, it is replicated down the page.
Column indicates whether the row is an Addition to the data base, an Update to or Deletion of an existing entry.
To use this template: (1) Print this page and then select and delete the drawings to get them out of the way. (2) Select the copy Block - Rows 3-6, Columns A-N.
(3) Copy the block and paste it in column A at the first empty row. (4) Select the third row of the newly pasted copy block, and "Copy" it. (4) Starting at the fourth row of the newly pasted copy block, drag-select the numer
of rows (or more) you will need for your table. (5) Chose (on Menu) Insert...Copied cells. (6) Choose/enter a Table Name and ID for the new table, and you are 'on your way.' (Adjust column widths as desired. Widths that
work on 1024x768 screen: 3.3, 16.4, 8, 6.4, 5.1, 3.3, 33, 5.8, 16, 8.6, 39)
www.hl7.org//Library/data-model/Support_material/Vocab_source_Template_rev3.xls
May 16, 2000
© 2000, HL7
75
Proposing HL7 Code Sets - Example
A
B
C
ID
1 Acti TableName
Row
on Textual table Numeric.
2
3
4
5
6
7
actio identifier for
n:
HL7 table
Add
Upda
te
A
A
A
D
Parent
E
F
G
Row Ope
ValueSetName
Type
Dom Oper
r ValueSetName required for all rows
ID nmbr or
Set table Code of
Abs ator except types C & R.
row.
parent Value Spec '+' or
Formula
Set
'-'
Code
increments
Rec (Defa
ult is
CopyBlock 123320
CopyBlock 123321
CopyBlock 123322
123320
123320
D
C
S
H
Realm
I
Concept
Code for the Print name for the term
realm of the or value set.
value set.
Req'd for VS.
J
Code
K
Definition
App
Code for term or Definition of the concept. May be provided for all but
Value Set. Do Recode entries.
not code
Abstract value
or domains.
DummySourceRows
CopyPasteThisRowManyTimes
concept one
concept two
ServiceMood
ServiceMoodCompletionTrack root
mood_cd
completion track
C1
C2
First copy whole block.
Then copy/paste this row to form basic
block for table to be defined.
A mood_cd
A mood_cd
70000
70001
70000
D
A
+
A
mood_cd
70002
70000
S
+
ServiceMoodMaster
CAL_LAB definition
DEF
These are moods describing activities as
they progress in the business cycle, from
defined,
through
planned(“master”.)
and ordered to
A definition
of a service
A
mood_cd
70003
70001
S
+
ServiceMoodIntent
root
intent
INT
Historical
note:
in previous
RIMaversions,
An
intention
or plan
to perform
service.
A
mood_cd
70004 INT
C
+
order
ORD
A
mood_cd
70004 INT
R
+
order
35
Historical
note:
in previous
versions,
An order for
a service
is an RIM
intent
directed
from a placer (intent author) to a filler
(service
An
orderperformer.)
for a service is an intent directed
A
mood_cd
70005
C
+
event (occurrence)
EVN
from a placer (intent author) to a filler
(service
A
serviceperformer.)
that actually happens, may be an
8
9
10
11
12
70001
ongoing service or a documentation of a
past
service.
Any of
the above service moods (e.g.,
13
A
mood_cd
70006
70000
A
+
A
mood_cd
70007
70006
C
+
ServiceMoodPredicate
root
predicate
14
event criterion
EVN.CRT
event, intent, or goal) can be turned into a
predicate
as a criterion
to express
A
criterionused
or condition
that must
apply for
an associated service to be considered.
15
www.hl7.org//Library/data-model/Support_material/Vocab_source_Example_rev3.xls
May 16, 2000
© 2000, HL7
76
Whic
or ta
relat
code
to (O
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Overview of HL7 V3 data types
Closer look at data types for coded attributes
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
77
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Vocabulary & Version 3
Vocabulary domains
Vocabulary domain definition data base
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
78
Initial Data Type Ballot
• Being presented to Control/Query this week
• Subject to committee-level ballot soon
http://www.hl7.org//Library/data-model/
Support_material/ HL7v3DataTypes_1_0.pdf
May 16, 2000
© 2000, HL7
79
Data types vis-à-vis Classes - the basics
• A data type is represented in RIM diagrams as a UML
class
• Both have descriptions
• A primitive data type has no components and is defined
solely by its description
• Data types may have components, as classes have attributes
• Components and attributes are each assigned a data type
• “Abstract” data types may not be assigned to attributes.
They are reserved for use in defining other data types
May 16, 2000
© 2000, HL7
80
Quantity data types
Integer : INT
Physical_quantity : PQ
value : REAL
unit : CV
Boolean : BL
Binary_data : BIN
Number : N
Monetary_amount : MO
value : REAL
currency_unit : CV
Ratio : RTO
numerator : QTY
denominator : QTY
No_information : NULL
flavor : CD
Real : REAL
value : N
precision : N
May 16, 2000
© 2000, HL7
Null is not a type to be
assigned an attribute, but rather
one that is communicated
(sent) when the information is
missing
The flavor of the null value.
Can be interpreted as the
reason why the information is
missing.
81
Time-related data types
• Point in time - very similar to the
Version 2.x time stamp -- a scalar
defining a point on the axis of natural
time.
Point_in_time : TS
General_timing_specification : GTS
• General timing specification is a primitive data type that
is conceptually an arbitrary set of points in time. It is any
combination of (1) a point in time, and/or (2) an interval of
time. This includes uncertain points and intervals of time.
Values are defined in terms of a literal expression syntax.
Regardless of how complex the literal definition is, it will
always decompose into an ordered sequence of points or
intervals of time.
• Primarily used for scheduling of events to allow concepts
like “the last Tuesday of each month” (Poker night)
May 16, 2000
© 2000, HL7
82
Text-related data types
Character_string : ST
• Encapsulated data
–
–
–
–
–
Encapsulated_data : ED
media descriptor - MIME types
media_descriptor : CV
data : BIN
compression : CV
data - the pay-load
charset : CV
reference : TEL
compression - code for compression algorithm
thumbnail : BIN
integrity_check : BIN
charset - character encoding if other than default ic_algorithm : CV
reference - the telecommunication address to the pay-load in
cases where the pay-load is too large to include
– thumbnail - a logical precis of the pay-load
– integrity_check - a cryptographically strong sum-check for
use in signing, authenticating, etc.
– ic_algorithm - the algorithm used to create the integrity check
May 16, 2000
© 2000, HL7
83
Demographic data types
Postal_and_residential_address : AD
purpose : CV
bad_ind : BL
value : LIST<ADXP>
• Postal address is a list of
address parts whose roles
are things like ZIP code,
city, country, post box, etc.
Address_part : ADXP
value : ST
role : CV
Person_name_type : PN
value : LIST<PNXP>
Person_name_part : PNXP
value : ST
classifiers : SET<CV>
Organization_name : ON
type_cd : CV
value : ST
• Person_name is a similar
construct, where the classifiers are may
express multiple dimensions such as given name vs.
family name and name in public records vs. nickname.
May 16, 2000
© 2000, HL7
84
Generic data types
• Provide a means for applying an operation (such as an
interval or a probability distribution) to values
expressed in another data type.
• Examples – interval - of time, of values, etc.
– list - of addresses, of person name parts
– set - of codes
• Interval applies to any ordered type
• List - an ordered collection of items
• Set - an unordered collection of unique items
T
Interval : IVL
low : T
low_closed : BL
high : T
high_closed : BL
T, R
List : LIST
T, R
Set : SET
T, R
Bag : BAG
• Bag - an unordered collection of items
May 16, 2000
© 2000, HL7
85
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Overview of HL7 V3 data types
Look at new “thing” data types for coded attributes
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
86
“Thing” data types (1)
• OIDs - HL7 can issue OIDs and can
enable a member or user organization to
create OIDs ‘underneath’ the HL7 root.
• In the Instance Identifier, the
combination of assigning_authority and
value_text must be unique.
ISO_object_identifier : OID
Instance_identifier : II
assigning_authority : OID
assigning_authority_print_nm : ST
value_txt : ST
type_cd : CV
valid_tmr : IVL<TS>
Telecommunication_address : TEL
address : URI
use_cd : SET<CV>
valid_time : GTS
• The universal resource identifier is
defined and maintained by the IETF and
W3C. Refers to addresses of
communicating entities used to transmit information.
Might be: (a) Web servers (HTTP), (b) File Transfer
Protocol servers (FTP), (c) Telephone numbers, (d)
Telefax numbers, (e) Dialup Modem connections.
Universal_resource_identifier : URI
May 16, 2000
© 2000, HL7
87
“Thing” data types (2)
• A code value is exactly one symbol in a code system. The
meaning of the symbol is defined exclusively and completely
by the code system that the symbol is from.
• A concept descriptor communicates a real world concept
(such as a finding or a diagnosis). A given concept may be
expressed in multiple terms where each term is a translation of
some other term, or is a (re-)encoding of the original human
readable text.
• Code_translation is one translation in a set of translations
describing a concept.
• A code phrase is combination of code values linked by roles.
This can be used for example in SNOMED, where you can
combine multiple codes into a new composite meaning. HL7
V2.x combines codes and modifiers for the OBR specimen
source.
May 16, 2000
© 2000, HL7
88
Revisions to Cx types (May 2000)
CodedSimpleValue : CS
ConceptRole : CR
name : CD
inverted : BL
value : CD
Constraint 3
code : ST
displayName : ST
CodedValue : CV
Constraint 2
ConceptDescriptor : CD
code : ST
displayName : ST
codeSystem : OID
codeSystemName : ST
codeSystemVersion : ST
originalText : ED
modifier : LIST<CR>
translation : SET<CD>
impliesCd : BL
Constraint 1
1. Define a pair of types that
incorporate all of the features
of previous CD, CV, CDXL,
CDPH & CRR types.
May 16, 2000
code : ST
displayName : ST
codeSystem : OID
codeSystemName : ST
codeSystemVersion : ST
originaltext : ST
CodedWithEquivalents : CE
code : ST
displayName : ST
codeSystem : OID
codeSystemName : ST
codeSystemVersion : ST
originaltext : ST
translation : SET<CV>
2. Define a set of constraints and
promotion/demotion rules
that simplify the concepts for
simpler domains.
© 2000, HL7
89
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
90
Problem statement
• Domain facts:
– HL7 Voting Members are either: (a) individual members, or (b) sponsored by
an organizational member, usually their employer.
– Items for balloting are proposed by HL7 Committees or Subcommittees, and
the proposing committee designates an individual to serve as their contact for a
particular proposal.
– Voting members submit ballots on items proposed as HL7 standards.
– Each ballot may vote aye, nay or abstain, and all negative ballots must be
accompanied by a supporting comment.
• Messaging requirements:
– HL7 has a ballot acceptance system, and a ballot notification system.
– HL7 seeks a message to go from the ballot acceptance system to the ballot
notification system.
– This message will be sent upon receipt of a completed ballot.
– The message will allow the notification system to send a confirming e-mail to
each of: the voter, the voter’s sponsor organization (if any) and the contact
person for the item being voted upon.
May 16, 2000
© 2000, HL7
91
What’s in a message
May 16, 2000
© 2000, HL7
92
What’s in a message - below the attribute
May 16, 2000
© 2000, HL7
93
Message basics (1)
• Every part of the message, from the entire message
down to the smallest subcomponent of a subcomponent
of a data type, is a message element.
• Every message element has a type.
• Every message element that is an attribute of a RIM has
a type that is an HL7 data type.
• Every message element that represents a component of
an HL7 data type also has a type that is an HL7 data
type.
• Every message that represents a class has a type that is
based on that class or a Common Message Element
Type.
May 16, 2000
© 2000, HL7
94
Message basics (2)
• Every message that represents an association has a type
that is based on the distal class of the association or a
Common Message Element Type.
• Every message element type is one of these four
metatypes: primitive, composite, collection, or choice.
• Primitives have no subordinate components.
• Composites do have heterogeneous subordinate
components, each with its own name.
• Collections have repetitions of a homogeneous message
element. The name of the repeating message element is
derived from its type.
May 16, 2000
© 2000, HL7
95
R-MIM - relative to the MIM (1)
• Additional constraints on cardinality
• When a class is re-used with different semantics, it may
be shown as two separate classes (clones), with
different constraints
• General classes may be subsumed into specializations,
with different attributes or associations chosen
• Absolute cardinality of classes
– used primarily to show singular classes
May 16, 2000
© 2000, HL7
96
R-MIM - relative to the MIM (2)
• This has all the information of the HMD except
the path resulting from the Tree-walk
• Classes are in an arbitrary order; no semantic
significance
• Used to record semantic information that cannot
be shown in the graphical model:
–
–
–
–
May 16, 2000
domains
update semantics
default values
mandatory in message versus required in implementation
© 2000, HL7
97
Hierarchical Message Description
• Includes
– path
– choices
– interpolated items for collections
• Special treatment for specializations that are not
subsumed in the R-MIM
• Other than the path, there is no additional semantic
content in the HMD, when compared to the Tabular RMIM (the other differences are algorithmically
developed)
May 16, 2000
© 2000, HL7
98
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
R-MIM components
Update semantics
HMD components
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
99
R-MIM components
• The information model section (left) lists the information model entities (classes,
associations, and attributes), one per row.
• The constraints and defaults section (right) states specific constraints on the
information model entities that will be applied to all message formats defined in
HMDs derived from the R-MIM. Some of the constraints are also a part of the
MIM, although they may be tightened in the R-MIM. Many of the constraints are
not UML constructs; they apply specifically to the HL7 messages defined based
on the R-MIM.
May 16, 2000
© 2000, HL7
100
R-MIM - Information model section
Row types
rmim - the first row of the table, identifies the R-MIM
class - identifies a "class" in the Refined Message Information Model
attr - identifies an attribute of the "class" that is most directly above this row
assoc - identifies an association leading from the class that is most directly above this row
stc - subtype constraint: row corresponds to a subcomponent of the row above; included in order
to be able to state a constraint on the subtype
Class or Property -- contains the information model name of the entity
Short name -- an abbreviated form of the name of the entity that will be used to tag the
corresponding message elements in ITS-specific syntaxes that use tags.
Inherited from. This is the class where the property (attribute or association) appears in
the Message Information Model.
Message Element Type. For attributes, this is the data type of the attribute. For
associations, this is the name of the distal class.
May 16, 2000
© 2000, HL7
101
R-MIM - Constraint section (1)
• Cardinality. This column contains the minimum and maximum number of
times that the message element can appear in any message instance based on
this R-MIM. The cardinality of most classes can be left blank and inferred.
Most frequently this column is used to state that a central, or root class for
messages derived from the R-MIM will be present exactly once, or at least
once.
• Domain Specification. This column contains a specification of the domain
specification for message elements that contain codes. The syntax of such a
specification is defined in Chapter 7.
• Coding Strength. This column contains either CWE (coded with exceptions)
or CNE (coded, no exceptions). It is blank in rows that do not describe a
message element that contains a code.
May 16, 2000
© 2000, HL7
102
R-MIM - Constraint section (2)
•
Mandatory. This column contains an M (mandatory) or is empty (not mandatory). If
mandatory, all message elements derived from this entity in any message instance must
contain a non-null value, or they must have a default that is not null.
•
Default Value. This column may contain a value that the receiver should use when it
receives a message instance that does not contain the message element derived from this
information model entity. If the column is left empty for a specific row, the "default default"
is the simple form of null (NI).
•
Conformance Flag. A cell in this column may contain an R (required) or be empty.
Possible conformance values are:
– Required. The message element must appear every time the message description is used for an
Interaction (subject to the rules of multiplicity and conditionality.) Note that all message elements
that have an inclusion value of mandatory must have a conformance value of required.
– Not Required. The message element may be populated or used by one system sponsor, but not by
another. Each system sponsor is required to state its ability to accept or send the message element
as part of its conformance claim.
– Not Permitted. This message element may never occur when the message type is used for an
interaction. (Having this is an artifact of using a single HMD to describe multiple message types.)
– Only the “Required” value may be asserted in the R-MIM. The other values are only appropriate
in the message section of an HMD
•
Constraint/Note. describes a constraint that applies to all message instances derived from
this Refined Message Information Model. Example might be "at least one instance of this
message element must identify the attending physician.”
May 16, 2000
© 2000, HL7
103
Optional/Mandatory, Null, Default,
and Required for Conformance
HMD
Mandatory
Name: Mandatory
DOB: Optional
VIP:
Optional
APP 1
(VIP: n/a)
DOB: Null
Name: Curlie
Default
No
Null
Null
HL7
HL7
X
Conformance
Required
Not Reqd
Not Reqd
APP 2
VIP: Null
DOB: Null
Name: Curlie
PT|Curlie|Null||
May 16, 2000
© 2000, HL7
104
R-MIM - Constraint section (3)
•
Default Update Mode. This column may contain a value that defines the update mode that
will be used for a message element when no update mode is explicitly sent in the message.
When the column is left empty for a cell, "default default" update mode is R (replace).
•
Update mode set. This column may contain a list of values that may be sent in message
instances to alter the receiver's processing from the default update mode. If the column is left
blank, the only permitted value is the default update mode.
•
Update code values:
–
–
–
–
–
–
–
–
–
R replace
D Delete
I Ignore
K(Key) this message element is used as a key to a collection of message elements
V (Verify) this message element must match a value already in the receiving systems database in
order to process the message
ESA Edit set add, add the message element to the collection of items on the receiving system that
correspond to the message element
ESD Edit set delete, delete the item on the receiving system that corresponds to this message
element
ESC Edit set change, change the item on the receiving system that corresponds to this message
element; do not process if a matching element does not exist
ESAC Edit set change, change the item on the receiving system that corresponds to this message
element; if a matching element does not exist, add a new one created with the values in the message
May 16, 2000
© 2000, HL7
105
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
R-MIM components
Update semantics
HMD components
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
106
Update Semantics
• Issue: how does one application tell another what to
change?
• Examples:
– Change one allergy or replace the whole collection?
– Send only the data fields that change, or send all
• Observation: at best this is described verbally in 2.X; at
worst we discover disagreements when chasing down
bugs.
May 16, 2000
© 2000, HL7
107
Different Update Paradigms
• R
replace (this is the default)
• D
delete
• I
ignore
• NA
not applicable
• V
verify: confirm that it exists
• K
key: when creating an element store it;
when updating an element confirm that it exists.
• When updating individual items in a set
–
–
–
–
May 16, 2000
ESA
ESC
ESD
ESAC
edit set: add item
edit set: change item
edit set: delete item
edit set: add or, if the item exists, change
© 2000, HL7
108
Update Semantics in Message Definitions
V e h ic le
F le e t
i d : TI I
has
owner : S T
0 . .1
P a th
ro o t
Edit Set Paradigms
permitted because there
is a key in the set.
p a rt _ o f i d : TI I
ty pe : C V
0..*
c o lo r : C V .0 . .n
M e s s a ge
Ca r di-
Ele m e nt
na lity
Type
Allow e d
De fa ult
Upda te
Upda te
P a r a digm s
P a r a digm
Fle e t
1
Fle e t
N
N
--
id
1
T II
V
V
--
o w n er
1
ST
I
I
h as
h as
ES A C , ES A D
ES A C
--
0 ..*
--
S e t< V e h i cl e >
--
V e h ic le
N
N
--
id
1
T II
K
K
--
ty p e
1
CV
R
R
--
c o lo r
1 ..*
Set < C V >
R
R
--
--
--
CV
N
N
May 16, 2000
© 2000, HL7
109
Update Semantics in Message Definitions
V e h ic le
F le e t
i d : TI I
has
owner : S T
0 . .1
P a th
ro o t
Edit Set Paradigms not
permitted because there
is no key in the set.
p a rt _ o f i d : TI I
ty pe : C V
0..*
c o lo r : C V .0 . .n
M e s s a ge
Ca r di-
Ele m e nt
na lity
Type
Allow e d
De fa ult
Upda te
Upda te
P a r a digm s
P a r a digm
Fle e t
1
Fle e t
N
N
--
id
1
T II
V
V
--
o w n er
1
ST
I
I
h as
h as
ES A C , ES A D
ES A C
--
0 ..*
--
S e t< V e h i cl e >
--
V e h ic le
N
N
--
id
1
T II
K
K
--
ty p e
1
CV
R
R
--
c o lo r
1 ..*
Set < C V >
R
R
--
--
--
CV
N
N
May 16, 2000
© 2000, HL7
110
Update Semantics in Message Definitions
V e h ic le
F le e t
i d : TI I
has
owner : S T
0 . .1
P a th
ro o t
p a rt _ o f i d : TI I
ty pe : C V
0..*
c o lo r : C V .0 . .n
M e s s a ge
Ca r di-
Ele m e nt
na lity
Type
What does this message do?
Creates, updates or deletes
one or more vehicles in a
predefined fleet.
Allow e d
De fa ult
Upda te
Upda te
P a r a digm s
P a r a digm
Fle e t
1
Fle e t
N
N
--
id
1
T II
V
V
--
o w n er
1
ST
I
I
h as
h as
ES A C , ES A D
ES A C
--
1 ..*
--
S e t< V e h i cl e >
--
V e h ic le
N
N
--
id
1
T II
K
K
--
ty p e
1
CV
R
R
--
c o lo r
1 ..*
Set < C V >
R
R
--
--
--
CV
N
N
May 16, 2000
© 2000, HL7
111
An “Edit Set” Where There is no Set???
V e h ic le
F le e t
i d : TI I
has
owner : S T
0 . .1
P a th
ro o t
p a rt _ o f i d : TI I
ty pe : C V
0..*
c o lo r : C V .0 . .n
M e s s a ge
Ca r di-
Ele m e nt
na lity
Type
What does this message do?
Creates, updates or deletes
one vehicle in a
predefined fleet.
Allow e d
De fa ult
Upda te
Upda te
P a r a digm s
P a r a digm
Fle e t
1
Fle e t
N
N
--
id
1
T II
V
V
--
o w n er
1
ST
I
I
h as
h as
ES A C , ES A D
ES A C
1 ..* 1
S e t< V e h i cl e >
--
--
--
V e h ic le
N
N
--
id
1
T II
K
K
--
ty p e
1
CV
R
R
--
c o lo r
1 ..*
Set < C V >
R
R
--
--
--
CV
N
N
May 16, 2000
© 2000, HL7
112
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
R-MIM components
Update semantics
HMD components
Building an R-MIM and HMD
May 16, 2000
© 2000, HL7
113
HMD components (1)
•
The Information Model Mapping. The columns that are in this section describe classes and
attributes of the R-MIM, organized in a sequence that describes a "walk" from class to class
on the R-MIM.
•
The Message Elements. The columns in this section describe the message elements and
define the Message Element Types. The message elements compose a hierarchy. This
hierarchy is illustrated by indentation in the column Message Element Name.
•
General constraints and defaults. Describe specific constraints and defaults for the message
element defined in the row. The columns are the same as the corresponding section of the RMIM. The values in the columns may be the same or may be a more restrictive constraint.
Repeat this set of nine
columns for each
message type defined
May 16, 2000
© 2000, HL7
114
HMD components (2)
• Message type definitions (repeating). This section repeats, once
for each message type defined in the Hierarchical Message
Definition. The columns that are in this section describe one or
more message types. Each message type is identified with one or
more interactions in the interaction model. The column headings
for each message type are the same as the column headings for
the general constraints. If the cells are left empty, the values will
be the same as in the general constraints section. When filled in,
they, may represent more restrictive constraints, or may indicate
that the specific message element is not a part of the specific
message type being defined in the section.
May 16, 2000
© 2000, HL7
115
HMD Information model section
• Row types
–
–
–
–
–
–
hmd - identifies the particular Hierarchical Message Definition
class - is only one class entry in HMD - the root class for the message.
assoc - identifies an association from the class that is most directly above this row
attr - identifies an attribute of a "class" in the R-MIM
item - identifies an element that represents one of whatever is repeated in a collection
stc - subtype constraint: corresponds to a subcomponent of the row above; included in
order to be able to state a constraint on the subtype
• Class or Property of Class. For an item, the name is empty. For an stc row, the
name will be populated if the subtype corresponds to an entity of the information
model. In an hmd row, this column identifies the parent R-MIM.
•
Rim Source Class. This column gives the name of the RIM class from which the
entity stems, regardless of inheritance or cloning that may appear in the R-MIM.
May 16, 2000
© 2000, HL7
116
HMD Message Elements Section (1)
•
Message Element Name. By row type, it contains:
– hmd - the identifier for the parent R-MIM
– class - same as the name in the R-MIM in the Class or Property of Class
column.
– attr - same as the in the R-MIM in the Class or Property of Class column,
unless the item has a maximum cardinality greater than one, in which case
the name is constructed by prepending Set or List to the name of the attribute
and an item row is included immediately underneath this row.
– assoc - name is constructed by combining the name of the association with
the name of the distal class of the association.
– item
– stc - name of the message element that is the subcomponent described by this
row.
• Message Element Short Name. An abbreviation of the name in the Message
Element Name column.
•
In Message Element Type(MET) . Every message element type except the one
defined in the first (class) row is a sub-element of a larger composite MET. This
column contains the name of the containing MET.
May 16, 2000
© 2000, HL7
117
HMD Message Elements Section (2)
•
Source Of Message Element Type (MET). Possible entries are:
– N - New type. This row starts the definition of a new MET. The subordinate rows
–
–
–
–
•
beneath it compose the definition of the type. Each subordinate row has the name
of the MET being defined in the In MET column. That name will be the same one
that is in the Of MET of this row.
D
- This MET is an HL7 data type.
C
- This MET is an HL7 common message element type.
U
- This MET was previously defined in this HMD and is being reused
R - This row represents the recursive reuse of the MET within which it appears.
Of MET - states the type of the message element defined in a row. Short
names are used. By row type:
– class - The cell contains the short name of the class.
– attr - The cell contains the short name of the data type of the attribute.
– assoc - This name is the short name of the distal class of the association.
However, if the association has a maximum cardinality greater than one, the name
is preceded by Set< or List< and followed by >. Multiple class names may appear
in this cell, in the case of choices.
– Item - Represents a single item in a set or list of elements
– stc - The type of the message element that is the subcomponent described by this
row.
May 16, 2000
© 2000, HL7
118
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
Assembling the MIM
Defining the R-MIM
Building the HMD
May 16, 2000
© 2000, HL7
119
Working the problem
• Problem definition
• Building the Information Model for the Message
• Creating message-specific “views”
• Defining the abstract message
• Expression in a DTD
• Example message instance
May 16, 2000
© 2000, HL7
120
V-3 Methodology - working the process
Use Case
Model
Reference
Information
Model
Domain
Information
Model
Message
Information
Model
Interaction
Model
Refined
Message
Information
Model
Common
Message
Element
Definition
Hierarchical
Message
Description
May 16, 2000
© 2000, HL7
121
Problem statement
• Domain facts:
– HL7 Voting Members are either: (a) individual members, or (b) sponsored by
an organizational member, usually their employer.
– Items for balloting are proposed by HL7 Committees or Subcommittees, and
the proposing committee designates an individual to serve as their contact for a
particular proposal.
– Voting members submit ballots on items proposed as HL7 standards.
– Each ballot may vote aye, nay or abstain, and all negative ballots must be
accompanied by a supporting comment.
• Messaging requirements:
– HL7 has a ballot acceptance system, and a ballot notification system.
– HL7 seeks a message to go from the ballot acceptance system to the ballot
notification system.
– This message will be sent upon receipt of a completed ballot.
– The message will allow the notification system to send a confirming e-mail to
each of: the voter, the voter’s sponsor organization (if any) and the contact
person for the item being voted upon.
May 16, 2000
© 2000, HL7
122
Portion of Reference Information Model (RIM)
Person_name
effective_dt
cd
nm
purpose_cd
termination_dt
type_cd
Stakeholder
addr
credit_rating_cd
email_address_txt
phon
type_cd
real_id : SET<RWII>
id : SET<II>
participates_as_primary_in
0..*
has_as_primary_participant
1
0..*
participates_as_secondary_in
1
has_as_secondary_participant
Stakeholder_affiliation
affiliation_type_cd
desc
effective_dt
termination_dt
0..* is_for
has_as_a_subdivision
0..1
1
has
Person
May 16, 2000
birth_dttm
birthplace_addr
citizenship_country_cd
confidentiality_constraint_cd
deceased_dttm
deceased_ind
disability_cd
education_level_cd
ethnic_group_cd
administrative_gender_cd
language_cd
marital_status_cd
military_branch_of_service_cd
military_rank_nm
military_status_cd
nationality_cd
race_cd
religious_affiliation_cd
student_cd
very_important_person_cd
status_cd
ambulatory_status_cd
id
hispanic_ind
birth_order_nbr
living_arrangement_cd
Organization
0..*
organization_name_type_cdis_a_subdivision_of
organization_nm
standard_industry_class_cd
© 2000, HL7
123
Initial message information model (MIM)
0..*
participates_as_primary_in
Stakeholder
1..1
has_as_primary_participant Stakeholder_affiliation
addr : ST
email_address_txt : TEL participates_as_secondary_in
0..* affiliation_type_cd : CD
id : SET<II>
1..1
has_as_secondary_participant
Person_name
nm : ST
type_cd : CD
0..*
is_for
1..1
has
Person
education_level_cd : CD
May 16, 2000
has_as_a_subdivision
0..1
Organization
0..*
organization_nm : ST
is_a_subdivision_of
© 2000, HL7
124
Message information model (MIM)
Person_name
effective_dt
cd
nm
purpose_cd
termination_dt
type_cd
Stakeholder
addr
credit_rating_cd
email_address_txt
phon
type_cd
real_id : SET<RWII>
id : SET<II>
participates_as_primary_in
0..*
has_as_primary_participant
1
0..*
participates_as_secondary_in
1
has_as_secondary_participant
Stakeholder_affiliation
affiliation_type_cd
desc
effective_dt
termination_dt
0..* is_for
has_as_a_subdivision
0..1
1
has
Person
birth_dttm
birthplace_addr
citizenship_country_cd
confidentiality_constraint_cd
deceased_dttm
deceased_ind
disability_cd
0..*
education_level_cdStakeholder
participates_as_primary_in
Person_name
ethnic_group_cd
1..1
has_as_primary_participant Stakeholder_affiliation
addr : ST
nm : ST
administrative_gender_cd
email_address_txt : TEL participates_as_secondary_in
0..* affiliation_type_cd : CD
type_cd : CD
language_cd id : SET<II>
1..1
has_as_secondary_participant
marital_status_cd
0..* is_for
military_branch_of_service_cd
military_rank_nm
military_status_cd
nationality_cd
race_cd
has_as_a_subdivision
1..1
religious_affiliation_cd
has
0..1
student_cd
Person
Organization
very_important_person_cd
0..*
status_cd
education_level_cd : CD
organization_nm : ST
is_a_subdivision_of
ambulatory_status_cd
id
1..1
1..1 proposes
1..1
has_as_role
hispanic_ind
sponsors
birth_order_nbr
0..* is_role_of
living_arrangement_cd
2000
© 2000, HL7
Proposed_item
living_dependency_cd
Fewer
attributes
May 16,
Organization
0..*
organization_name_type_cdis_a_subdivision_of
organization_nm
standard_industry_class_cd
RIM
content
MIM
content
(a proper subset
of the RIM) 125
Add voters to MIM
0..*
participates_as_primary_in
Stakeholder
1..1
has_as_primary_participant Stakeholder_affiliation
addr : ST
email_address_txt : TEL participates_as_secondary_in
0..* affiliation_type_cd : CD
id : SET<II>
1..1
has_as_secondary_participant
Person_name
nm : ST
type_cd : CD
0..*
is_for
has_as_a_subdivision
0..1
1..1
has
Person
education_level_cd : CD
Organization
0..*
organization_nm : ST
is_a_subdivision_of
1..1
has_as_role
sponsors
1..1
0..* is_role_of
Voting_member
draft_level_voting_ind : BL
standard_level_voting_ind : BL
0..* sponsored_by
Individual_representative
dues_current_ind : BL
Organizational_representative
HL7 Voting Members are either: (a) individual
members, or (b) sponsored by an organizational
member, usually their employer.
May 16, 2000
© 2000, HL7
126
Message information model (MIM)
0..*
0..*
participates_as_primary_in
Stakeholder
Stakeholder
Stakeholder_affiliation
1..1
has_as_primary_participant Stakeholder_affiliation
has_as_primary_participant
addr
addr :: ST
ST
email_address_txt : TEL participates_as_secondary_in
email_address_txt
affiliation_type_cd :: CD
CD
0..*
0..* affiliation_type_cd
id :: SET<II>
SET<II>
id
1..1
has_as_secondary_participant
has_as_secondary_participant
Person_name
Person_name
nm
nm :: ST
ST
type_cd :: CD
CD
type_cd
is_for
0..* is_for
0..*
1..1
1..1
has_as_a_subdivision
has_as_a_subdivision
0..1
has
has
Person
Person
education_level_cd :: CD
CD
education_level_cd
has_as_role
has_as_role
Organization
0..*
organization_nm : ST is_a_subdivision_of
is_a_subdivision_of
1..1
1..1
sponsors
1..1
1..1 proposes
is_role_of
0..* is_role_of
0..*
Proposed_item
ballot_period_tmr : IVL<TS>
proposed_by content_txt : ED
standard_level_ind : BL
Voting_member
Voting_member
draft_level_voting_ind
draft_level_voting_ind :: BL
standard_level_voting_ind : BL
1..1 standard_level_voting_ind
0..*
casts
Individual_representative
Individual_representative
dues_current_ind :: BL
BL
dues_current_ind
0..* sponsored_by
sponsored_by
0..*
Organizational_representative
Organizational_representative
cast_by
0..*
May 16, 2000
1..1
receives_votes
Items for balloting are proposed by HL7
Committees or Subcommittees, Voting
votes_on
members submit ballots on items. Each ballot
Ballot
comments_txt : ST 0..* may vote aye, nay or abstain, and all negative
dttm : TS
ballots must be accompanied by a supporting
vote_cd : CV
© 2000, HL7 comment.
127
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
Assembling the MIM
Defining the R-MIM
Building the HMD
May 16, 2000
© 2000, HL7
128
V-3 Methodology - working the process
Use Case
Model
Reference
Information
Model
Domain
Information
Model
Message
Information
Model
Interaction
Model
Refined
Message
Information
Model
Common
Message
Element
Definition
Hierarchical
Message
Description
May 16, 2000
© 2000, HL7
129
Message information model (MIM)
0..*
participates_as_primary_in
Stakeholder
1..1
has_as_primary_participant Stakeholder_affiliation
addr : ST
email_address_txt : TEL participates_as_secondary_in
0..* affiliation_type_cd : CD
id : SET<II>
1..1
has_as_secondary_participant
Person_name
nm : ST
type_cd : CD
0..*
is_for
has_as_a_subdivision
0..1
1..1
has
Person
education_level_cd : CD
Organization
0..*
organization_nm : ST
is_a_subdivision_of
1..1
has_as_role
sponsors
1..1 proposes
1..1
0..* is_role_of
Proposed_item
ballot_period_tmr : IVL<TS>
proposed_by content_txt : ED
standard_level_ind : BL
Voting_member
draft_level_voting_ind : BL
1..1 standard_level_voting_ind : BL
0..*
casts
0..* sponsored_by
Individual_representative
dues_current_ind : BL
Organizational_representative
cast_by
May 16, 2000
1..1
receives_votes
Ballot
comments_txt
: ST
0..*
dttm : TS
vote_cd : CV
votes_on
0..*
© 2000, HL7
130
Partially morphed MIM
Person_name
nm : ST
type_cd : CD
0..*
has_as_secondary_participant
Stakeholder_affiliation
affiliation_type_cd : CD
0..*
0..*
1..1
has_as_primary_participant
is_for
1..1 participates_as_primary_in
has participates_as_secondary_in
1..1
Person
education_level_cd : CD
email_address_txt : TEL
has_as_role
has_as_a_subdivision
0..1
Organization
0..*
organization_nm : ST
is_a_subdivision_of
email_address_txt : TEL
1..1
sponsors
0..* is_role_of
1..1
1..1 proposes
Proposed_item
ballot_period_tmr : IVL<TS>
proposed_by content_txt : ED
standard_level_ind : BL
Voting_member
draft_level_voting_ind : BL
1..1 standard_level_voting_ind : BL
0..*
casts
0..* sponsored_by
Individual_representative
dues_current_ind : BL
Organizational_representative
cast_by
May 16, 2000
1..1
receives_votes
Ballot
comments_txt
: ST
0..*
dttm : TS
vote_cd : CV
votes_on
0..*
© 2000, HL7
131
Remove inconsequential inheritance
0..*
participates_as_primary_in
Stakeholder
1..1
has_as_primary_participant Stakeholder_affiliation
addr : ST
email_address_txt : TEL participates_as_secondary_in
0..* affiliation_type_cd : CD
id : SET<II>
1..1
has_as_secondary_participant
Person_name
nm : ST
type_cd : CD
is_for
0..*
has_as_a_subdivision
0..1
1..1
has
Person
education_level_cd : CD
Organization
0..*
organization_nm : ST
is_a_subdivision_of
1..1
has_as_role
sponsors
1..1
1..1 proposes
0..* is_role_of
Subsume inherited attributes
Voting_member
draft_level_voting_ind : BL
1..1 standard_level_voting_ind : BL
Person_name
nmcasts
: ST
type_cd : CD
0..*
is_for
Individual_representative
dues_current_ind : BL
1..1
May 16, 2000
Proposed_item
Transfer
inherited
associations
0..*
ballot_period_tmr : IVL<TS>
proposed_by content_txt : ED
0..*
standard_level_ind : BL
Stakeholder_affiliation
has_as_secondary_participant
affiliation_type_cd : CD
1..1
0..*
receives_votes
has_as_primary_participant
0..* sponsored_by
Organizational_representative
1..1 participates_as_primary_in
has participates_as_secondary_in
1..1
has_as_a_subdivision
0..1
Person
Organization
0..*
votes_on
education_level_cd : CDcast_by
organization_nm
: ST
Ballot
is_a_subdivision_of
email_address_txt : TEL
email_address_txt : TEL
0..* comments_txt : ST 0..*
dttm : TS
1..1
2000,1..1HL71..1 proposes
vote_cd©
: CV
has_as_role
sponsors
132
Partially morphed MIM
Person_name
nm : ST
type_cd : CD
0..*
has_as_secondary_participant
Stakeholder_affiliation
affiliation_type_cd : CD
0..*
0..*
1..1
has_as_primary_participant
is_for
1..1 participates_as_primary_in
has participates_as_secondary_in
1..1
Person
education_level_cd : CD
email_address_txt : TEL
has_as_role
has_as_a_subdivision
0..1
Organization
0..*
organization_nm : ST
is_a_subdivision_of
email_address_txt : TEL
1..1
sponsors
0..* is_role_of
1..1
1..1 proposes
Proposed_item
ballot_period_tmr : IVL<TS>
proposed_by content_txt : ED
standard_level_ind : BL
Voting_member
draft_level_voting_ind : BL
1..1 standard_level_voting_ind : BL
0..*
casts
0..* sponsored_by
Individual_representative
dues_current_ind : BL
Organizational_representative
cast_by
May 16, 2000
1..1
receives_votes
Ballot
comments_txt
: ST
0..*
dttm : TS
vote_cd : CV
votes_on
0..*
© 2000, HL7
133
Refined Message Information Model (R-MIM)
Person_name
is_for
nm : ST
type_cd : CD
0..1
is_for
0..*
has
1..1
has_as_secondary_participant
0..*
Stakeholder_affiliation
affiliation_type_cd : CD
0..*
participates_as_secondary_in
has_as_primary_participant
1..1
has 1..1
Person_as_Committee_contact
email_address_txt : TEL
participates_as_primary_in has_as_a_subdivision
0..1
1..1
Person_as_Voter
education_level_cd : CD
email_address_txt : TEL
Organization_as_Committee
organization_nm : ST
1..1
has_as_role
1..1
is_role_of 0..*
Voting_member
draft_level_voting_ind : BL
1..1 standard_level_voting_ind : BL
is_a_subdivision_of
proposes
proposed_by
Organization_as_HL7_member
organization_nm : ST
email_address_txt : TEL
casts
sponsors
Individual_representative
dues_current_ind : BL
0..*
0..1
0..* sponsored_by
Organizational_representative
votes_on
Ballot
0..*
0..* comments_txt : ST
dttm : TS
vote_cd : CV
0..*
Proposed_item
ballot_period_tmr : IVL<TS>
content_txt : ED
standard_level_ind : BL
1..1
receives_votes
cast_by
May 16, 2000
© 2000, HL7
134
Refined Message Information Model (R-MIM)
has_as_secondary_participant
0..*
Person_name
is_for
nm : ST
type_cd : CD
0..1
is_for
0..*
has
1..1
0..*
participates_as_secondary_in
has_as_primary_participant
1..1
has 1..1
Person_as_Committee_contact
email_address_txt : TEL
participates_as_primary_in has_as_a_subdivision
0..1
1..1
Person_as_Voter
education_level_cd : CD
email_address_txt : TEL
Organization_as_Committee
organization_nm : ST
1..1
has_as_role
Person_name
nm : ST
type_cd : CD
0..*
1..1
0..*
is_a_subdivisi
proposes
0..*
is_role_of 0..*
Stakeholder_affiliation
proposed_by
has_as_secondary_participant
Proposed
Voting_member affiliation_type_cd : CD
0..*
Organization_as_HL7_member
ballot_period_tm
0..*
draft_level_voting_ind : BL
organization_nm : ST
content_txt : ED
standard_level_voting_ind : BL
1..1
has_as_primary_participant
email_address_txt : TEL
standard_level_i
casts
is_for
Specialize cloned views of Person
to meet specific requirements
sponsors
has_as_a_subdivision
1..1 participates_as_primary_in
has participates_as_secondary_in
1..1
0..1
Individual_representative
Person
Organization
0..* : BL
dues_current_ind
education_level_cd : CD
organization_nm : ST
is_a_subdivision_of
email_address_txt : TEL
email_address_txt : TEL
1..1
has_as_role
Stakeholde
affiliation_typ
1..1
0..* is_role_of
Voting_member
draft_level_voting_ind : BL
: BL
1..1 standard_level_voting_ind
May
16, 2000
sponsors
1..1
1..1 proposes
0..1
0..* sponsored_by
Organizational_representative
1..1
receives
votes_on of associations
Constrain
Ballot navigability
cast_by
0..*
Proposed_item
0..* comments_txt : ST
dttm :: IVL<TS>
TS
ballot_period_tmr
vote_cd
: CV
content_txt
:
ED
proposed_by
2000,
HL7standard_level_ind : BL
0..*
©
135
Refined Message Information Model (R-MIM)
Person_name
is_for
nm : ST
type_cd : CD
0..1
is_for
0..*
has
1..1
has_as_secondary_participant
0..*
Stakeholder_affiliation
affiliation_type_cd : CD
0..*
participates_as_secondary_in
has_as_primary_participant
1..1
has 1..1
Person_as_Committee_contact
email_address_txt : TEL
participates_as_primary_in has_as_a_subdivision
0..1
1..1
Person_as_Voter
education_level_cd : CD
email_address_txt : TEL
Organization_as_Committee
organization_nm : ST
1..1
has_as_role
1..1
is_role_of 0..*
Voting_member
draft_level_voting_ind : BL
1..1 standard_level_voting_ind : BL
is_a_subdivision_of
proposes
proposed_by
Organization_as_HL7_member
organization_nm : ST
email_address_txt : TEL
casts
sponsors
Individual_representative
dues_current_ind : BL
0..*
0..1
0..* sponsored_by
Organizational_representative
votes_on
Ballot
0..*
0..* comments_txt : ST
dttm : TS
vote_cd : CV
0..*
Proposed_item
ballot_period_tmr : IVL<TS>
content_txt : ED
standard_level_ind : BL
1..1
receives_votes
cast_by
May 16, 2000
© 2000, HL7
136
Our agenda
Refresher - Why do we care?
Reading a UML model
Vocabulary, codes and terminology
Data types, structure and objectives
Structure of a message
Reading an R-MIM and an HMD
Building an R-MIM and HMD
Assembling the MIM
Defining the R-MIM
Building the HMD
May 16, 2000
© 2000, HL7
137
V-3 Methodology - working the process
Use Case
Model
Reference
Information
Model
Domain
Information
Model
Message
Information
Model
Interaction
Model
Refined
Message
Information
Model
Common
Message
Element
Definition
Hierarchical
Message
Description
May 16, 2000
© 2000, HL7
138
Refined Message Information Model (R-MIM)
Person_name
is_for
nm : ST
type_cd : CD
0..1
5
is_for
0..*
has_as_secondary_participant
0..*
3
0..*
participates_as_secondary_in
has_as_primary_participant
1..1
has 1..1
Person_as_Committee_contact
email_address_txt : TEL
4
has
Stakeholder_affiliation
affiliation_type_cd : CD
1..1
Person_as_Voter
education_level_cd : CD
email_address_txt : TEL
2a
participates_as_primary_in has_as_a_subdivision
0..1
1..1
Organization_as_Committee
organization_nm : ST
2
1..1
has_as_role
1..1
is_role_of 0..*
Voting_member
draft_level_voting_ind : BL
1..1 standard_level_voting_ind : BL
is_a_subdivision_of
proposes
proposed_by
Organization_as_HL7_member
organization_nm : ST
email_address_txt : TEL
casts
sponsors
Individual_representative
dues_current_ind : BL
0..*
0..1
0..* sponsored_by
Organizational_representative
votes_on
Ballot
0..*
0..* comments_txt : ST
dttm : TS
vote_cd : CV
0..*
Proposed_item
ballot_period_tmr : IVL<TS>
content_txt : ED
standard_level_ind : BL
1
1..1
receives_votes
cast_by
May 16, 2000
© 2000,0HL7
139
Refined Message Information Model (R-MIM)
has_as_secondary_participant
0..*
Person_name
is_for
nm : ST
type_cd : CD
0..1
is_for
0..*
has
1..1
Stakeholder_affiliation
affiliation_type_cd : CD
0..*
participates_as_secondary_in
has_as_primary_participant
1..1
has 1..1
Person_as_Committee_contact
email_address_txt : TEL
participates_as_primary_in has_as_a_subdivision
0..1
1..1
Person_as_Voter
education_level_cd : CD
email_address_txt : TEL
Organization_as_Committee
organization_nm : ST
7
1..1
has_as_role
1..1
is_role_of 0..*
Voting_member
draft_level_voting_ind : BL
1..1 standard_level_voting_ind : BL
Organization_as_HL7_member
organization_nm : ST
email_address_txt : TEL
6
10
sponsors
8
is_a_subdivision_of
proposes
proposed_by
casts
Individual_representative
dues_current_ind : BL
0..*
0..1
0..*
Proposed_item
ballot_period_tmr : IVL<TS>
content_txt : ED
standard_level_ind : BL
1..1
0..* sponsored_by
Organizational_representative
receives_votes
9
votes_on
Ballot
0..*
0..* comments_txt : ST
dttm : TS
vote_cd : CV
cast_by
May 16, 2000
© 2000,0HL7
140
Walk gives HMD structure
May 16, 2000
© 2000, HL7
141
HMD adds constraints, defaults, cardinality, etc.
Link to RIM
Vocab domain
constraints,
cardinality,
etc.
May 16, 2000
© 2000, HL7
142
Conversion from HMD to a DTD is algorithmic
DTD for-->
HMD C00_RIM_0092Da_1
<!-- HL7-generated
Element Definitions
19991205 -->
<!ELEMENT Ballt
%Ballt-cont.model;>
<!ENTITY %Ballt
V3DT SYSTEM "V3DT991006a.dtd">
<!ATTLIST
%Ballt-attrib.list;
HL7_NAME
CDATA
#FIXED 'Ballot'
%V3DT;
>
<!-- Entity
Definitions -->
<!ELEMENT
IndvdlReprsntv
%IndvdlReprsntvcont.model;>
<!ENTITY %IndvdlReprsntv
Ballt-cont.model
"(commntsTxt?,
<!ATTLIST
%IndvdlReprsntvdttm?, vote, votesOn_PropsdItm, castBy_VotngMembr)?">
attrib.list;
<!ENTITY
% Ballt-attrib.list
HL7_NAME
CDATA "#FIXED
T
CDATA
#FIXED 'Ballt'
'Individual_representative'
NULL
%null.code.set; #IMPLIED
>
NOTE
CDATA
#IMPLIED
….
UPDATE_MODE %update.mode.code.set;
'R'
<!ELEMENT balltPeriodTmr
%IVL_TS-cont.model;>
">
<!ATTLIST
balltPeriodTmr
%IVL_TS-attrib.list;
HL7_NAME
CDATA
#FIXED 'balltPeriodTmr'
<!ENTITY % PropsdItm-cont.model
"(balltPeriodTmr?,
>
contntTxt?, standrdLevlInd?,
propsdBy_OrgnztnAsCommtte)?">
<!ELEMENT
castBy_VotngMembr
%VotngMembr<!ENTITY % PropsdItm-attrib.list "
cont.model;>
T
CDATA
#FIXED 'PropsdItm'
<!ATTLIST castBy_VotngMembr
%VotngMembr%null.code.set; #IMPLIED
attrib.list; NULL
CDATA #FIXED #IMPLIED
HL7_NAME NOTE
CDATA
'castBy_VotngMembr'
UPDATE_MODE %update.mode.code.set; 'R'
>
">
<!ELEMENT emailAddrssTxt
%TEL-cont.model;>
<!ENTITY %emailAddrssTxt
OrgnztnAsHL7Membr-cont.model
"(nm,
<!ATTLIST
%TEL-attrib.list;
emailAddrssTxt?)?">
HL7_NAME
CDATA
#FIXED 'emailAddrssTxt'
<!ENTITY % OrgnztnAsHL7Membr-attrib.list "
>
T
CDATA
#FIXED 'OrgnztnAsHL7Membr'
NULL
%null.code.set; #IMPLIED
NOTE
CDATA
<!ELEMENT vote
%CV-cont.model;>
#IMPLIED
<!ATTLIST vote
%CV-attrib.list;
%update.mode.code.set;
'R'
HL7_NAME UPDATE_MODE
CDATA
#FIXED 'vote'
">
>
May 16, 2000
© 2000, HL7
143
V-3 Methodology - sending a message instance
Hierarchical
Message
Description
1. Use HMD to collect & structure data
2. Use ITS to format message instance
3. Communicate the instance
4. Use ITS to parse message instance
ITS
5. Use HMD to disassemble and store data
Implementation
Technology
Specifications
Data
HL7
Message
Creation
Message
Instance
HL7-Conformant
Application
May 16, 2000
HL7
Message
Parsing
Data
HL7-Conformant
Application
© 2000, HL7
144
Message instance
<?xml version="1.0"?>
<!DOCTYPE Ballt SYSTEM "Ballot_C00_RIM_0092Da_1.dtd" [ ]>
<Ballt>
<dttm V="199912052357+0100"/>
<castBy_VotngMembr T="OrgnztnlReprsntv">
<vote V="A" S="HL7001" R="3.0" PN="Abstain"/>
<OrgnztnlReprsntv>
<votesOn_PropsdItm>
<isRoleOf_PrsnAsVotr>
<standrdLevlInd V='T'/>
<has_PrsnName>
<propsdBy_OrgnztnAsCommtte>
<pnm>
<nm V="Humble Task Group"/>
<G V="George" CLAS="R"/>
<isAsubdvsnOf_OrgnztnAsCommtte>
<G V="W." CLAS="R I"/>
<nm V="Grand Committee"/>
<F V="Beeler" CLAS="R"/>
</isAsubdvsnOf_OrgnztnAsCommtte>
</pnm>
<partcpesAsPrimryIn_StkhldrAffltn>
</has_PrsnName>
<_StkhldrAffltn>
<has_PrsnName>
<type V="X" S="HL7004" R="3.0" PN="XXX"/>
<pnm>
<hasSecndryPartcpnt_PrsnAsCommtteContct>
<G V="Woody" CLAS="C"/>
<has_PrsnName>
<G V="W." CLAS="R I"/>
<pnm>
<F V="Beeler" CLAS="R"/>
<G V="George" CLAS="R"/>
</pnm>
<G V="Woody" CLAS="C"/>
</has_PrsnName>
<G V="W." CLAS="R I"/>
</isRoleOf_PrsnAsVotr>
<F V="Beeler" CLAS="R"/>
<sponsrdBy_OrgnztnAsHL7Membr>
</pnm>
<nm V="Mayo Clinic"/>
</has_PrsnName>
<emailAddrssTxt v=“[email protected]”/>
</hasSecndryPartcpnt_PrsnAsCommtteContct>
</sponsrdBy_OrgnztnAsHL7Membr>
</_StkhldrAffltn>
</OrgnztnlReprsntv>
</partcpesAsPrimryIn_StkhldrAffltn>
</castBy_VotngMembr>
</propsdBy_OrgnztnAsCommtte>
</Ballt>
</votesOn_PropsdItm>
May 16, 2000
© 2000, HL7
145
Auditability - Message
DTD Entity
Hierarchical
Refined
Element
Message
instance
Information
definitions
Message
definition
Info.Model
Description
Model
0..*
participates_as_primary_in
DTD for-->
HMD C00_RIM_0092Da_1
<!-- HL7-generated
Element Definitions
Stakeholder
has_as_secondary_participant
Person_name
<?xml version="1.0"?>
19991205
-->
Stakeholder_affiliation
1..1
has_as_primary_participant
is_for addr : ST
0..*
nm : ST
<!ELEMENT
Ballt
%Ballt-cont.model;>
<!DOCTYPE Ballt
SYSTEM
"Ballot_C00_RIM_0092Da_1.dtd"
[
]>
participates_as_secondary_in
email_address_txt
:
TEL
affiliation_type_cd
CD
:: CD
type_cd : CD
0..*0..*affiliation_type_cd
0..1
<!ENTITY
%
V3DT
SYSTEM
"V3DT991006a.dtd">
<!ATTLIST
Ballt
%Ballt-attrib.list;
id : SET<II>
1..1
participates_as_secondary_in
has_as_secondary_participant
has_as_primary_participant
HL7_NAME
CDATA
#FIXED 'Ballot'
<Ballt>
1..1
is_for
0..*
%V3DT;
>
is_for 0..*
has 1..1
<dttm V="199912052357+0100"/>
Person_as_Committee_contact
<vote V="A" S="HL7001"
R="3.0" PN="Abstain"/> <!ELEMENT
<!-- Entity
Definitions -->
IndvdlReprsntv
%IndvdlReprsntvemail_address_txt
:
TEL
cont.model;>
<castBy_VotngMembr T="OrgnztnlReprsntv">
<votesOn_PropsdItm>
<!ENTITY
%IndvdlReprsntv
Ballt-cont.model
"(commntsTxt?,
<!ATTLIST
%IndvdlReprsntvparticipates_as_primary_in
<OrgnztnlReprsntv>
<standrdLevlInd
has_as_a_subdivision
1..1V='T'/>
has 1..1
has_as_a_subdivision castBy_VotngMembr)?">
dttm?, vote, votesOn_PropsdItm,
attrib.list;
has
0..1
<propsdBy_OrgnztnAsCommtte>
0..1 <isRoleOf_PrsnAsVotr>
1..1
<!ENTITY
% Ballt-attrib.list
HL7_NAME
CDATA "#FIXED
Person_as_Voter
<has_PrsnName>
<nm V="Humble Task
Group"/>
Person
Organization
Organization_as_Committee
T
CDATA
#FIXED 'Ballt'
'Individual_representative'
0..*
0..*
education_level_cd : CD
<pnm>
<isAsubdvsnOf_OrgnztnAsCommtte>
NULL
%null.code.set;
#IMPLIED
>
education_level_cd
organization_nm
: ST
organization_nm
: ST
email_address_txt
: TEL : CD
is_a_subdivision_of
is_a_subdivision_of
NOTE
CDATA
#IMPLIED
….
<G V="George" CLAS="R"/>
<nm V="Grand Committee"/>
UPDATE_MODE
<!ELEMENT balltPeriodTmr
%IVL_TS-cont.model;>
1..1
<G %update.mode.code.set;
V="W." CLAS="R
I"/>'R'
</isAsubdvsnOf_OrgnztnAsCommtte>
1..1 proposes
1..1
1..1 proposes
1..1
has_as_role
">
<!ATTLIST
balltPeriodTmr
%IVL_TS-attrib.list;
has_as_role
sponsors
<F
V="Beeler"
CLAS="R"/>
<partcpesAsPrimryIn_StkhldrAffltn>
HL7_NAME
CDATA
#FIXED 'balltPeriodTmr'
is_role_of
</pnm>
<_StkhldrAffltn>
0..*
<!ENTITY % PropsdItm-cont.model
"(balltPeriodTmr?,
>
is_role_of 0..*
proposed_by
</has_PrsnName>
<type V="X"
S="HL7004"
R="3.0"
PN="XXX"/>
Proposed_item
contntTxt?,
standrdLevlInd?,
Voting_member
0..*
0..*
Organization_as_HL7_member
propsdBy_OrgnztnAsCommtte)?">
<!ELEMENT
castBy_VotngMembr
%VotngMembr<has_PrsnName>
<hasSecndryPartcpnt_PrsnAsCommtteContct>
ballot_period_tmr : IVL<TS>
draft_level_voting_ind : BL
<!ENTITY
%
PropsdItm-attrib.list
"
cont.model;>
organization_nm : ST
content_txt : ED
<pnm>
proposed_by
standard_level_voting_ind : BL
1..1
1..1<has_PrsnName>
T
CDATA
#FIXED 'PropsdItm'
<!ATTLIST
castBy_VotngMembr
%VotngMembremail_address_txt
: TEL
standard_level_ind
<G %null.code.set;
V="Woody": BLCLAS="C"/>
<pnm>
casts
#IMPLIED
attrib.list; NULL
<G
V="W."
CLAS="R
I"/>
<G V="George" CLAS="R"/> 0..1 HL7_NAME NOTE
CDATA
#IMPLIED
CDATA
#FIXED
'castBy_VotngMembr'
sponsors
1..1
<F %update.mode.code.set;
V="Beeler"
CLAS="R"/>
<G V="Woody" CLAS="C"/>
1..1
UPDATE_MODE
'R'
>
">
</pnm> receives_votes
<G V="W." CLAS="R I"/> 0..*
receives_votes
sponsored_by
0..* sponsored_by
<!ELEMENT emailAddrssTxt
%TEL-cont.model;>
</has_PrsnName>
<F V="Beeler" CLAS="R"/>
<!ENTITY
%
OrgnztnAsHL7Membr-cont.model
"(nm,
<!ATTLIST
emailAddrssTxt
%TEL-attrib.list;
Organizational_representative
Individual_representative
</isRoleOf_PrsnAsVotr>
</pnm>
emailAddrssTxt?)?">
HL7_NAME
CDATA
#FIXED
'emailAddrssTxt'
dues_current_ind :: BL
BL
dues_current_ind
</has_PrsnName>
<!ENTITY %<sponsrdBy_OrgnztnAsHL7Membr>
OrgnztnAsHL7Membr-attrib.list "
>
V="Mayo#FIXED
Clinic"/>
</hasSecndryPartcpnt_PrsnAsCommtteContct>
T <nm CDATA
'OrgnztnAsHL7Membr'
NULL
%null.code.set;
#IMPLIED
<emailAddrssTxt v=“[email protected]”/>
</_StkhldrAffltn>
NOTE
CDATA
<!ELEMENT
vote
%CV-cont.model;>
</sponsrdBy_OrgnztnAsHL7Membr>
</partcpesAsPrimryIn_StkhldrAffltn>
#IMPLIED
<!ATTLIST
vote
%CV-attrib.list;
votes_on
votes_on
</OrgnztnlReprsntv>
</propsdBy_OrgnztnAsCommtte> cast_by
Ballot
%update.mode.code.set;
'R'
HL7_NAME UPDATE_MODE
CDATA
#FIXED 'vote'
</castBy_VotngMembr>
</votesOn_PropsdItm>
0..*
">
comments_txt
:
ST
>
0..*
0..*
0..*
</Ballt>
dttm : TS
May 16, 2000
vote_cd : CV
© 2000, HL7
146
V-3 Methodology - defining abstract message
Use Case
Model
Reference
Information
Model
Domain
Information
Model
Message
Information
Model
Interaction
Model
Refined
Message
Information
Model
Common
Message
Element
Definition
Hierarchical
Message
Description
May 16, 2000
© 2000, HL7
147
Questions?
May 16, 2000
© 2000, HL7
148