Hl7 v2 messaging conformance jan 2011
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Hl7 v2 messaging conformance jan 2011

  • 3,014 views
Uploaded on

A tutorial I presented at the HL7 January 2011 working group meeting.

A tutorial I presented at the HL7 January 2011 working group meeting.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Excellent tutorial ! Thanks much for posting the same.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
3,014
On Slideshare
3,012
From Embeds
2
Number of Embeds
1

Actions

Shares
Downloads
145
Comments
1
Likes
3

Embeds 2

http://www.slashdocs.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11 Use case model (1..1) Static Definition (1..*) or reference Dynamic Definition (1..1) Vocabulary definition (1..1) with v2.6, hopefully
  • 03/03/11
  • 03/03/11 In V3, they went with storyboards – that would work here as well. HDF (HL7 Development Framework) is the future replacement to the MDF – which is outdated.
  • 03/03/11 MSH:9.1 Message Type MSH 9.2 Trigger Event ORC:1 Order Control Code Actually, a Z trigger is not necessarily based on HL7 std message: MSH, Z01, Z02
  • 03/03/11 The figure depicts the HL7 Message Profile as an overlay of the HL7 Message Structure that is further constrained. For example, where the HL7 Message Structure shows unlimited number of NK1 Segments, the HL7 Message Profile allows for only three repetitions. Additionally, fields that are optional in the HL7 Message Structure may be required within the HL7 Message Profile. For example, where the HL7 Message Structure shows unlimited number of NK1 Segments, the Message Profile allows for only three repetitions Fields that are optional in the HL7 may be required within the HL7 Message Profile may be not supported within the HL7 Message Profile (PV1.x) Field repetitions may be constrained Components that are optional in the HL7 Message Structure (PV1-3) may be required within the HL7 Message Profile may be not supported within the HL7 Message Profile
  • 03/03/11 Enhanced mode acknowledgement: MSH-15 MSH-16
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11 There are three basic profile types used in documenting standard conformance: HL7 Standard profile (represents a specific HL7 published standard, creation and publication limited to HL7 use) Constrainable profile (with “Optional” elements which must be further constrained in order to create implementation profiles) Implementation profile (no “Optional” parts, fully implementable). This model allows vendors or providers to publish generic profiles from which fully constrained implementation profiles can be created. In comparison with the HL7 standard, separate constrainable and implementation profiles may exist for the receiving and the sending role. Both constrainable profiles and implementation profiles focus primarily on the expectations of the sending application, with minimal constraints on the application behavior of the receiver. Due to the HL7 principle of not specifying application behavior, this message profile section will not address use cases where explicit constraints on the expected behavior of the receiver application (e.g. whether the receiver must process information, ignore it or generate an error) are required. Realm Realms, national and regional, profiles represent localization and restrictions placed on the appropriate standard, while providing enough optionality for basing the more specific implementation profiles. Some examples of realm constrainable profiles are: AS4700.1-2001 Implementation of HL7 v2.3.1 Part 1:Patient Administration (constrainable profile for Australian Standards, constrains HL7 2.3.1, Chapter 3). AS/NZS 4700.3-1999 Implementation of HL7 v2.3 Part 3: Electronic messages for exchange of information on Drug Prescription (constrainable profile for Australian Standards, constrains HL7 2.3, various Chapters). Vendor Vendor giving source to customers who will modify the code Configurable implementation Cross-product development guide Interface Engines - runtime
  • 03/03/11 expressed as a minimum-maximum pair of non-negative integers (such that the minimum is less than or equal to the maximum). A conformant application must always send at least the minimum number of repetitions, and may never send more than the maximum number of repetitions. (In practice, all elements have some maximum value limit (e.g. 2^15 – 1). However, if this upper boundary is orders of magnitudes above the number of reasonable repetitions, it is acceptable to use ‘*’) Some tools can’t handle the “*”. They use 0 to represent unlimited (length, repetitions)
  • 03/03/11
  • 03/03/11
  • 03/03/11 Process= save/print/archive/etc.
  • 03/03/11
  • 03/03/11
  • 03/03/11 Based on other values in message: not necessarily before that point in the message.
  • 03/03/11
  • 03/03/11 Please update your handout Conditional and be set to required if conditionality rule is satisfied by the use case U is not a valid HL7 optionality – cross it out (I’ve removed from the slide) W is a new optionality code added in v2.5
  • 03/03/11 If the profile author wishes to express a circumstance 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 with the minimum cardinality representing the minimum number of repetitions when the element is present. In UML, this would generally be expressed as (0,n..m), indicating that permitted occurrences are either zero, or the range of n through m)
  • 03/03/11 Added the last two rows
  • 03/03/11 HL7 Messages are constructed using a hierarchy of elements in which messages contain segment groups and segments, segment groups contain other segment groups and segments, segments contain fields, fields contain components and components contain sub-components. As part of the conformance framework, there is an additional rule for determining whether a particular 'element' is present. The rule is as follows: For an element to be considered present, it must have content. This means that simple elements (fields, components or sub-components with simple data types such as NM, ST, ID) must have at least one character. Complex elements (those composed of other elements. e.g. Messages, Segment Groups, Segments, Fields with complex data types such as CE, XPN, etc.), must contain at least one component that is present. Elements that do not meet these conditions are not considered to be present. For example, if a segment is made up of 10 optional fields, at least one of the fields must be present in order for the segment to be considered present. Thus, if the segment is marked as Required, an instance message would only be conformant if the segment contained at least one field. The reason for this rule is to ensure that the intent of the profile is met. The rule is necessary because the traditional 'vertical bar' encoding allows for a bare segment identifier with no fields (e.g. a line containing just "NTE|" would be considered valid under the standard rules, but would be considered not present as far as testing against a conformance specification. The XML encoding also allows this, as well as fields without their components, components without their sub-components, etc. (e.g. .
  • 03/03/11
  • 03/03/11
  • 03/03/11 ADT_A01 With v2.5, there is now a status column that might show something as deprecated or not supported.
  • 03/03/11 ADT_A01 With v2.5, there is now a status column that might show something as deprecated or not supported.
  • 03/03/11 ADT_A01 With v2.5, there is now a status column that might show something as deprecated or not supported.
  • 03/03/11 ADT_A01 With v2.5, there is now a status column that might show something as deprecated or not supported.
  • 03/03/11 Examples: NK1s having special meaning and the fields being constrained based on that OBXs for a CBC HL7 segment definition based on a HL7 Segment Attribute Table
  • 03/03/11
  • 03/03/11
  • 03/03/11 The allowed code sets (table) for many fields within the HL7 Standard are specified as user-defined (data type IS) or HL7-defined (data type ID) values. For clarification of rules governing various code sets, see Section 2.5.3.6, "Table" . In these cases, the exact allowed code set shall be specified. These values shall be defined according to the specified scope of use for the message profile by vendors, provider, or within a realm. Coded Entry (CE, CF, CWE, and CNE) type fields are specified as being populated based on coding systems. For each of these fields, the specific coding system used shall be identified. Compliant applications are required to use the specified coding system, but may also use an alternate coding system as supported by the data type (See the example within each data type definition). Constant values If an element will always have a constant value, this shall be specified. Constant values may only be specified for elements that represent primitive data types, i.e., they have no components or sub-components. Data values A list of example data values for the element may be specified. Data values may only be specified for elements that represent primitive data types i.e. they no components or sub-components. Each component within composite fields shall be profiled. This requires defining the usage , length , data type , and data values of each of the components. Where there are sub-components of a component, each of the sub-components shall also be profiled using the same method. With the exception of cardinality, the rules for these definitions follow those for fields (See section 0 , " Static definition - segment level ").
  • 03/03/11 Each message profile may have a unique identifier to facilitate reference. Static definition identifier Each static definition must have a unique identifier when registered (See section 2.12.9, "Message profile document"). An authority other than the registry may define this identifier. If, at the time of registration, the static profile does not have an identifier assigned by the submitter’s authority, the registry authority will assign one. The static definition identifier would be the identifier used if a system asserts a strict conformance claim (See MSH-21 Message Profile Identifier (EI) 01598 ).
  • 03/03/11
  • 03/03/11
  • 03/03/11 Show meaningful gaps for estimating work effort
  • 03/03/11
  • 03/03/11 This course is designed to explore the concept of conformance within HL7 Version 2 as described in Chapter 2 of Version 2.5. Additionally, this tutorial will demonstrate how we can apply message profiling to interoperability by improving clarity, simplifying implementations and streamlining testing. Participants will be introduced to tools that facilitate analysis and interoperability while, at the same time, fully documenting HL7 conformance.
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11 Load Message Structures
  • 03/03/11 Message and event type selection list
  • 03/03/11
  • 03/03/11 Click the compile button Add a segment Add a field Add another segment Group the newly added segments
  • 03/03/11 Profile ready to be constrained, created from standard libraries
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11 Notice that the Conformance Profile button is not available and the Usage codes available are what HL7 allows Unknown should be Withdrawn – there is no unknown in HL7 What about “varies”?
  • 03/03/11
  • 03/03/11 Notice that the conformance Profile button is now available
  • 03/03/11
  • 03/03/11
  • 03/03/11 Open file with Diagram
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11 Reports Display Tab
  • 03/03/11 Reports drop down list and report viewer toggle button
  • 03/03/11 Text view of SpecXML report when toggle button displays a scroll icon
  • 03/03/11 HTML view of SpecXML report; toggle button displays Internet Explorer icon
  • 03/03/11 Report File Menu showing XSL Translation and Validation options; HL7 Registry Profile production button Should to be in the text mode (not HTML) before pressing the HL7 button.
  • 03/03/11
  • 03/03/11 This is another way to register – can’t do if not online
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11 Can’t do if not online
  • 03/03/11 Can’t do if not online
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11
  • 03/03/11

Transcript

  • 1. Version 2.x Messaging Conformance Abdul-Malik Shakir Principal Consultant, Shakir Consulting HL7 Working Meeting January 2011 – Sydney, AU
  • 2.
    • Abdul-Malik Shakir
    • Principal Consultant, Shakir Consulting, La Verne, CA
    • HL7 Member since 1991
    • Principal Consultant with Shakir Consulting
    • Chief Technical Architect with Cal2Cal Corporation
    • Co-Chair of the HL7 Education Committee
    • Member of the HL7 Architectural Review Board
    • Member of the HL7 Public Health and Emergency Response Committee
    • Member of the HL7 Regulated Clinical Research Information Management Committee
    • Member of the HL7 Modeling and Methodology Committee
  • 3. 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
    • Sample Projects
      • CADHS ELR
      • CA SIIS SIP
  • 4.
    • Health Level Seven
    • What and Why
  • 5. An HL7 Messaging Scenario: Why User Interface Program Module Dataset User Interface Program Module Dataset Message Creation Message Parsing A to B Transformation Message Parsing Message Creation B to A Transformation Order Entry Application System Laboratory Application System Lab Order Transaction Order Entry Application System Laboratory Application System Lab Result Transaction
  • 6. Reaching the Limits of Application Interfaces Lab Order Entry ADT Pharmacy Radiology Decision Support Electronic Health Record Administrative Systems ? Enterprise Systems ? External Systems ?
  • 7. Health Level Seven: Why
    • The number of interfaces between N systems is given by the formula I = (N 2 -N)/2.
    • Linking systems only needs 1 interface, ;
    • Linking 6 systems needs as many as 15 interfaces, (6 2 – 6) / 2 = 15
    • The benefits of using the HL7 standard increase rapidly with the number of systems involved. I = N
    3 (3 2 - 3) / 2 = 3 2 (2 2 - 2) / 2 = 1 4 (4 2 - 4) / 2 = 6
  • 8. Health Level Seven: Why Tolerable Painful Intolerable
  • 9. Divide and Conquer / Component Reuse DATA Visit Billing Results Reporting Next of Kin ( NK 1 ) Insurance ( IN 1 ) Patient Visit ( PV 1 ) Patient Demographics ( PID ) Guarantor ( GT 1 ) NK 1 IN 1 PV 1 PID GT 1 OBR OBX Next of KIN ( NK 1 ) Patient Visit ( PV 1 ) Patient Demographics ( PID )
  • 10. Abstract Message Specification
    • MSH Message Header
    • EVN Event Type
    • PID Patient 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.
    • }
    • ]
    Segment ID Segment Name [ ] optional { } may repeat
  • 11. MSH Segment Definition
  • 12. 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
  • 13. HL7 Message Elements
    • An HL7 message specification is an ordered collection of one or more segment groups where each segment group is an ordered collection of one or more segments. A segment may be part of more than one segment group; it can also appear more than once within the same segment group.
    • A segment is an ordered collection of fields. Each segment field is an instance of a data element. A data element may appear as a field in more than one segment or as more than one field within the same segment. Each data element is assigned a data type.
    • A datatype may be simple or composite. A composite datatype is an ordered collection of one or more data type components; a simple datatype has no components. A data type component is an instance of a data element. A data element may appear as a component of more than one composite data type or as more than one component of the same composite data type.
    • Segment fields and datatype components may be associated with a code table. A code table is a collection of code table items. Each code table item is a code system term from some code system. A code system may be HL7 defined, user defined, or defined by a third party. A code system term may be used as a code table item in more than one code table but may appear only once within the same code table.
  • 14. HL7 v2 Message Elements
  • 15. Sample HL7 v2.x Message
    • Segments
    • MSH: Message Header
    • PID: Patient Identification
    • OBR: Observation Request
    • OBX: Observation Result
    Delimiters | Field ^ Component & Subcomponent ~ Repetition Escape Character 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
  • 16.
    • Message Profiles
    • Why and When
  • 17. Reveal Assumptions Revealing assumptions is an essential component of effective communication. Yes, I do play football. Do you play football?
  • 18. Reveal Assumptions Message Profiles are an effective means of documenting our assumptions about message structures Do you use HL7? MSH EVN PID [PD1] [ { NK1 } ] Yes, I use HL7. MSH EVN PID [ NK1 ] OBX
  • 19. Reduce Ambiguity 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 MSH EVN PID [PD1] [ { NK1 } ]
  • 20. Highlight Conflicts Sharing message profiles provides an opportunity to identify and reconcile conflicts in our understanding and to validate our assumptions about message structures. MSH EVN PID [PD1] [ { NK1 } ] MSH EVN PID [ NK1 ] OBX
  • 21. Consolidate Viewpoints Message Profile Message Profile Message Profile MSH EVN PID [PD1] [ { NK1 } ] MSH EVN PID [ NK1 ] OBX MSH EVN { PID } [PD1] [ { GT1 } ] MSH EVN { PID } [PD1] [ { NK1 } ] [ { GT1 } ] [ OBX ] Canonical Message Profile
  • 22. Value of Message Profiling
    • Reveal Assumptions
    • Reduce Ambiguity
    • Highlight Conflicts
    • Consolidate Viewpoints
  • 23.
    • Message Profiles
    • What and How
  • 24. 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
  • 25. Message Profile Defined (cont’d)
    • 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
    of 15
  • 26. Conceptual Overview Message Profile = Static Profile + Dynamic Profile Critical Care Unit ADT System Clinical Data Repository Response Message Initiating Message Initiating Message
  • 27. 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)
  • 28. 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
  • 29. Static Definition Example ... ... ... 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 ... NK1 MSH EVN PID NK1 NK1 NK1 NK1 PV1 PV2 OBX AL1 HL7 Message Structure
  • 30. 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
  • 31. Dynamic Interaction Critical Care Unit HIS/CIS Clinical Data Repository A/D/T System Order Filling Application Accept Ack Accept + App ACK Receiver Responsibility MSH-15,16 No ACK
  • 32. How it all ties together
  • 33.
    • Message Profiles
    • Concepts and Constituents
  • 34. Profiling Concepts
    • Profile Types
      • HL7 Standard
      • Constrainable
      • Implementable
    • Generic term ‘message element’ used
      • Segment groups
      • Segments
      • Fields
      • Components
      • Sub-components
    • Cardinality
    • Usage
    Message Constituents
  • 35. 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.)
      • Organization / Application Specific
    • Implementation
      • Further constrained
      • No optionality
  • 36. 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 ‘*’)
  • 37. Cardinality Examples 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
  • 38. 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
  • 39. 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
  • 40. 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
  • 41. Usage (continued)
    • Optional
      • This code indicates that the Usage for this element has not yet been defined
      • May NOT be used in ‘Implementation’ profiles (no-optionality profiles)
      • Conformance cannot be tested on an Optional field
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. 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.
  • 46. Usage-Cardinality Combinations
  • 47. 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
  • 48.
    • Message Profiles
    • Levels and Examples
  • 49. 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
  • 50. Message Level Profile Example
  • 51. Message Level Profile Example
  • 52. Message Level Profile Example
  • 53. Message Level Profile Example
  • 54. 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)
  • 55. Segment Level Profile Example (PID)
  • 56. Segment Level Profile Example (PID)
  • 57. 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
  • 58. 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
  • 59. MSH-21 Message Profile Identifier
    • Sites may use this field to assert adherence to, or reference, a message profile. Message profiles contain detailed explanations of grammar, syntax, and usage for a particular message or set of messages.
    • Repetition of this field allows more flexibility in creating and naming message profiles. Using repetition, this field can identify a set of message profiles that the message conforms to.
      • the first repetition could reference a vendor's message profile
      • The second could reference another compatible provider's profile or a later version of the first vendor profile.
    • As of v2.5, the HL7 message profile identifiers might be used for conformance claims.
    • Prior to v2.5, the field was called Conformance Statement ID. For backward compatibility, the Conformance Statement ID can be used here.
  • 60. 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.
    Compliance Conformance
  • 61. 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
  • 62.
    • Messaging Workbench
    • What and Why
  • 63. 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
  • 64. 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
  • 65. 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
  • 66. HL7
  • 67. Constrainable
  • 68. Constrainable (continued)
  • 69. Implementation
  • 70. Message Profile
  • 71.
    • Messaging Workbench
    • Features and Use
  • 72. Capture/Analyze Message
  • 73. Reverse Engineer from Message
  • 74. New Profile Using Libraries
  • 75. New Profile Using Libraries (cont’d)
  • 76. New Profile Using Libraries (cont’d)
  • 77. New Profile Using Libraries (cont’d)
  • 78. New Profile Using Libraries (cont’d)
  • 79. New Profile using copy/paste
  • 80. New Profile Copy/Paste (cont’d)
  • 81. New Profile Copy/Paste (cont’d)
  • 82. Modifying a Profile – HL7
  • 83. Modifying a Profile – Constrainable
  • 84. Modifying Profile – Constr (cont’d)
  • 85. Modifying Profile – Implementation
  • 86. Modifying Profile – Impl (cont’d)
  • 87. Diagram Drawing Tool
  • 88.
    • Messaging Workbench
    • Reports and Examples
  • 89. Reports
  • 90. Reports (continued)
  • 91. Reports (continued)
  • 92. Reports (continued)
  • 93. Reports (continued)
  • 94. Reports (continued)
  • 95. Producing Profile Reports
  • 96. Producing Profile Reports (cont’d)
  • 97. Producing Profile Reports (cont’d)
  • 98. Producing Profile Reports (cont’d) Browser View
  • 99. Producing Profile Reports (cont’d)
  • 100. HL7 Message Profile
  • 101. Register Profile with HL7
  • 102.
    • Messaging Workbench
    • Contacts and Help
  • 103. MWB Contacts
    • The Implementation/Conformance WorkGroup is interested in your feedback and suggestions for improvement of the tool
    • Implementation/Conformance WorkGroup 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 peter.rontey@med.va.gov
  • 104. Where to Get More Information
    • MWB On-line help
  • 105. Where to Get More Info (cont’d)
    • MWB On-line help (cont’d)
  • 106. Where to Get More Info (cont’)
    • MWB Updates/Downloads
  • 107. Where to Get More Info (cont’d)
    • Conformance Tools Forum at Yahoo Groups
  • 108. California Department of Health Services Electronic Laboratory Reporting Project
  • 109.  
  • 110. Inbound Message Processing Outbound Message Processing Data Persistence Business Intelligence
  • 111. Inbound Laboratory Message Inbound Message Profile Transform Translate Inbound Message Mapping Canonical Laboratory Message Canonical Message Profile Transform Translate Outbound Message Mapping Outbound Laboratory Message Outbound Lab Message Supplier Lab Message Consumer Knowledge Management Service Knowledge Management Service Object Graph Generation Laboratory Message Objects Object Relational Mapping Laboratory Message Repository Object Relational Map ELR Database Design Model CA Public Health Logical Data Model HL7 RIM & CDC PHLDM Canonical Message Profile Laboratory Message Object Model Extract, Transform, and Load Laboratory Datamart Business Intelligence Application Business Intelligence Application Business Intelligence Application Message Profile Extract, Transform, and Load Additional Data Sources
  • 112. 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
  • 113. 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?
  • 114. 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?
  • 115. 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?
  • 116. California State Immunization Information System System Interface Project
  • 117.
    • The California State Immunization Information System (SIIS) is a collaboration of
      • regional immunization registries,
      • local health departments,
      • the California Department of Health Services Immunization Branch, and
      • a spectrum of key stakeholders across the state of California.
    • The goal of SIIS is to ensure that health care providers have rapid access to complete and up-to-date immunization records.
    • The objective is to eliminate both missed opportunities to immunize and unnecessary duplicate immunizations.
    • SIIS consists of nine regional registries and two county registries.
    • SIIS is a system of systems each independently managed and operated.
  • 118. Regional and County Registries
    • Immunization Network of Northern California (INNC)
    • Shots For Tots KIDS Regional Immunization Registry (SFT)
    • Bay Area Regional Immunization Registry (BARR)
    • Imperial County (IMPL) **
    • Contra Costa County Automated Immunization Registry (CCAIR)**
    • Regional Immunization Data Exchange (RIDE)
    • Central Valley Immunization Information System (CVIIS)
    • Central Coast Immunization Registry (CCIR)
    • Los Angeles-Orange Immunization Network (LINK)
    • VaxTrack Regional Immunization Registry (VaxTrack)
    • San Diego Regional Immunization Registry (SDIR)
  • 119.
    • The scope of the California Statewide Immunization Information System (SIIS) Systems Interface Project (SIP) is to design, construct, and implement a centralized electronic messaging hub that facilitates the automated exchange of immunization related data within the state of California.
    • The objective is to enable registry users to gain access to an individual’s complete immunization history regardless of where that history is maintained.
    Project Scope
  • 120.
    • The premise behind the project is that, for many reasons, a person’s immunization history data becomes fragmented over time.
    • The data are stored and maintained in separate state registries and immunization provider information systems.
    • Typical scenarios that lead to this situation are changes in a person’s primary residence, changes in a person’s primary healthcare provider, and ad hoc administration of immunizations such as during vacation or emergencies.
    • Once a person’s immunization data becomes fragmented across multiple registry or provider information systems it can be difficult to ascertain their current immunization status.
    • This can result in over immunization or under immunization.
    Problem Statement
  • 121.
    • A combination of manual and automated processes are employed to address this issue.
    • First and foremost, providers are encouraged to enroll in regional registries and to record administered immunizations in the registry. All providers within the jurisdiction of the regional registry will then have access to the same data.
    • Second, a CIR (yellow card) with the person’s immunization history is updated by administering providers and carried by the patient, parent, or guardian to all settings requiring an official immunization record.
    • Finally, immunization data may be requested from a former provider by phone, email, or fax and then entered into the immunization registry system.
    Current Processes
  • 122.
    • There are serious inefficiencies and limitations associated with the current processes used to address the fragmentation of a person’s immunization history data.
    • The yellow card is often out of date, misplaced or otherwise unavailable.
    • Some healthcare providers operate in multiple regional registry jurisdictions and find the prospect of coordinating reporting to multiple registries to be too much of an administrative burden.
    • Some providers would prefer to have an automated means of exchanging data between the regional registry system and their electronic systems. These providers object to entering data into regional registries because it involves redundant data entry.
    Current Limitations
  • 123.
    • Today immunization information is not easily able to follow the approximately 30,000 CA children moving throughout the state each year.
    • SIP will address this shortcoming by enabling the electronic exchange of immunization related data.
    • The SIIS SIP Immunization Information Exchange System will support the electronic request and response for immunization data from one registry to another.
    • Regional and county registries, healthcare providers, and multi-jurisdictional provider organizations will be able to participate in a SIIS SIP information network and use electronic messages based upon HL7 messaging standards to exchange immunization data.
    SIIS SIP SOLUTION
  • 124. HL7 Message Profiling
  • 125.
    • Prepare IZ messaging implementation guide
    • Prepare preliminary segment level profile
    • Prepare SIIS SIP conceptual data model
    • Map preliminary profile to regional IZ systems
    • Prepare final segment level profile
    • Prepare SIIS SIP logical data model
    • Prepare SIIS SIP phase I message level profiles
    • Prepare SIIS SIP vocabulary specification
  • 126. Immunization Messaging Implementation Guide
    • The Centers for Disease Control and Prevention (CDC) National Immunization Program (NIP) publishes an implementation guide for immunization data messaging.
    • The title of the guide is “Implementation Guide for Immunization Data Transactions using version 2.3.1 of the Health Level Seven (HL7) Standard Protocol”.
    • The intent of the guide is to help familiarize developers of immunization information systems with HL7 immunization message definitions and encoding rules and provide a nationally consistent implementation of those messages.
    • Changes to the guide are coordinated through the Data Exchange Steering Committee of the American Immunization Registry Association (AIRA) and its associated work groups.
    • The members of AIRA are committed to advancing the exchange of immunization data using a common protocol.
  • 127. Immunization Messaging Implementation Guide
    • The guide identifies the set of HL7 messages needed to enable information systems that maintain immunization records to transmit patient-specific immunization histories electronically to other systems to allow healthcare providers to have access to these records at the time health care is given.
    • The use cases detailed in the guide indicate that data transmission will occur as the result of four activities:
      • a query from one system for a patient’s vaccination record that is held in another system using the HL7 VXQ message;
      • a response to a query containing multiple patient “matches” to the query, but not returning vaccination records using the HL7 VXX message;
      • a response to a query containing the vaccination record using the HL7 VXR message; and
      • an unsolicited update to a vaccination record using the HL7 VXU message.
    • In addition to the messages used for the four primary activities the guide also includes specifications for transmission confirmation and exception notification messages; ACK and QCK.
  • 128. Preliminary Segment Level Profile
  • 129. SIIS SIP Conceptual Data Model
  • 130. Regional System to Segment Profile Mapping
  • 131. Regional System to Segment Profile Mapping
  • 132. Final Segment Level Profile
  • 133. SIIS SIP Logical Data Model
  • 134. SIIS SIP Message Level Profiles
    • HL7 defines a message profile as “an unambiguous specification of one or more standard HL7 messages that have been analyzed for a particular use case”. It prescribes a set of precise constraints upon one or more standard HL7 messages.
    • A message profile eliminates ambiguity in a HL7 message specification by declaring static and semantic constraints for constituent elements of a message and the expected dynamic behavior of conformant application systems.
    • The SIIS SIP HL7 message profile is an extension to the NIP Implementation Guide. The profile is based upon version 2.1 of the guide published in September 2002.
    • The profile extends the specifications included in the guide. The profiles do not conflict with the guide; however, they are more constrained than the guide.
    • Messages that conform to the profile are conformant with the guide as well; although the converse may not be true.
    • A message profile has dynamic definition and a static definition.
  • 135. HL7 Message Profile Dynamic Definition
    • The dynamic definition describes the supported use cases, interactions, and acknowledgement requirements.
      • Use Case Model
      • The use case portion of the message profile dynamic definition documents the scope and requirements for an HL7 message profile or set of message profiles. The use case model documents the purpose for each message exchange; defines the actors, including the sending and receiving applications; and document the situations in which the exchange of a particular HL7 message profile is required
      • Interaction Model
      • The Interaction Model illustrates the sequence of trigger events and resulting message flows between 2 or more systems. It may be in literal or graphical form. Graphical form should be a UML activity diagram.
      • Acknowledgement Requirements
      • The specific HL7 acknowledgments required and/or allowed for use with the specified static definition of the HL7 message profile is defined. Specifically, the dynamic definition identifies whether accept and application level acknowledgments are allowed or required. For any one static definition there may be one or more dynamic definitions. The dynamic definition defines the conditions under which accept and application level acknowledgments are expected. Allowed conditions include: Always, Never, Only on success, and Only on error.
  • 136. HL7 Message Profile Static Definition
    • The static definition describes usage rules, cardinalities, and code systems.
      • Usage Rules
      • Usage refers to the circumstances under which an element appears in a message instance. Some elements must always be present, others may never be present, and others may only be present in certain circumstances. HL7 has defined a set of codes to clearly identify the rules governing the presence of a particular element. These usage codes expand/clarify the optionality codes defined in the HL7 standard.
      • Cardinality
      • Cardinality identifies the minimum and maximum number of repetitions for a particular element (Segment Group, Segment or Field). Cardinalities are expressed as a minimum-maximum pair of non-negative integers. A conformant application must always send at least the minimum number of repetitions, and may never send more than the maximum number of repetitions.
      • Vocabulary Specification
      • Vocabulary specifications declare an organized set of code systems and code system terms. Code system terms are coded concepts including concept codes, concept names, and concept relationships. Code system terms are collected into value sets declared as code tables associated with segment fields and data type components. The static definition declares the value sets for tables associated with coded message elements. Some of the value sets are HL7 defined, third party defined, or user defined.
  • 137. SIIS SIP Use Case Diagram
  • 138. SIIS SIP Activity Model 1 2 3 4 6 5
  • 139. SIIP SIP Interaction Model
  • 140. SIIS SIP Acknowledgement Requirements Message Source Destination Acknowledgment
    • Vaccination Record Query (VXQ)
    Requester IIES Only on error
    • General Acknowledgement (ACK)
    IIES Requester Never
    • Vaccination Record Query (VXQ)
    IIES Responder Never
    • Query Acknowledgement (QCK)
    Responder IIES Only on error
    • General Acknowledgement (ACK)
    IIES Responder Never
    • Query Acknowledgement (QCK)
    IIES Requester Never
    • Vaccination Query Response (VXX)
    Responder IIES Only on error
    • General Acknowledgement (ACK)
    IIES Responder Never
    • Vaccination Query Response (VXX)
    IIES Requester Never
    • Vaccination Query Response (VXR)
    Responder IIES Only on error
    • General Acknowledgement (ACK)
    IIES Responder Never
    • Vaccination Query Response (VXR)
    IIES Requester Never
  • 141. SIIS SIP Message Profile Static Definitions
    • The static definition portion of the message profile declares the usage and cardinality constraints for the constituent message elements of the SIIS SIP HL7 messages.
    • There is a static definition for each message type (VXQ, VXX, VXR, QCK, and ACK).
    • Each static definition includes a message level, segment level, and field level definition.
    • The static definition also includes a supported elements definition.
    • The supported elements definition is a field level definition containing supported message elements only.
  • 142.
    • The static definition portion of the message profile declares the usage and cardinality constraints for the constituent message elements of the SIIS SIP HL7 messages.
    • There is a static definition for each message type (VXQ, VXX, VXR, QCK, and ACK).
    • Each static definition includes a message level, segment level, and field level definition.
    • The static definition also includes a supported elements definition.
    • The supported elements definition is a field level definition containing supported message elements only.
    SIIS SIP Message Profile Static Definitions
  • 143. SIIS SIP Message Profile Static Definitions
    • The static definition portion of the message profile declares the usage and cardinality constraints for the constituent message elements of the SIIS SIP HL7 messages.
    • There is a static definition for each message type (VXQ, VXX, VXR, QCK, and ACK).
    • Each static definition includes a message level, segment level, and field level definition.
    • The static definition also includes a supported elements definition.
    • The supported elements definition is a field level definition containing supported message elements only.
  • 144. SIIS SIP Message Profile Vocabulary Specification
    • The Health Level Seven (HL7) message profile vocabulary specification is a companion document to the California State Immunization Information System System Interface Project HL7 message profiles.
    • The specification contains the value sets for supported coded message elements identified in the profile.
    • The values presented in this specification are the primary code values to be used for coded message elements in the SIIS SIP message profile.
    • Fields with a data type of CE may include an equivalent code drawn from an alternate coding system. However, the values included in this specification must be used as the primary code.
  • 145. SIIS SIP Message Profile Vocabulary Specification
    • The Health Level Seven (HL7) message profile vocabulary specification is a companion document to the California State Immunization Information System System Interface Project HL7 message profiles.
    • The specification contains the value sets for supported coded message elements identified in the profile.
    • The values presented in this specification are the primary code values to be used for coded message elements in the SIIS SIP message profile.
    • Fields with a data type of CE may include an equivalent code drawn from an alternate coding system. However, the values included in this specification must be used as the primary code.
  • 146. Application Testing
  • 147.  
  • 148. Test Themes and Scenarios
    • Valid message syntax, content, and flow
    • Valid message syntax, content, and invalid flow
    • Valid message syntax, invalid content
    • Invalid message syntax
    • Data content scenarios
    • Technical problems
  • 149. Test Scenarios
    • Valid Message Syntax, Content, and Flow
    • This set of tests is intended to ensure that the systems produce the appropriate flow of messages, with the proper content, and in the proper syntax. These tests should not result in anything being written to the error log.
      • VXQ, QCK
      • This scenario is a query for a patient that is known to have no match in the remote system. The remote system is expected to respond with a QCK.
      • The test data should include patients with varying ranges of matching confidence.
      • VXQ, VXR
      • This scenario is a query for a patient that is known to match a single patient in the remote system. The remote system is expected to respond with a VXR.
      • The test data should include patients with varying ranges of matching confidence. A subset of patients should have locked records to test the “locked record” alerting process
  • 150. Test Scenarios
    • Valid Message Syntax, Invalid Content
    • This set of tests is intended to ensure that message construction and validation rules are properly implemented. These test are focused on content issues not syntax errors. The message profile and vocabulary specification are the source of validation rules.
      • Missing required message element
      • This scenario involves the omission of required message elements (segments, fields, or components). The omitted items in this test scenario are those that are specified as optional in the standard but declared as required in the SIIS SIP Message Profile. Such an error should result in an ACK message being returned to the message originator and an entry in the error log.
      • Missing conditionally required message element
      • This scenario involves the omission of conditionally required message elements (segments, fields, or components). The omitted items in this test scenario are those that are specified as optional in the standard but declared as conditionally required in the SIIS SIP Message Profile. Such an error should result in an ACK message being returned to the message originator and an entry in the error log.
      • The test data for this scenario must include a mixture of data values that meet the predicate conditions and others that do not meet the predicate conditions relevant for the conditional elements.
  • 151. SIIS SIP HL7 Message Profile Links
    • SIIS SIP Message Profile Specification
    • http://www.ca-siis.org/images/docs/SIIS_SIP_HL7_MessageProfile_V1-1.pdf
    • SIIS SIP Vocabulary Specification
    • http:// www.ca-siis.org/images/docs/SIIS_SIP_HL7_Message_Profile_Vocabulary_Specification_V1-0.pdf
    • SIIS SIP Logical Data Model
    • http:// www.ca-siis.org/images/docs/SIIS_SIP_LogicalDataModel_v1-0.pdf
  • 152. Questions
  • 153. Thank You Abdul-Malik Shakir Principal Consultant Shakir Consulting 1407 Foothill Blvd., Suite 145 La Verne, CA 91750 Office: (909) 596-6790 Mobile: (626) 644-4491 Email: [email_address] Abdul-Malik Shakir Information Management Strategist City of Hope 1500 East Duarte Road Duarte, CA 91010-3000 Office: (626) 256-4673 Mobile: (626) 644-4491 Email: [email_address]