Upload
alvis
View
30
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Version 2 Messaging Conformance HL7 Educational Summit Chicago, Illinois. Abdul-Malik Shakir Principal Consultant, Shakir Consulting July 2005. My HL7 Background. Abdul-Malik Shakir Principal Consultant, Shakir Consulting, La Verne, CA HL7 Member since 1991 - PowerPoint PPT Presentation
Citation preview
Version 2 Messaging ConformanceVersion 2 Messaging ConformanceHL7 Educational Summit
Chicago, Illinois
Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting
July 2005
March 2005 V2 Messaging Conformance 2 of 122
My HL7 Background
Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting, La Verne, CA
HL7 Member since 1991
• Three-term Member of the HL7 Board of Directors
• Co-Chair of the Board Education and Implementation Committees
• Member of the Board Architectural Review Board
• Member of the Board Process Improvement Committee
• Co-Chair of the Modeling & Methodology Technical Committee
March 2005 V2 Messaging Conformance 3 of 122
Session Outline
Part I
• Background
HL7: What, and Why
Message Profile: Why and When
• Message Profiles:
What and How
Concepts and Constituents
Levels and Examples
Part II
• Messaging Workbench
What and Why
Features and Use
Reports and Examples
Contacts and Help
• CADHS ELR Project
Project Scope
Message Profiles
March 2005 V2 Messaging Conformance 4 of 122
Health Level SevenWhat and Why
March 2005 V2 Messaging Conformance 5 of 122
An HL7 Messaging Scenario: Why
User InterfaceUser InterfaceProgram
Module
ProgramModuleDataset
Dataset
User InterfaceUser Interface Program
Module
ProgramModule Dataset
Dataset
Message Creation
Message Creation
Message Parsing
Message Parsing
A to BTransformation
A to BTransformation
Message Parsing
Message Parsing
Message Creation
Message Creation
B to ATransformation
B to ATransformation
Order Entry Application
System
Laboratory Application
System
Lab
Ord
er
Tr a
ns a
ctio
nOrder Entry Application
System
Laboratory Application
System
Lab
Res
ult
T
ran
sact
ion
March 2005 V2 Messaging Conformance 6 of 122
Reaching the Limits of Application Interfaces
LabLab
Order EntryOrder Entry ADTADT
PharmacyPharmacy RadiologyRadiology
DecisionSupport
DecisionSupport
ElectronicHealth Record
ElectronicHealth Record
AdministrativeSystems
AdministrativeSystems
?
EnterpriseSystems
EnterpriseSystems
?ExternalSystems
ExternalSystems
?
March 2005 V2 Messaging Conformance 7 of 122
Health Level Seven: Why
• The number of interfaces between N systems is given by the formula (N2-N)/2.
• Linking 2 systems only needs 1 interface, (22 – 2) / 2 = 1;
• Linking 6 systems needs as many as 15 interfaces, (62 – 6) / 2 = 15
• The benefits of using the HL7 standard increase rapidly with the number of systems involved.
March 2005 V2 Messaging Conformance 8 of 122
Abstract Message Specification
MSH Message Header
EVN Event Type
PIDPatient Identification
[PD1] Additional Demographics
[ { NK1 } ] Next of Kin /Associated Parties
PV1 Patient Visit
[ PV2 ] Patient Visit - Additional Info.
…
[ { GT1 } ] Guarantor
[
{ IN1 Insurance
[ IN2 ] Insurance Additional Info.
[ IN3 ] Insurance Add'l Info - Cert.
}
]
…
[ ] optional
{ } may repeat
Segment ID Segment Name
March 2005 V2 Messaging Conformance 9 of 122
MSH Segment Definition
March 2005 V2 Messaging Conformance 10 of 122
MSH Segment Definition
SEQ - position within segment
LEN - length of field
DT - data type for field
OPT - optionality for field
RP/# - repeatability
TBL# - table number for codes
ITEM# - HL7 element number
ELEMENT NAME - name
March 2005 V2 Messaging Conformance 11 of 122
Sample HL7 v2.x Message
Segments
• MSH: Message Header
• PID: Patient Identification
• OBR: Observation Request
• OBX: Observation Result
MSH|^~\&|LABGL1||DMCRES||199812300100||ORU^R01|LABGL1199510221838581|P|2.3|||NE|NE
PID|||6910828^Y^C8||Newman^Alfred^E||19720812|M||W|25 Centscheap Ave^^Whatmeworry^UT^85201^^P||(555)777-6666|(444)677-7777||M||773789090
OBR||110801^LABGL|387209373^DMCRES|18768-2^CELL COUNTS+DIFFERENTIAL TESTS (COMPOSITE)^LN|||199812292128||35^ML|||||||IN2973^Schadow^Gunther^^^^MD^UPIN||||||||||^Once||||||CA20837^Spinosa^John^^^^MD^UPIN
OBX||NM|4544-3^HEMATOCRIT (AUTOMATED)^LN||45||39-49||||F|||199812292128||CA20837
OBX||NM|789-8^ERYTHROCYTES COUNT (AUTOMATED)^LN||4.94|10*12/mm3|4.30-5.90||||F|||199812292128||CA20837
Delimiters
| Field
^ Component
& Subcomponent
~ Repetition
\ Escape Character
March 2005 V2 Messaging Conformance 12 of 122
Message ProfilesWhy and When
March 2005 V2 Messaging Conformance 13 of 122
Revealing assumptions is an essential component of effective communication.
Yes, I doplay
football.
Do youplay
football?
Reveal Assumptions
March 2005 V2 Messaging Conformance 14 of 122
Message Profiles are an effective means of documenting our assumptionsabout message structures
Yes, Iuse HL7.
Do you use
HL7?
Reveal Assumptions
MSHEVNPID [PD1][ { NK1 } ]
MSHEVNPID[ NK1 ]OBX
March 2005 V2 Messaging Conformance 15 of 122
Message Profiles provide a language that allows us to unambiguously express our understanding and assumptions about the information in a
message structure used in a particular scenario
Reduce Ambiguity
MSHEVNPID [PD1][ { NK1 } ]
March 2005 V2 Messaging Conformance 16 of 122
Sharing message profiles provides an opportunity to identify and reconcile conflicts in our understanding
and to validate our assumptions about message structures.
Highlight Conflicts
MSHEVNPID [PD1][ { NK1 } ]
MSHEVNPID[ NK1 ]OBX
March 2005 V2 Messaging Conformance 17 of 122
Consolidate Viewpoints
Message Profile Message Profile Message Profile
MSHEVNPID [PD1][ { NK1 } ]
MSHEVNPID[ NK1 ]OBX
MSHEVN{ PID } [PD1][ { GT1 } ]
MSHEVN{ PID } [PD1][ { NK1 } ][ { GT1 } ][ OBX ]
Canonical Message Profile
March 2005 V2 Messaging Conformance 18 of 122
Value of Message Profiling
• Reveal Assumptions
• Reduce Ambiguity
• Highlight Conflicts
• Consolidate Viewpoints
March 2005 V2 Messaging Conformance 19 of 122
Compliance and Conformance
• Compliance
Messages that adhere to the rules and conventions for constructing of a specific version of a standard are compliant to that version of the standard.
• Conformance
Messages that adhere to the constraints of a precise and unambiguous specification called a message profile are said to be conformant to the profile.
ComplianceCompliance ConformanceConformance
March 2005 V2 Messaging Conformance 20 of 122
Conformance Project Background
• Began in 1997 by the HL7 Conformance SIG
• The SIG, in conjunction with the Andover Working Group (AWG), prepared this specification to:
Define the HL7 Message Profile
Recommend a specification for defining specific message profiles of HL7 messages
Facilitate HL7 interpretation by users familiar with the HL7 standard, reducing interface analysis time and dissatisfaction with the HL7 standard
March 2005 V2 Messaging Conformance 21 of 122
Conformance SIG
• HL7 Conformance has two objectives: Interoperability
• Implementable message profiles
Certification• Conformance Statement
• Normative Documentation Chapter 2
Message Profile Schema/DTD
• Tutorial - education
• You are invited to participate! Bi-weekly calls
List server
March 2005 V2 Messaging Conformance 22 of 122
Message ProfilesWhat and How
March 2005 V2 Messaging Conformance 23 of 122
Message Profile Defined
• Unambiguous specification of a standard HL7 message for use within a particular set of requirements
Prescribes a set of precise constraints upon one or more standard messages
Supported by use case analysis and interaction modeling
• Measurable
What data will be passed in a message
The format in which the data will be passed
The acknowledgement responsibilities of the sender and receiver
March 2005 V2 Messaging Conformance 24 of 122
Message Profile Defined (continued)
• Based on HL7, although may further constrain Static structure and content of each message
The dynamic interactions
• Parts of a valid message profile Use Case Model
Static Definition
Dynamic Definition
• Represented as an XML document Can be registered with HL7
May be reused by other HL7 users
May be used for documentation
March 2005 V2 Messaging Conformance 25 of 122
Conceptual Overview
Message Profile = Static Profile + Dynamic Profile
Critical Care Unit
ADT System
Initiating MessageResponse Message
Initiating Message
Clinical Data Repository
March 2005 V2 Messaging Conformance 26 of 122
Use Case Model
• Documents the scope and requirements for an HL7 Message Profile or set of Message Profiles
May include a use case diagram or detailed text
Provides a name that clearly and concisely defines the exchange
Defines the actors, including the sending and receiving applications
Defines the responsibilities of these actors
Documents the situations in which the exchange of a particular HL7 Message Profile is required
Documents the purpose
• V3.0 Message Development Framework (MDF 99)
March 2005 V2 Messaging Conformance 27 of 122
Static Definition
• A specification for a message structure intended to support the use case
• Based on a message defined in HL7 Std
• Defined at the message, segment, and field levels
Follows the HL7 rules (chapter 2)
May further constrain
• Identifies only those specific elements used in the exchange
• Removes all instances of optionality, defining explicitly
• Segments, segment groups, fields and components usage rules
• Cardinalities
• Value sets and coding systems
• Implementation notes
March 2005 V2 Messaging Conformance 28 of 122
Static Definition Example
...
...
...
NK1
MSH
EVN
PID
NK1 NK1 NK1 NK1
PV1
PV2
OBX
AL1
HL7 Message Structure
...
NK1
MSH
EVN
PID
NK1 NK1 NK1 NK1
PV1
PV2
OBX
AL1
Message Profile
Segments/Segment Groups:•Usage (Optionality) •Cardinality (min, max)
Fields/Components: - Usage (Optionality) - Cardinality (min, max) - Value Sets/Coding system - Descriptions
March 2005 V2 Messaging Conformance 29 of 122
Dynamic Definition
• Defines interaction between the sender and receiver Acknowledgment mode supported
Conditions under which an accept and/or application level acknowledgment is expected
• Always
• Never
• Only on success
• Only on error
• Interaction Model Defines specific interactions between the applications that support message
profile communication requirements
Includes interaction diagrams that illustrate the sequence of trigger event and resulting message flows between the sending and receiving applications
• Dynamic can refer one to many static definitions
March 2005 V2 Messaging Conformance 30 of 122
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 OFF
BED 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 OFF
BED 1 OFFBED 1 OFF
Clinical Data Repository
A/D/T System
Order Filling Application
Accept AckAccept Ack
Accept + App ACKAccept + App ACK
Receiver ResponsibilityMSH-15,16
No ACKNo ACK
March 2005 V2 Messaging Conformance 31 of 122
How it all ties together
Static Definition – Field Level
Vocabulary
SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAME
1 4 SI X 00104 Set ID - PID
2 20 CX RE [1..1] 00105 Patient ID
3 20 CX R [1..*] 00106 Patient Identifier List
4 20 CX X 00107 Alternate Patient ID - PID
5 48 XPN R [1..*] 00108 Patient Name
6 48 XPN RE [1..*] 00109 Mother’s Maiden Name
7 26 TS RE 00110 Date/Time of Birth
8 1 IS RE 0001 00111 Sex
9 48 XPN X 00112 Patient Alias
10 80 CE X 0005 00113 Race
11 106 XAD RE [1..3] 00114 Patient Address
12 4 IS X 0289 00115 County Code
13 40 XTN RE [1..3] 00116 Phone Number - Home
14 40 XTN RE [1..3] 00117 Phone Number - Business
15 60 CE X 0296 00118 Primary Language
16 80 CE X 0002 00119 Marital Status
17 80 CE X 0006 00120 Religion
18 20 CX X 00121 Patient Account Number
19 16 ST RE 00122 SSN Number - Patient
20 25 DLN X 00123 Driver's License Number - Patient
21 20 CX X 00124 Mother's Identifier
22 80 CE X 0189 00125 Ethnic Group
23 60 ST RE 00126 Birth Place
24 1 ID X 0136 00127 Multiple Birth Indicator
25 2 NM X 00128 Birth Order
26 80 CE X 0171 00129 Citizenship
27 60 CE X 0172 00130 Veterans Military Status
28 80 CE X 0212 00739 Nationality
29 26 TS X 00740 Patient Death Date and Time
30 1 ID X 0136 00741 Patient Death Indicator
: A DT S y s tem : A DT Notifi c ation Rec ip ient
A DT^A 01
A CK ^A 01
Interaction Model
Segment ADT Message Usage Cardinality Chapter
MSH Message Header R [1..1] 2
EVN Event Type R [1..1] 3 PID Patient Identification R [1..1] 3 [ PD1 ] Additional Demographics X [0..0] 3 [{ ROL }] Role X [0..0] 12 [{ NK1 }] Next of Kin / Associated
Parties RE [0..3] 3
PV1 Patient Visit R [1..1] 3 [ PV2 ] Patient Visit - Additional
Info. RE [0..1] 3
[{ ROL }] Role X [0..0] 12 [{ DB1 }] Disability Information X [0..0] 3 [{ OBX }] Observation/Result X [0..0] 7 [{ AL1 }] Allergy Information RE [0..*] 3 [{ DG1 }] Diagnosis Information X [0..0] 6 [ DRG ] Diagnosis Related Group X [0..0] 6 [{ X [0..0] PR1 Procedures X [0..0] 6 [{ ROL }]
Role X [0..0] 12
}] [{ GT1 }] Guarantor X [0..0] 6 [{ X [0..0] IN1 Insurance X [0..0] 6 [ IN2 ] Insurance Additional Info. X [0..0] 6 [{ IN3 }]
Insurance Additional Info - Cert.
X [0..0] 6
[{ ROL }]
Role X [0..0] 12
}] [ ACC ] Accident Information X [0..0] 6 [ UB1 ] Universal Bill Information X [0..0] 6 [ UB2 ] Universal Bill 92 Information X [0..0] 6 [ PDA ] Patient Death and Autopsy X [0..0] 3
Dynamic Definition
Static Definition – Segment Level
P at ie n t
P hy s ic ian
A D T N o t ific a t ion R e c ip ien t
A D T S y s tem
A dm it / V is it N ot ific a t ion
is s u b jec t o fau tho riz es
rec e ives no t if ic a t ions en ds no t if ic a t ion
R eg is t ra rt rig gers
Use Case Model
Static Definition – Message Level
1 Use Case Model
1.1 Use Case: Admit/Visit Notification
2. Dynamic Interaction Model
3 Dynamic Definition: ADT/ACK (Event A01)
3.1 ADT^A013.2 ACK^A01
4 Static Definition: - Message Level -ADT/ACK (event A01)
4.1 ADT^A014.2 ACK^A01
5 Static Defintiion - Segment Level
5.1 MSH – Message Header Segment Definition5.2 EVN - Event Type Segment Definition5.3 PID (Y) - Patient Demographics Segment Definition5.4 PD1 – Patient Additional Demographic Segment Definition5.5 NK1 - Next of kin Segment Definition5.6 PV1 (2) - Admit Visit Info Segment Definition5.7 AL1 - Allergy Segment Definition5.8 MSA - Message Acknowledgment Segment Definition5.9 ERR - Error Segment Definition
6 Static Definition - Field Level
6.1 Table 0001 – Sex6.2 Table 0002 – Marital Status6.3 Table 0003 – Event Type Code6.4 Table 0004 – Patient Class6.5 Table 0005 – Race6.6 Table 0006 – Religion6.7 Table 0007 – Admission Type6.8 Table 0008 – Acknowledgement Code6.9 Table 0009 – Ambulatory Status
March 2005 V2 Messaging Conformance 32 of 122
Message ProfilesConcepts and Constituents
March 2005 V2 Messaging Conformance 33 of 122
Profiling Concepts• Profile Types
HL7 Standard Constrainable Implementable Future type to allow for expected receiver behavior
• Generic term ‘element’ used Segment groups Segments Fields Components Sub-components
• Cardinality• Usage
Message Constituents
March 2005 V2 Messaging Conformance 34 of 122
Profile Types
• HL7 Standard Profile
represents a specific HL7 published standard
creation and publication limited to HL7 use
• Constrainable
May have optionality - not implementable
Narrower profiles may be defined based on this
Realm Specific (National, Regional, SIGs, etc.)
Supplier / Consumer Specific
• Implementation
Further constrained
No optionality
March 2005 V2 Messaging Conformance 35 of 122
Cardinality
• Identifies minimum and maximum number of repetitions
• Special values for cardinality
Minimum number of repetitions is 0, the element may be omitted from a message
The maximum value may have no practical limit (In this case, it may be identified as ‘*’)
March 2005 V2 Messaging Conformance 36 of 122
Cardinality Examples
Examples of common cardinality combinations are:Element Cardinality
Value Description
[0..0] Element never present
[0..1] Element may be omitted and it can have at most one Occurrence
[1..1] Element must have exactly one Occurrence
[0..n] Element may be omitted or may repeat up to n times
[1..n] Element must appear at least once, and may repeat up to n times
[0..*] Element may be omitted or repeat for an unlimited number of times
[1..*] Element must appear at least once, and may repeat unlimited number of times
[m..n] Element must appear at least “m” and at most” n” times
March 2005 V2 Messaging Conformance 37 of 122
Usage
• The circumstances under which an element appears in a message
Some elements must always be present
others may never be present
others may only be present in certain circumstances
• Rules governing the expected behavior of the sending and limited restrictions on the receiving application with respect to the element
March 2005 V2 Messaging Conformance 38 of 122
Usage (continued)
• R - Required
A conforming sending application
• populate all “R” elements with a non-empty value
A conforming receiving application
• process (save/print/archive/etc.) or ignore the information conveyed by required elements
• must not raise an error due to the presence of a required element, but may raise an error due to the absence of a required element
For complete compatibility with HL7, any element designated as required in a standard HL7 message definition shall also be required in all HL7 Message Profiles of that standard message
March 2005 V2 Messaging Conformance 39 of 122
Usage (continued)
• RE - Required but may be empty May be missing from the message, but must be sent by the
sending application if there is relevant data
A conforming sending application
• must be capable of providing all “RE” element
• if it knows the required values for the element, then it must send that element
• if the conforming sending application does not know the required values, then element will be omitted
A conforming receiving applications
• will be expected to process (save/print/archive/etc.) or ignore data contained in the element
• must be able to successfully process the message if the element is omitted (I.e. no error message should be generated because the element is missing
March 2005 V2 Messaging Conformance 40 of 122
Usage (continued)
• Optional
This code indicates that the Usage for this element has not yet been defined
May NOT be used in ‘Implemention’ profiles (no-optionality profiles)
Conformance cannot be tested on an Optional field
March 2005 V2 Messaging Conformance 41 of 122
Usage (continued)
• C - Conditional Predicate associated with this element that identifies the
conditions under which the element must be present• must be testable and based on other values within the message
• may be expressed as a mathematical expression or in text and may utilize operators such as equivalence, logical AND, logical OR and NOT
• The conforming sending and receiving applications shall both evaluate the predicate
If the predicate is satisfied:• See rules for R (Required)
If the predicate is NOT satisfied:• A conformant sending application must NOT send the element
• A conformant receiving application must NOT raise an error if the condition predicate is false and the element is not present, though it MAY raise an error if the element IS present
March 2005 V2 Messaging Conformance 42 of 122
Usage (continued)
• CE - Conditional but may be empty This usage also has an associated condition predicate similar to
Conditional (C)
If the predicate is satisfied:
• See rules for RE (Required but may be empty)
If the predicate is not satisfied:
• The conformant sending application must NOT send the element
• The conformant receiving application MAY raise an application error if the element IS present
• X - Not supported Conformant sending applications will NOT send the element
Conformant receiving applications MAY ignore the element if it IS present, or may raise an application error
March 2005 V2 Messaging Conformance 43 of 122
Optionality / Usage Relationship
• Conformance Usage codes are more specific than HL7 Optionality codes
HL7 Optionality Allowed Conformance Usage Comment
R - Required R
O - Optional R, RE, O*, C, CE, X O is only permitted for constrainable profiles
C - Conditional C, CE, R**, RE** ** If satisfied by use case
X – Not Supported X
B – Backward Compatibility
R, RE, O*, C, CE, X O is only permitted for constrainable profiles
W – Withdrawn X
March 2005 V2 Messaging Conformance 44 of 122
Usage / Cardinality Relationship
• Both Usage and Cardinality govern the appearance of a field in a message
• Cardinality constrained by the usage code
If Required (R), the minimum and maximum cardinality for the element shall always be >= 1
If the usage of an element is not Required (R) (i.e. any code other than ‘R’), the minimum cardinality shall be 0 except in the following condition:
• where an element will not always be present but, when present, must have a minimum number of repetitions greater than one, this may be indicated by specifying
– the non-required Usage code
– the minimum cardinality representing the minimum number of repetitions when the element is present.
March 2005 V2 Messaging Conformance 45 of 122
Usage-Cardinality Combinations
Cardinality Usage Interpretation
[1..1] R There will always be exactly 1 repetition present
[1..5] R There will be between 1 and 5 repetitions present
[0..1] R Illegal: Minimum and maximum cardinality must always be at least 1 for ‘Required’ elements
[0..1] RE The element must be supported, but may not always be present
[0..5] C If the condition predicate is true, there will be between 1 and 5 repetitions. If the predicate is false, there will be 0 repetitions
[3..5] RE If any values for the element are sent, there must be at least 3 and no more than 5 repetitions. However, the element may be absent (0 repetitions)
[0..1] CE Under certain circumstances, the element must be supported, but may not always be present
[0..0] X Not supported
March 2005 V2 Messaging Conformance 46 of 122
Usage Within Hierarchical Elements
• Messages are constructed using a hierarchy of elements
• At least one lower level element must be present for the higher level element to be considered to be present
• Adds an implicit conditional constraint on elements that enforce the presence of an element
• Places constraints on what combinations of usage codes may be used within a hierarchy
March 2005 V2 Messaging Conformance 47 of 122
Message ProfilesLevels and Examples
March 2005 V2 Messaging Conformance 48 of 122
Message Level Profile
• Segment Definitions
The set of segments and segment groups included within the message of an HL7 Message Profile shall be defined
Any segments or segment groups that are required by HL7 shall be included
• Segment Usage
• Segment Cardinality
• Profile does not allow for “empty” segment
• HL7 abstract message syntax PLUS
Usage
Cardinality
March 2005 V2 Messaging Conformance 49 of 122
Message Level Profile Example
ADT^A01^ADT_A01 ADT Message Usage Cardinality Chapter
MSH Message Header R [1..1] 2 EVN Event Type R [1..1] 3 PID Patient Identification R [1..1] 3 [ PD1 ] Additional Demographics X [0..0] 3 [{ ROL }] Role X [0..0] 12 [{ NK1 }] Next of Kin / Associated
Parties RE [0..3] 3
PV1 Patient Visit R [1..1] 3 [ PV2 ] Patient Visit - Additional
Info. RE [0..1] 3
[{ ROL }] Role X [0..0] 12 [{ DB1 }] Disability Information X [0..0] 3 [{ OBX }] Observation/Result X [0..0] 7 [{ AL1 }] Allergy Information RE [0..*] 3 [{ DG1 }] Diagnosis Information X [0..0] 6 [ DRG ] Diagnosis Related Group X [0..0] 6 [{ X [0..0] PR1 Procedures X [0..0] 6 [{ ROL }] Role X [0..0] 12 }] [{ GT1 }] Guarantor X [0..0] 6 [{ X [0..0] IN1 Insurance X [0..0] 6 [ IN2 ] Insurance Additional Info. X [0..0] 6 [{ IN3 }] Insurance Additional Info -
Cert. X [0..0] 6
[{ ROL }] Role X [0..0] 12 }] [ ACC ] Accident Information X [0..0] 6 [ UB1 ] Universal Bill Information X [0..0] 6 [ UB2 ] Universal Bill 92 Information X [0..0] 6 [ PDA ] Patient Death and Autopsy X [0..0] 3
ADT^A01^ADT_A01 ADT Message Usage Cardinality Chapter
MSH Message Header R [1..1] 2 EVN Event Type R [1..1] 3 PID Patient Identification R [1..1] 3 [{ NK1 }] Next of Kin / Associated
Parties RE [0..3] 3
PV1 Patient Visit R [1..1] 3 [ PV2 ] Patient Visit - Additional
Info. RE [0..1] 3
[{ AL1 }] Allergy Information RE [0..*] 3
March 2005 V2 Messaging Conformance 51 of 122
Segment Level Profile
• The set of fields of each instance of a segment within the Message Profile
• If a segment occurs multiple times, it may be represented by different segment profiles
• Field Usage
• Field Cardinality
• Null
• Syntax (tabular HL7 segment definitions)
Length (updated)
Usage (new column)
Cardinality (new column)
March 2005 V2 Messaging Conformance 52 of 122
SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAME
1 4 SI X 00104 Set ID - PID
2 20 CX RE [0..1] 00105 Patient ID
3 20 CX R [1..*] 00106 Patient Identifier List
4 20 CX X 00107 Alternate Patient ID - PID
5 48 XPN R [1..*] 00108 Patient Name
6 48 XPN RE [0..*] 00109 Mother’s Maiden Name
7 26 TS RE [0..*] 00110 Date/Time of Birth
8 1 IS RE [0..*] 0001 00111 Sex
9 48 XPN X 00112 Patient Alias
10 80 CE X 0005 00113 Race
11 106 XAD RE [0..3] 00114 Patient Address
12 4 IS X 0289 00115 County Code
13 40 XTN RE [0..3] 00116 Phone Number - Home
14 40 XTN RE [0..3] 00117 Phone Number - Business
15 60 CE X 0296 00118 Primary Language
16 80 CE X 0002 00119 Marital Status
17 80 CE X 0006 00120 Religion
18 20 CX X 00121 Patient Account Number
19 16 ST RE [0..1] 00122 SSN Number - Patient
20 25 DLN X 00123 Driver's License Number - Patient
21 20 CX X 00124 Mother's Identifier
22 80 CE X 0189 00125 Ethnic Group
23 60 ST RE [0..1] 00126 Birth Place
24 1 ID X 0136 00127 Multiple Birth Indicator
25 2 NM X 00128 Birth Order
26 80 CE X 0171 00129 Citizenship
27 60 CE X 0172 00130 Veterans Military Status
28 80 CE X 0212 00739 Nationality
29 26 TS X 00740 Patient Death Date and Time
30 1 ID X 0136 00741 Patient Death Indicator
SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME
1 4 SI O 00104 Set ID - PID
2 20 CX B 00105 Patient ID
3 250 CX R Y 00106 Patient Identifier List
4 20 CX B Y 00107 Alternate Patient ID - PID
5 250 XPN R Y 00108 Patient Name
6 250 XPN O Y 00109 Mother’s Maiden Name
7 26 TS O Y 00110 Date/Time of Birth
8 1 IS O Y 0001 00111 Sex
9 250 XPN B 00112 Patient Alias
10 250 CE O 0005 00113 Race
11 250 XAD O Y 00114 Patient Address
12 4 IS B 0289 00115 County Code
13 250 XTN O Y 00116 Phone Number - Home
14 250 XTN O Y 00117 Phone Number - Business
15 250 CE O 0296 00118 Primary Language
16 250 CE O 0002 00119 Marital Status
17 250 CE O 0006 00120 Religion
18 250 CX O 00121 Patient Account Number
19 16 ST B 00122 SSN Number - Patient
20 25 DLN B 00123 Driver's License Number - Patient
21 250 CX O Y 00124 Mother's Identifier
22 250 CE O Y 0189 00125 Ethnic Group
23 250 ST O 00126 Birth Place
24 1 ID O 0136 00127 Multiple Birth Indicator
25 2 NM O 00128 Birth Order
26 250 CE O Y 0171 00129 Citizenship
27 250 CE O 0172 00130 Veterans Military Status
28 250 CE B 0212 00739 Nationality
29 26 TS O 00740 Patient Death Date and Time
30 1 ID O 0136 00741 Patient Death Indicator
Segment Level Profile Example (PID)
March 2005 V2 Messaging Conformance 53 of 122
Field Level Profile
• Field definitions Each individual field is completely defined to eliminate any
possible ambiguity
If HL7 2.x field descriptions are not sufficient, a precise semantic definition shall be specified
• Exact allowed value set shall be specified Coded Values (ID and IS)
• HL7 tables (ID) may be extended
• User defined (IS) may be redefined and/or extended
Coded Entry (CE, CF, CWE, and CNE)
• Composite Data (CM) types • Appendix for 2.3.1 and 2.4 for XML encoding
• Deprecated and all CM fields are using new data types as of 2.5
March 2005 V2 Messaging Conformance 55 of 122
Profile Registration Tool
• Message Profile registration utility on the HL7 Members’ Page of the HL7 WWW (www.hl7.org/memonly/conformance)
• Valid Conformance Documents (XML)
• Message Profile Identifier generated
• Repository of Message Profile
• Catalogue of Message Profile Users (future) application name and version
contact person
application role (whether the application sends or receives messages described by the profile)
• Search Capabilities
March 2005 V2 Messaging Conformance 56 of 122
Message Profile Identifier
• Uniquely identifies static and dynamic profile
• The static profile identifier is a means to uniquely identify a message profile, expressed as an ASN.1 Object Identifier (OID)
The sending application uses the profile identifiers to determine the specific HL7 Message Profile to send
Branch from ISO to HL7 and Message Profile
• 2.16.840.1.113883.9
March 2005 V2 Messaging Conformance 59 of 122
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
March 2005 V2 Messaging Conformance 60 of 122
Verification (Validation)
• The process by which message instance(s) are verified against the message profile on which it is based
• Verification is a very important part of conformance
• Conducted by providers, national or regional health organizations
Not conducted by HL7
March 2005 V2 Messaging Conformance 61 of 122
Australian Healthcare Messaging Laboratory(http://www.ahml.com.au)
March 2005 V2 Messaging Conformance 62 of 122
<XML>Considerations </XML>
• Message profile is independent of message instance encoding - ER7/XML
• XML Message Instance• 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
• Version 2.xml specification from XML SIG (informative -> normative)
March 2005 V2 Messaging Conformance 63 of 122
Conformance Benefits
• Consistent Documentation
• Reuse of Specification
• Lower Cost of Integration
• Similar to Version 3 Conformance SIG is developing Implementation guide
• Chaos -> order
• Site Specific Profiles Supports specific needs
Required of third-party application vendors
RFP
Simplifies introduction/acquisition of new applications
March 2005 V2 Messaging Conformance 64 of 122
Conformance Support in the HL7 Standard
• Version 2.4, 2.5, 2.6
MSH:21
Profile identifier
OID data type for ASN.1 identifiers
Conformance Section
Implementation Guide
• Version 3
At the core of the Message Development Process
Chapter 7 of HDF
Implementation Guide
March 2005 V2 Messaging Conformance 65 of 122
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
V3 Conformance
March 2005 V2 Messaging Conformance 66 of 122
Break
March 2005 V2 Messaging Conformance 67 of 122
Messaging WorkbenchWhat and Why
March 2005 V2 Messaging Conformance 68 of 122
The Messaging Workbench (MWB)
• For those who: Design HL7 2.x messages
Manage specification repositories
Collaborate on varied messaging projects within and outside of their organizations
• Free of charge from HL7 Web site (www.hl7.org) HL7 -> SIG -> Conformance -> Documents
• Encouraged by the Conformance SIG
• Open Source Project Call for participation
• It will continue to be supported within the VA for the foreseeable future
March 2005 V2 Messaging Conformance 69 of 122
Design Features - 1
• Rapid prototyping of message profiles derived from standard libraries, from profile inheritance or from scratch
• Quick and easy alteration of existing profiles to meet new requirements
• Design time comparison of profiles on an element by element basis
• Linkage of data elements or constants to message elements for a more complete specification
March 2005 V2 Messaging Conformance 70 of 122
Design Features - 2
• Tools for storage and retrieval of profiles as well as updating and customizing message element libraries
• The ability to capture and analyze ER7 messages
• Capability to reverse engineer specifications from captured messages.
• A suite of reports that document specifications and produce example messages in text, xml and html formats
• Additional style sheets available for PDF
March 2005 V2 Messaging Conformance 71 of 122
HL7
March 2005 V2 Messaging Conformance 72 of 122
Constrainable
March 2005 V2 Messaging Conformance 73 of 122
Constrainable (continued)
March 2005 V2 Messaging Conformance 74 of 122
Implementation
March 2005 V2 Messaging Conformance 75 of 122
Message Profile
March 2005 V2 Messaging Conformance 76 of 122
Messaging WorkbenchFeatures and Use
March 2005 V2 Messaging Conformance 77 of 122
Capture/Analyze Message
March 2005 V2 Messaging Conformance 78 of 122
Reverse Engineer from Message
March 2005 V2 Messaging Conformance 79 of 122
New Profile Using Libraries
March 2005 V2 Messaging Conformance 80 of 122
New Profile Using Libraries (cont’d)
March 2005 V2 Messaging Conformance 81 of 122
New Profile Using Libraries (cont’d)
March 2005 V2 Messaging Conformance 82 of 122
New Profile Using Libraries (cont’d)
March 2005 V2 Messaging Conformance 83 of 122
New Profile Using Libraries (cont’d)
March 2005 V2 Messaging Conformance 84 of 122
New Profile using copy/paste
March 2005 V2 Messaging Conformance 85 of 122
New Profile Copy/Paste (cont’d)
March 2005 V2 Messaging Conformance 86 of 122
New Profile Copy/Paste (cont’d)
March 2005 V2 Messaging Conformance 87 of 122
Modifying a Profile – HL7
March 2005 V2 Messaging Conformance 88 of 122
Modifying a Profile – Constrainable
March 2005 V2 Messaging Conformance 89 of 122
Modifying Profile – Constr (cont’d)
March 2005 V2 Messaging Conformance 90 of 122
Modifying Profile – Implementation
March 2005 V2 Messaging Conformance 91 of 122
Modifying Profile – Impl (cont’d)
March 2005 V2 Messaging Conformance 92 of 122
Diagram Drawing Tool
March 2005 V2 Messaging Conformance 93 of 122
Messaging WorkbenchReports and Examples
March 2005 V2 Messaging Conformance 94 of 122
Reports
March 2005 V2 Messaging Conformance 95 of 122
Reports (continued)
March 2005 V2 Messaging Conformance 96 of 122
Reports (continued)
March 2005 V2 Messaging Conformance 97 of 122
Reports (continued)
March 2005 V2 Messaging Conformance 98 of 122
Reports (continued)
March 2005 V2 Messaging Conformance 99 of 122
Reports (continued)
March 2005 V2 Messaging Conformance 100 of 122
Producing Profile Reports
March 2005 V2 Messaging Conformance 101 of 122
Producing Profile Reports (cont’d)
March 2005 V2 Messaging Conformance 102 of 122
Producing Profile Reports (cont’d)
March 2005 V2 Messaging Conformance 103 of 122
Producing Profile Reports (cont’d)
Browser View
March 2005 V2 Messaging Conformance 104 of 122
Producing Profile Reports (cont’d)
March 2005 V2 Messaging Conformance 105 of 122
HL7 Message Profile
March 2005 V2 Messaging Conformance 106 of 122
Register Profile with HL7
March 2005 V2 Messaging Conformance 107 of 122
Messaging WorkbenchContacts and Help
March 2005 V2 Messaging Conformance 108 of 122
MWB Contacts
• The Conformance SIG is interested in your feedback and suggestions for improvement of the tool
• Conformance SIG list server is a good source for general information about the tool and for making improvement suggestions
• For specific questions you may also contact Pete Rontey via Email at [email protected]
March 2005 V2 Messaging Conformance 109 of 122
Where to Get More Information
• MWB On-line help
March 2005 V2 Messaging Conformance 110 of 122
Where to Get More Info (cont’d)
• MWB On-line help (cont’d)
March 2005 V2 Messaging Conformance 111 of 122
Where to Get More Info (cont’)
• MWB Updates/Downloads
March 2005 V2 Messaging Conformance 112 of 122
Where to Get More Info (cont’d)
• Conformance Tools Forum at Yahoo Groups
California Department of Health ServicesElectronic Laboratory Reporting Project
March 2005 V2 Messaging Conformance 114 of 122
California Electronic Laboratory Reporting System
Lab MessageSupplier
InboundLaboratoryMessage
InboundMessage Profile
Transform
Translate
InboundMessage Mapping
CanonicalLaboratoryMessage
CanonicalMessage Profile
Transform
Translate
OutboundMessage Mapping
OutboundLaboratoryMessage
Lab MessageConsumer
KnowledgeManagement
Service
KnowledgeManagement
Service
Object GraphGeneration
LaboratoryMessageObjects
ObjectRelationalMapping
LaboratoryMessage
Respository
Object RelationalMap
ELR DatabaseDesign Model
CA Public HealthLogical Data
Model
HL7 RIM &CDC PHLDM
CanonicalMessage Profile
LaboratoryMessage Object
Model
Extract,Transform,and Load
LaboratoryDatamart
BusinessIntelligenceApplication
BusinessIntelligenceApplication
BusinessIntelligenceApplication
OutboundMessage Profile
Extract,Transform,and Load
Additional DataSources
March 2005 V2 Messaging Conformance 115 of 122
Inbound Message Processing Outbound Message Processing
Data PersistenceBusiness Intelligence
Functional Areas of the CA-ELR System
Lab MessageSupplier
InboundLaboratoryMessage
InboundMessage Profile
Transform
Translate
InboundMessage Mapping
CanonicalLaboratoryMessage
CanonicalMessage Profile
Transform
Translate
OutboundMessage Mapping
OutboundLaboratoryMessage
Lab MessageConsumer
KnowledgeManagement
Service
KnowledgeManagement
Service
Object GraphGeneration
LaboratoryMessageObjects
ObjectRelationalMapping
LaboratoryMessage
Respository
Object RelationalMap
ELR DatabaseDesign Model
CA Public HealthLogical Data
Model
HL7 RIM &CDC PHLDM
CanonicalMessage Profile
LaboratoryMessage Object
Model
Extract,Transform,and Load
LaboratoryDatamart
BusinessIntelligenceApplication
BusinessIntelligenceApplication
BusinessIntelligenceApplication
OutboundMessage Profile
Extract,Transform,and Load
Additional DataSources
March 2005 V2 Messaging Conformance 116 of 122
California Electronic Laboratory Reporting System
InboundLaboratoryMessage
InboundMessage Profile
Transform
Translate
InboundMessage Mapping
CanonicalLaboratoryMessage
CanonicalMessage Profile
Transform
Translate
OutboundMessage Mapping
OutboundLaboratoryMessage
Outbound
Lab MessageSupplier
Lab MessageConsumer
KnowledgeManagement
Service
KnowledgeManagement
Service
Object GraphGeneration
LaboratoryMessageObjects
ObjectRelationalMapping
LaboratoryMessage
Respository
Object RelationalMap
ELR DatabaseDesign Model
CA Public HealthLogical Data
Model
HL7 RIM &CDC PHLDM
CanonicalMessage Profile
LaboratoryMessage Object
Model
Extract,Transform,and Load
LaboratoryDatamart
BusinessIntelligenceApplication
BusinessIntelligenceApplication
BusinessIntelligenceApplication
Message Profile
Extract,Transform,and Load
Additional DataSources
March 2005 V2 Messaging Conformance 117 of 122
Message Profiles
• Describe message structure and anticipated application behavior
• Identify required, optional, and conditional message elements
• Identify coding systems or value-sets for coded elements
• Enable message validation, transformation, and persistence
• Are essential for achieving system-to-system interoperability
InboundLaboratoryMessage
InboundMessage Profile
Transform
Translate
InboundMessage Mapping
CanonicalLaboratoryMessage
CanonicalMessage Profile
Transform
Translate
OutboundMessage Mapping
OutboundLaboratoryMessage
OutboundMessage Profile
March 2005 V2 Messaging Conformance 118 of 122
Message-Level Profile
• Which Segments are Supported?
• Which Segments are Required?
• How are Segments Grouped?
• What is the order of Segments and Segment groups
• Which Segments/Segment Groups are repeatable?
• What is the cardinality of repeating segments/segment Groups?
March 2005 V2 Messaging Conformance 119 of 122
Segment-Level Profile
• Which Fields are Supported?
• Which Fields are Required?
• What is the order of fields within the segment?
• What is the datatype of each field?
• Which fields are repeatable?
• What is the cardinality of repeating fields?
• What maximum field length is supported?
• What value tables are associated with the field?
March 2005 V2 Messaging Conformance 120 of 122
Field-Level Profile
• Which Field components are supported?
• Which Field components are Required?
• What is the order of components within a field?
• What is the datatype of each field component?
• Which fields components are repeatable?
• What is the cardinality of repeating fields components?
• What maximum length is supported for field components?
• What value tables are associated with the field components?
March 2005 V2 Messaging Conformance 121 of 122
Questions / Discussion / Feedback
March 2005 V2 Messaging Conformance 122 of 122
Thank You
Abdul-Malik ShakirPrincipal Consultant
Shakir Consulting1911 Foothill Blvd., Suite 148
La Verne, CA 91750
Office: (909) 596-6790 Mobile: (626) 644-4491
Email: [email protected]