conformance tutorial - hl7
TRANSCRIPT
1
HL7 2.X Conformance Tutorial
Ioana Singureanu, Eversolve Mary Ann Juurlink, Killdara
January 2001
2
Speakers Ioana Singureanu, CEO [email protected]
Mary Ann Juurlink, Healthcare Product Architect, Killdara
4
Part 1 : Conformance Concepts
Overview of HL7 2.x Conformance• Conformance Concepts
• Use case derived message profilesIoana Singureanu
Sample Conformance documentationMary Ann Juurlink
5
Part 2: Hands-on tutorial
• Hands-on message profiling exercise• Real-life scenarios• See the specification and tool in
action !
6
Part 1 : Conformance Concepts
Overview of HL7 2.x Conformance• Conformance Concepts• Use case derived message
profiles
Ioana Singureanu
7
The problem... Interoperability standard for clinical
application – uptake … The standard combines the collective
experience of many vendors Multiple business requirement sets combined
but not enough specificity for any given implementation: optionality.
Optional message elements had encouraged standard uptake but created difficulties in establishing standard conformance
Z-segments, Z-triggers, optional fields and segments are all allowed by the standard.
LACK OF UNIFORM SEMANTICS
8
The solution...
• Add specificity to existing messages and identify the specific scenarios/use cases
• Identify, document, and bridge semantic differences
• Eliminate optionality (“implementable”)
• UML- Unified Methodology Language (just like V3)
RIM
CommonMessage
Type
MessageType
MessageType
MessageProfile
Collective Experience
equivalent
V3 V2.X
MDF
Requirements Requirements
9
Conformance SIG
• HL7 Conformance has two objectives:– Interoperability
• Implementable message profiles– Certification
• Conformance Statement• Informative Documentation
– Specification for Message Profile Content• Tutorial - education• You are invited…
10
Glossary…
• Message Profile• Conformant Message Profile • Message profile id • Conformance Statement • Compatibility • Consistency • Registration• Certification• Validation
11
Message Profile
Message specification indicating a precise, unambiguous use of message constructs (segments, fields, data types) for exchanging information based on a messaging standard.
• A message specification where “optional” are disallowed and repeatable constructs will be bound by maximum cardinality specifications.
• developed by vendors to describe their applications’ interoperability
• developed by healthcare providers to describe their interoperability needs.
12
Message Profiles specify…• Use Case Model (UML) and Vocabulary
(field semantics, code sets, user-defined value sets)
• Static message profile– Message,segment, field, data type
• Dynamic interaction – Initiating message, response message
13
Message Profile = Static Profile + Dynamic Profile
Critical Care Unit
A/D/T System
Initiating MessageResponse Message
Initiating Message
Clinical Data Repository
Conceptual Overview
14
Static Message Profile
...
...
...
MSHEVNPID
NK1 NK1 NK1 NK1 NK1PV1
PV2
OBXAL1
ADT^A01
...
HL7(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A01(1).NULL(0).NULL(0).1(1)
Fields/Components: - Field Usage (Optionality) (R, RE, C, CE, X) - Cardinality (max repeats) - Value Sets/Coding system - Descriptions
...
...
MSHEVNPIDNK1 NK1 NK1 NK1 NK1PV1
PV2
OBXAL1
Segments/Segment Groups: - Cardinality (min, max)
Message ProfileHL7 Message Structure
15
Specification of Min, Max Cardinality
ADT^A01 ADT Message Chapter
MSH 1..1 Message Header 2EVN 1..1 Event Type 3PID 1..1 Patient Identification 3[ { NK1 } ]1..3 Next of Kin 3PV1 1..1 Visit Info 3PV2 1..1 Visit - additional info 3[ { OBX } ]0..0 Observation/Result 7[ { AL1 } ]1..* Allergy Information 3[ { DG1 } ]0..0 Diagnosis Information 6[ { PR1 } ]0..0 Procedures 6[ { GT1 } ]0..0 Guarantor Information 6[ 0..0 { IN1 0..0 Insurance Information 6 [ IN2 ] 0..0 Insurance Information - Addit. Info. 6 [ IN3 ] 0..0 Insurance Information - Cert. 6 }][ ACC ] 0..0 Accident Information 6[ UB1 ] 0..0 Universal Bill Information 6[ UB2 ] 0..0 Universal Bill 92 Information 6
Message Profile Specification HL7(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A01(1).NULL(0).NULL(0).1(1)
16
Segment Profile SpecificationSEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME
1 4 SI X 00104 Set ID - Patient ID
2 16 CK RE 00105 Patient External ID
3 20 CM R Y 00106 Patient Internal ID
4 12 ST X Y 00107 Alternate Patient ID
5 48 PN R 00108 Patient Name
6 30 ST RE 00109 Mother's Maiden Name
7 26 TS RE 00110 Date of Birth
8 1 ID RE 0001 00111 Sex
9 48 PN X Y 00112 Alias
10 1 ID X 0005 00113 Race
11 106 AD RE Y/3 00114 Address
12 4 ID X 00115 County Code
13 40 TN X Y/3 00116 Home Phone Number
14 40 TN X Y/3 00117 Business Phone Number
15 25 ST X 00118 Primary Language
16 1 ID X 0002 00119 Marital Status
17 3 ID X 0006 00120 Religion
18 20 CK X 00121 Patient Account Number
19 16 ST RE 00122 SSN Number - Patient
20 25 CM X 00123 Driver's Lic Num - Patient
21 20 CK X 00124 Mother's Identifier
22 1 ID X 0189 00125 Ethnic Group
23 25 ST RE 00126 Birth Place
Specification of Field Usage and Cardinality
17
1.1.1 OBX-8 Abnormal flags (ID) 00576Definition: This field is used to indicate the normalcy status of the result.
This field will be specified with a repeat count of three (3). The first repetition willspecify the abnormal flag. The second repetition will specify the delta flag. The thirdrepetition will specify the microbial susceptibilities.
Values from HL7 table #0078:
- abnormal flags alpha {N,A,AA,CNM} numeric {L,H,LL,HH,CNM,<,>}
- delta flags alpha {B,W} numeric {U,D}
- microbial susceptibility flags {S,R,I,MS,VS}
Only the most extreme flag for each repetition of the field should be specified.
Note that the value “CNM” (Could Not Measure) has been added to HL7 table #0078.
Field/Component Profile Specification
• Field Descriptions– In cases where HL7 2.x
fields descriptions are unclear or ambiguous, supply a more precise semantic definition.
18
Field/Component Profile Specification
• Vendor defined tables: – HL7 2.2 definition of PID-26 refers to Table #0171 which is
undefined– HL7 suggests using ISO-3166– ISO 3166 has 3 different coding schemes - Alpha-2, Alpha-3,
Numeric– A vendor/provider may choose ISO-3166 - Alpha-3
PID-26 Citizenship (ID) 00129Definition: indicates the patient's country of citizenship. Refer to user-defined table 0171 -country code for suggested values or to ISO 3166.
This vendor profile specification uses ISO 3166 Alpha-3 codes.
19
Message Profile Hierarchy
NULL (0)
NULL (0) DEVICE(2)
A01(1)
v2_2(4)Version
static-profile(1)
ADT(3)
O01(92)A02 (2)
1(1) 1(1)
NEW(1)
1(1) 1(1)
CANCEL(4)...
DIAG(1)
ORM(21)
NULL (0)
NULL (0) NEW(1)
1(1) 1(1)
CANCEL(4) ...
DIET(2) ...
ORU(23)
R01(112)
NULL (0)
LAB(1)
1(1) 1(1)
Profile Type
Message Type
Trigger Event
Structure
Use Model
Data Version
Registration Authority HL7(1)
Organization HL7(1)
20
Dynamic Interaction
Vectra
XU
5/90C
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
POTASSIUM 3.5-5.0
BED 1 OFF
POTASSIUM 3.5-5.0
POTASSIUM 3.5-5.0
POTASSIUM 3.5-5.0
BED 1 OFF
POTASSIUM 3.5-5.0
BED 1 OFF BED 1 OFF
BED 1 OFFBED 1 OFFBED 1 OFF
Critical Care Unit HIS/CIS
Vectra
XU
5/90C
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
BED 1 OFF
POTASSIUM 3.5-5.0
BED 1 OFF
POTASSIUM 3.5-5.0
POTASSIUM 3. 5-5.0
POTASSIUM 3.5-5.0
BED 1 OFF
POTASSIUM 3.5-5.0
BED 1 OFF BED 1 OFF
BED 1 OFFBED 1 OFFBED 1 OFF
Clinical Data Repository
A/D/T System
Order Filling Application
Accept AckAccept Ack
Accept + App ACKAccept + App ACK
Receiver Responsibility MSH-15,16
No ACKNo ACK
21
Message Profile Summary
• Well-defined process for developing Message Profiles.
• A Message Profile is a pre-negotiated agreement:– Static (data contents)– Dynamic (application interaction)
• Registered by a unique identifier.
22
Message Profiles are used for…
• Describing the content of inbound and outbound interfaces– Conformance statement
• Certifying conformance• Validating messages• Simplifying interoperability
– Not plug-and-play but… close
23
Patient Management
Admission Transfer Discharge
Sender
Receivers
RadiologySystem
OncologySystem
HISSystem
{1 1 3 .. 3 1} {1 1 3 .. 5 1} {1 1 3 .. 7 1}
Application Use Case
Message Profile
Sample Application Use Case
24
Message Profiles are HL7 Conformant
• A message profile which meets the HL7 standard requirements: all the required segments and fields are specified and all fields are using the appropriated HL7 data types as specified in the Chapter 2 of the HL7 standard
• Only conformant profiles will be registered
25
HL7 Message Profile Identification
• A unique identifier is assigned to a message profile submitted by a vendor or a healthcare provider
• Assigned when the profile is registered with HL7 (Registration tool)
• ASN.1 Generated by the message profile registration tool (HL7 provided to members)
• Unique – OID – ASN.1(American Symbolic Notation) Object Identifier
• Conformance SIG
26
OID…OID root for Registered Conformance Profiles is: OID root for Registered Conformance Profiles is:
2.16.840.1.113883.9. 2.16.840.1.113883.9. • 2 ISO• 16• 840• 113883 HL7• 9 Profile • Samples:
2.16.840.1.113883.9.12.16.840.1.113883.9.22.16.840.1.113883.9.32.16.840.1.113883.9.4 …
27
Purpose of OID• Unique identifier• Registration
– For cataloging message profiles registered by HL7
• Used to specify the conformance statement of an application– References to OIDs
28
Conformance Statement• A document describing the HL7
interoperability characteristics as a use case model (UML) of an application and the message profiles implemented by that application.
• Describes overall interoperability requirements along with the message profiles.
• Basis for compliance certification
29
{1 1 3 .. 3 0}
Oncology SystemConformance Statement
Use Case Model
Radiology System Conformance Statement
Use Case Model
{1 1 3 .. 3 1}
Message Profile Registry
{1 1 3 .. 7 2}
{1 1 3 .. 4 1}
{1 1 3 .. 5 1}
{1 1 3 .. 6 1}
{1 1 3 .. 7 1}
{1 1 3 .. 8 1}
ASN.1 identifiers
Reference to…
Application Conformance Statement
30
Compatibility
• Relationship between an outbound and an inbound message profile such that, despite differences, they can interoperate
• Outbound message profile will be richer in content than an inbound profile.
31
Hospital Registration System (producer)
Radiology system (receiver)
Nursing System(receiver)
Oncology system (receiver)
ADT Message Profile Compatibility Example
32
Consistency• Characteristic of all message profile
specifications registered with HL7.– XML documents following a pre-defined DTD
• Consistent documentation of message profiles will ensure that vendors and providers will be able to easily integrate applications.
• Encourages reuse, comparison, differences– Simplifies interoperability
33
Application Role
The set of messages (message types) an application can send or received as part of its operation. Applications with similar interoperability needs are expected to use the same application profile. – Part of HL7 Version 3
34
Registration
A conformant message profile document will be registered with HL7 and be granted a unique message profile identifier.
35
Certification
• The process by which an application’s conformance claim in verified against the actual application implementation. Certification is a very important part of conformance
• Conducted by providers, national or regional health organizations– Not conducted by HL7
36
Verification
The process by which a message instance (one message) is verified against the message profile on which it is based.
37
<XML>Considerations </XML> • XML Message
– It represents an XML document and it contains data and meta-data (tags) as described by its schema/DTD.
• XML DTD/Schema – Contains the rules (structure, content, data types,
cardinality) for constructing and validating an XML document.
• Message = document • Version 2.XML specification from XML Sig
(informative -> normative)
38
Conformance Benefits• Consistent documentation• Reuse of specification
– Convergence on use cases• Lower cost of integration
– Tool for comparing specifications• Similar to Version 3
– Conformance SIG is developing Implementation guide
• Chaos -> order
39
Conformance Support in the HL7 Standard
• Version 2.4, 2.5– MSH:21 – Profile identifier– OID data type for
ASN.1 identifiers– Conformance
Chapter– Implementation
Guide
• Version 3– At the core of the
Message Development Process
– Chapter 8 of MDF– Implementation
Guide
40
Overview of HL7 2.x Conformance
• Conformance Concepts
• Use case derived message profiles
• Sample Conformance documentation
41
Use Case Analysis• UML
– Language for describing requirements• Use Case Analysis• Use Case Models• Conceptual Interoperability Model
– Expressed in the user’s terms• Information Model
42
Use Case derived Message Profiles
• Specification for Message Profile Content – See the HL7 web site
• Use cases, static profile, dynamic specification, profile identifiers
• Allows clinical site and application vendors to specify their standard conformance
• XML DTD/schemas for describing profiles – Profiling tool
43
Vendor Message Profiles
• Conformance Statements• Contract between vendor and
customers – It will enable clinical sites to make
better purchasing decisions and clearly evaluate the capabilities of various software products.
• Unambiguous, registered, backed by design and analysis
44
Site Message Profiles • Supports specific needs • Required of third-party application
vendors • RFP• Simplifies introduction/acquisition
of new applications
45
HL7 Registry of Profiles• Search/browse• Unique profile identifiers• Consistent Profile Documentation• DTD/Schema representation of the
profile • Indicates who is using a profile• Version 3 application roles
46
Domain Use Case
Profiled App
Role1
Sends------------------------
Receives------------------------
Role1
Sends------------------------
Receives------------------------
Role1
Sends------------------------
Receives------------------------
Role1
Sends------------------------
Receives------------------------
Sends------------------------
Receives------------------------
Application Profile
Leaf-level Use Cases
Analogous to V2.x Profiling
Static Message Structures
Interaction Model
Use Case Model
Version 3 Deliverables(for a given domain)
HMD
Version 3 Conformance(for a given application)
Actors
47
Overview of HL7 2.x Conformance• Conformance Concepts
• Use case derived message profilesIoana Singureanu
• Sample Conformance documentation
Mary Ann Juurlink
48
The GoalTo enable healthcare organizations to better communicate with their partners by sharing data electronically
To facilitate Healthcare integration efficiently and cost effectively
To use and promote open systems and standards
49
Hospital Registration System
Clinical information system• support messaging (VPN)• no support for secure
communication (Internet)
Remote Lab system
Remote Physician’s Office • cannot send/receive messages
easily
Existing Infrastructure
50
How do we achieve the goal?
By developing profiles for applications
By encouraging vendors to create their own profiles and register them with HL7
By creating a transition path (V2.x -> V3.0) based on conformance profile development
51
Message Profiling Specification
• Use case model• Vocabulary
– Coding– Value sets– Field semantics
• Static Definition of an HL7 v2.x message– Message Level Profile– Segment Level Profile– Field Level Profile
• Dynamic Definition of HL7 v2.x message– Interaction Model
52
Message Description A registration event
(ADT^A04) signals that a patient has arrived or checked in but is not assigned a bed.
Scenario• 40 year old female• Diabetes• Community hospital• Arrives by ambulance
Register a Patient ADT^A04
53
Hospital registration SystemIs responsible for notifying all appropriate systems
Remote Lab System
Receives the messages and sends results
Remote Physicians OfficeReceives the message
Use Case Actors
54
Use Case Model
Care Data Systems
Killdara
IntrinsiqPatient RegistrationADT^A04
+sends message
+receives message
+receives message
FiveSight
+routes message
55
PreconditionsThe patient is ready for clinical attention and demographic information is supplied
Flow of eventsThe patient is registered and the appropriate system is notified
Post ConditionsThe appropriate system has been notified
Use Case Description
56
Dynamic Interaction1. Sequence Diagram
: Care Data Systems
: FiveSight : Killdara : Intrinsiq
RegisterPatientADT^A04( )
RegisterPatientADT^A04( )
RegisterPatientADT^A04( )
2. Receiver responsibilityAcceptNever, Application Never
57
Static Definition ADT^A04 Cardinality Message Description
MSH [1,1] Message HeaderEVN [1,1] Event TypePID [1,1] Patient Demographics[{ NK1 }] [0,+] Next of KinPV1 [1,1] Admit Visit InfoPV2 [1,1] More Admit Visit Info[{ AL1 }] [0,+] Allergy Info
2. Segment Level Profile
PID (1) – Patient Demographics
SEQ DT R/O RP/# ITEM# TBL# ELEMENT NAME1 SI RE 00104 SetID – Patient ID2 CK RE 00105 Patient External ID3 CM R Y 00106 Patient Internal ID4 ST RE Y 00107 Alternate Patient ID5 PN R 00108 Patient Name
6 ST RE 00109 Mother’s Maiden ..7 TS RE 00110 Date Of Birth8 ID RE 00001 00111 Sex9 PN RE Y 00112 Alias10 ID RE 00005 00113 Race 11 AD RE Y/3 00114 Address
Patient Internal ID (00106)Components: <patient ID (NM)> ^ <check digit (NM)> ^ <check digit scheme (ID)> ^ <assigning facility ID (ST)> ^ <type (ID)>
Patient Name (00108)Components: <family name> ^ <given name> ^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^ <prefix (e.g., DR)> ^ <degree (e.g., MD)> Name is standard format described in Chapter 2, HL7 Standard.
1. Message Level Profile
3. Field Level Profile
58
ADT^A04
XML Conformance Profileproduced using the Message Work Bench report XML Spec
<Field Name="Patient ID (Internal ID) " Description="" Optionality="R" Repeatable="Y" Sequence="3" Primitive="T" Datatype="CM" Length="20" QuantLo="1" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Field>
<Field Name="Alternate Patient ID " Description="" Optionality="NS" Repeatable="N" Sequence="4" Primitive="T" Datatype="ST" Length="12" QuantLo="0" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Field>
<Field Name="Patient Name" Description="" Optionality="R" Repeatable="N" Sequence="5" Primitive="F" Datatype="PN" Length="48" QuantLo="1" QuantHi="0"><Component Name="family name" Description="" Optionality="O" Repeatable="N" Sequence="1" Primitive="T" Datatype="ST" Length="0" QuantLo="0" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Component> <Component Name="given name" Description="" Optionality="O" Repeatable="N" Sequence="2" Primitive="T" Datatype="ST" Length="0" QuantLo="0" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Component>
59
HL7 Conformance Profile DTD V2.X
<!-- PID - Patient Identification section --><!ELEMENT PID (PID.3+, PID.5, PID.27* )><!ELEMENT PID.3 (#PCDATA)><!ELEMENT PID.5 (PID.5.1?, PID.5.2?, PID.5.3?, PID.5.4?, PID.5.5?, PID.5.6? )><!ELEMENT PID.5.1 (#PCDATA)><!ELEMENT PID.5.2 (#PCDATA)><!ELEMENT PID.5.3 (#PCDATA)><!ELEMENT PID.5.4 (#PCDATA)><!ELEMENT PID.5.5 (#PCDATA)><!ELEMENT PID.5.6 (#PCDATA)><!ELEMENT PID.27 (#PCDATA)>
•This is the result of associating the dtd with the ADT^A04 Conformance Profile•All profiles registering with HL7 must be validated against this dtd•One dtd per version
60
Admit Patient
Update Patient Information Transfer Patient
Discharge Patient
Register Patient
Hospital Registration System
Cancel Admit
Pre-admit Patient
Clinical Information System
Patient Management
ADTA01_AdmitPatientADTA02_TransferPatient ADTA03_DischargePatient ADTA04_RegisterPatient ADTA05_PreadmitPatient ADTA08_UpdatePatientInfo ADTA11_CancelAdmit
The Most Common ADT HL7 Message Profiles
61
Diagnostic Study Order Cancelled as Requested
Ordering System
Diagnostic Study Order
triggersOrder
Filler System
receivesOrder
Cancel Diagnostic Study Order
Unable to Cancel Diagnostic Study Order
Unable to Accept Diagnostic Study Order
New Diagnostic Study Order
Diagnostic Study Order Accepted
Diagnostic Study Order Cancelled (by Filler)
ORMO01_NewDiagnosticStudyOrder ORRO02_DiagnosticStudyOrderAccepted ORRO02_UnableToAcceptDiagnosticStudyOrder ORRO02_DiagnosticStudyOrderCancelled ORMO01_CancelDiagnosticStudyOrder ORRO02_DiagnosticStudyOrderCancelledAsRequested ORRO02_UnableToCancelDiagnosticStudyOrder
The Most Common Order/ResultHL7 Message Profiles
62Reference Model RepositoryReference Model Repository
RequirementsRequirementsAnalysisAnalysis
Use CaseUse CaseModelModel(UCM)(UCM)
DomainDomainAnalysisAnalysis
Information Information Model &Model &
VocabularyVocabulary(RIM)(RIM)
AnalysisAnalysis DesignDesign
InteractionInteractionDesignDesign
InteractionInteractionModelModel(IM)(IM)
MessageMessageDesignDesign
HierarchicalHierarchicalMessageMessage
DescriptionsDescriptions(HMD)(HMD)
ApplicationApplication
2-nd Order2-nd Order 1 choice of1 choice of 0-n Drug0-n Drug
0-1 Nursing0-1 Nursing
Medical logicMedical logic
VariableVariabledefinition for definition for Arden syntaxArden syntax
(AVD)(AVD)
data:data:location_of_actionlocation_of_action := READ LAST := READ LAST MPSLOC ; MPSLOC ; ‘ ‘ {patient{patient location} location}
DocumentsDocuments
Document Document Types forTypes forHL7 PRAHL7 PRA
(DTD)(DTD)
<!ENTITY %DT_MPSLOC<!ENTITY %DT_MPSLOC“MPSLOC.id,“MPSLOC.id, MPSLOC.name?, MPSLOC.name?, MPSLOC.addr?, MPSLOC.addr?, MPSLOC.phon?, MPSLOC.phon?, MPSLOC.emlAdr?"> MPSLOC.emlAdr?">
MessagingMessaging
Message TypesMessage Typesfor use with for use with
XML, ER7, etcXML, ER7, etc(MET)(MET)
TYPE MPSLOC TYPE MPSLOC CONTAINS {CONTAINS {id[id].TYPE IIDid[id].TYPE IIDnm[name].TYPE STnm[name].TYPE STad[addr].TYPE XADad[addr].TYPE XADph[phon].TYPE XTN ph[phon].TYPE XTN email_addressemail_address [emlAdr].TYPE XTN [emlAdr].TYPE XTN}}
C Code c Codea artb bluec color
HL7 V3 Message Development Lifecycle
63
Deliverables• Some form of the “Technical Committee
Documentation Template”• Domain interaction model• Leaf level interaction model• Common message types (HMD)• So now what do we do with all of this?• How to we apply our specific user
requirement?
64
Starting point for Conformance Profiling
interaction #5,message structure D
Encounter_manager : AR_Encounter_manager
Encounter_tracker : AR_Encounter_tracker
Encounter_archivist : AR_Encounter_archivist
interaction #1,message structure A
interaction #4,Message Structure C
interaction #2,message structure B
interaction #3,message structure C
Trigger Event:Schedule Encounter
Trigger Event:Delete Scheduled Encounter
Trigger Event:Admit Patient
MessageStructures
Hierarchichal Message Descriptionfor Trigger Event "Admit Patient", Sending
Application Role "Encounter Manager"
1 root Patient_encounter 1
status_cd 1 CE
encounter_classification_cd 1 CE
id 1 ST
end_dttm 1 VTS
expected_insurance_plan_qty 1 NM
first_similar_illness_dt 1 VTSpatient_classification_cd 1 CEstart_dttm 1 VTS
1 ENC ENC 1
status_cd 1 26
encounter_classification_cd 2 12
id 3
end_dttm 4
expected_insurance_plan_qty 5
first_similar_illness_dt 6patient_classification_cd 7 13start_dttm 8 4
M 1 M 1
M 1 M 1
M 1 M 1
M 1 M 1
3 R 1 3 R 1
R 1 R 1
R 1 R 1R 1 R 1M 1 M 1
InformationModel Mapping
MessageElements C D
65
Hierarchical Message Definition
Information Model MappingClasses and attributes of the R-MIM, describes a “walk” through.
Message ElementDescribes elements and types, set up as a hierarchy
General constraintsDescribes specific constraints for the message element defined in the row
66
Car
dina
lity
Dom
ain
Spe
cific
atio
n (#
)
Cod
ing
Stre
ngth
(d
efau
lt C
WE
)
Man
dato
ry
Con
stra
int/N
ote
#
Def
ault
Val
ue (
#)D
efau
lt D
efau
lt =
"NI"
Def
ault
Upd
ate
Mod
eD
efau
lt D
efau
lt =
R
Upd
ate
mod
e se
t
Con
form
ance
Car
dina
lity
0..11..1 ORD M0..1 MED R
0..1 <
<unassigned>>0..10..1 R0..* R1
0..1 R
Constraints based on application requirements
67
Message Profiling Specification for Version 3• Use case model• Vocabulary
– Coding– Value sets– Field semantics
• Static Definition of an HL7 V3 message– Message Level Profile– Segment Level Profile– Field Level Profile
• Dynamic Definition of HL7 3 message– Interaction Model – application role
68
Version 3 vs. Version 2.X Analysis, Designi.e
•RIM•Interaction model
Message
Profile
CollectiveExperience
V3V2.X
disambiguate
Common SpecificHMD
Profile
69
Benefits of Message Profiling
Conformance statement• Describes a standard implementation by
coupling events, data elements and messages
• Improves clarity and precision• Profiles may be registered with HL7• Approaches plug and play
Conformance testingMessages can be validated against the message profile
70
ROI Benefits of Hl7 Conformance
Reduces the overhead of integrating applications
•EFFICIENCYAble to meet the needs of the clinicians for access to information, when and where they need it
•QUALITY OF COMMUNICATIONClinical sites can evolve yet maintain their infrastructure
•SAVINGS
71
Conformance Tool Available!
• The Messaging Workbench tool is available free of charge
• It is open source• It is supported within the VA for
the foreseeable future
72
Contacts• We in the Conformance sig are interested
in your feedback and suggestions for improvement of the tool
• The Conformance sig list server is a good source for general information
• For conformance tool information:[email protected]• E-mail:
[email protected]@killdara.com
73
Q&A