1 / 118

Version 2 Messaging Conformance HL7 Educational Summit Chicago, Illinois

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

alvis
Télécharger la présentation

Version 2 Messaging Conformance HL7 Educational Summit Chicago, Illinois

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Version 2 Messaging ConformanceHL7 Educational SummitChicago, Illinois Abdul-Malik Shakir Principal Consultant, Shakir Consulting July 2005

  2. My HL7 Background Abdul-Malik Shakir Principal 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 V2 Messaging Conformance

  3. 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 Session Outline V2 Messaging Conformance

  4. Health Level Seven What and Why V2 Messaging Conformance

  5. Order Entry Application System Order Entry Application System Message Creation Message Parsing An HL7 Messaging Scenario: Why Lab Result Transaction Lab Order Transaction A to B Transformation B to A Transformation Message Parsing Message Creation Laboratory Application System Laboratory Application System Program Module User Interface Dataset User Interface Program Module Dataset V2 Messaging Conformance

  6. Decision Support Electronic Health Record Reaching the Limits of Application Interfaces Radiology Pharmacy ? ? ? ADT Administrative Systems Enterprise Systems External Systems Lab Order Entry V2 Messaging Conformance

  7. 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. V2 Messaging Conformance

  8. Abstract Message Specification [ ] optional { } may repeat 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 V2 Messaging Conformance

  9. MSH Segment Definition V2 Messaging Conformance

  10. 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 V2 Messaging Conformance

  11. MSH|^~\&|LABGL1||DMCRES||199812300100||ORU^R01|LABGL1199510221838581|P|2.3|||NE|NEMSH|^~\&|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 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 V2 Messaging Conformance

  12. Message Profiles Why and When V2 Messaging Conformance

  13. Reveal Assumptions Do you play football? Yes, I do play football. Revealing assumptions is an essential component of effective communication. V2 Messaging Conformance

  14. MSH EVN PID [PD1] [ { NK1 } ] MSH EVN PID [ NK1 ] OBX Reveal Assumptions Do you use HL7? Yes, I use HL7. Message Profiles are an effective means of documenting our assumptions about message structures V2 Messaging Conformance

  15. Reduce Ambiguity MSH EVN PID [PD1] [ { NK1 } ] 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 V2 Messaging Conformance

  16. Highlight Conflicts MSH EVN PID [ NK1 ] OBX MSH EVN PID [PD1] [ { NK1 } ] Sharing message profiles provides an opportunity to identify and reconcile conflicts in our understanding and to validate our assumptions about message structures. V2 Messaging Conformance

  17. Consolidate Viewpoints Canonical Message Profile MSH EVN { PID } [PD1] [ { NK1 } ] [ { GT1 } ] [ OBX ] MSH EVN PID [PD1] [ { NK1 } ] MSH EVN PID [ NK1 ] OBX MSH EVN { PID } [PD1] [ { GT1 } ] Message Profile Message Profile Message Profile V2 Messaging Conformance

  18. Reveal Assumptions Reduce Ambiguity Highlight Conflicts Consolidate Viewpoints Value of Message Profiling V2 Messaging Conformance

  19. Compliance and Conformance Compliance 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. V2 Messaging Conformance

  20. 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 V2 Messaging Conformance

  21. 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 V2 Messaging Conformance

  22. Message Profiles What and How V2 Messaging Conformance

  23. 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 V2 Messaging Conformance

  24. 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 V2 Messaging Conformance

  25. Message Profile = Static Profile +Dynamic Profile Initiating Message Response Message Conceptual Overview Critical Care Unit ADT System Initiating Message Clinical Data Repository V2 Messaging Conformance

  26. 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) V2 Messaging Conformance

  27. 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 V2 Messaging Conformance

  28. HL7 Message Structure MSH EVN PID Static Definition Example NK1 NK1 NK1 NK1 NK1 PV1 PV2 ... OBX AL1 Message Profile MSH • Segments/Segment Groups: • Usage (Optionality) • Cardinality (min, max) EVN PID ... NK1 NK1 NK1 NK1 NK1 PV1 ... Fields/Components: - Usage (Optionality) - Cardinality (min, max) - Value Sets/Coding system - Descriptions PV2 ... OBX AL1 V2 Messaging Conformance

  29. 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 V2 Messaging Conformance

  30. Receiver Responsibility MSH-15,16 Dynamic Interaction Accept + App ACK Critical Care Unit HIS/CIS No ACK A/D/T System Accept Ack Clinical Data Repository Order Filling Application V2 Messaging Conformance

  31. How it all ties together V2 Messaging Conformance

  32. Message Profiles Concepts and Constituents V2 Messaging Conformance

  33. Profiling Concepts Message Constituents • 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 V2 Messaging Conformance

  34. 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 V2 Messaging Conformance

  35. 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 ‘*’) V2 Messaging Conformance

  36. Examples of common cardinality combinations are: Element Cardinality Cardinality Examples V2 Messaging Conformance

  37. 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 V2 Messaging Conformance

  38. 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 V2 Messaging Conformance

  39. 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 V2 Messaging Conformance

  40. 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 V2 Messaging Conformance

  41. 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 V2 Messaging Conformance

  42. 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 V2 Messaging Conformance

  43. Optionality / Usage Relationship • Conformance Usage codes are more specific than HL7 Optionality codes V2 Messaging Conformance

  44. 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. V2 Messaging Conformance

  45. Usage-Cardinality Combinations V2 Messaging Conformance

  46. 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 V2 Messaging Conformance

  47. Message Profiles Levels and Examples V2 Messaging Conformance

  48. 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 V2 Messaging Conformance

  49. Message Level Profile Example V2 Messaging Conformance

  50. 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) V2 Messaging Conformance

More Related