1 / 153

Version 2.x Messaging Conformance

Version 2.x Messaging Conformance. AbdulMalik Shakir Principal Consultant, Shakir Consulting HL7 Working Meeting September 2012, Baltimore, MD. Abdul- Malik Shakir Principal Consultant, Shakir Consulting, La Verne, CA HL7 Member since 1991 Principal Consultant with Shakir Consulting

star
Download Presentation

Version 2.x Messaging Conformance

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.x Messaging Conformance AbdulMalik Shakir Principal Consultant, Shakir Consulting HL7 Working Meeting September 2012, Baltimore, MD

  2. Abdul-Malik Shakir Principal Consultant, Shakir Consulting, La Verne, CA HL7 Member since 1991 Principal Consultant with Shakir Consulting Director Research Informatics Architecture with City of Hope Co-Chair of the HL7 Modeling and Methodology Committee Member of the HL7 Education Committee Member of the HL7 Public Health and Emergency Response Committee Member of the HL7 Regulated Clinical Research Information Management Committee Member of the HL7 Clinical Interoperability Council

  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. Order Entry Application System Order Entry Application System Message Creation Message Parsing Lab Result Transaction Lab Order Transaction A to B Transformation B to A Transformation Message Parsing Message Creation Laboratory Application System Laboratory Application System An HL7 Messaging Scenario: Why Program Module User Interface Dataset User Interface Program Module Dataset

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

  7. 3 2 4 (32 - 3) / 2 = 3 (22 - 2) / 2 = 1 (42 - 4) / 2 = 6 Health Level Seven: Why • The number of interfaces between N systems is given by the formula I = (N2-N)/2. • Linking systems only needs 1 interface, ; • 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. I = N

  8. Health Level Seven: Why Tolerable Painful Intolerable

  9. Patient Visit PV 1 Patient ( PV 1 ) NK 1 Demographics PID ( PID ) Next of Kin IN 1 ( NK 1 ) OBX Guarantor ( GT 1 ) GT 1 Insurance OBR ( IN 1 ) Patient Demographics ( PID ) Patient Visit ( PV 1 ) Next of KIN ( NK 1 ) Divide and Conquer / Component Reuse Billing Results Reporting DATA Visit

  10. [ ] optional { } may repeat Abstract Message Specification Segment ID Segment Name 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. } ] …

  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. 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

  16. Message Profiles Why and When

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

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

  19. 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

  20. 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.

  21. 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

  22. Reveal Assumptions Reduce Ambiguity Highlight Conflicts Consolidate Viewpoints Value of Message Profiling

  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

  26. Initiating Message Response Message Initiating Message Conceptual Overview Message Profile = Static Profile +Dynamic Profile Critical Care Unit ADT System Clinical Data Repository

  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

  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. HL7 Message Structure MSH EVN PID NK1 NK1 NK1 NK1 NK1 PV1 PV2 ... OBX AL1 Static Definition Example 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

  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. Receiver Responsibility MSH-15,16 Accept + App ACK Critical Care Unit HIS/CIS No ACK A/D/T System Accept Ack Clinical Data Repository Order Filling Application Dynamic Interaction

  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

  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

  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

  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

More Related