Hl7 v2 messaging conformance jan 2011
•Descargar como PPT, PDF•
8 recomendaciones•5,510 vistas
A tutorial I presented at the HL7 January 2011 working group meeting.
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Hl7 v2 messaging conformance jan 2011
Similar a Hl7 v2 messaging conformance jan 2011 (20)
Más de Abdul-Malik Shakir
Más de Abdul-Malik Shakir (19)
Último
Último (20)
Hl7 v2 messaging conformance jan 2011
- 1. Version 2.x Messaging Conformance Abdul-Malik Shakir Principal Consultant, Shakir Consulting HL7 Working Meeting January 2011 – Sydney, AU
- 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 ?
- 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 )
- 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
- 14. HL7 v2 Message Elements
- 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
- 26. Conceptual Overview Message Profile = Static Profile + Dynamic Profile Critical Care Unit ADT System Clinical Data Repository Response Message Initiating Message Initiating Message
- 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
- 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
- 50. Message Level Profile Example
- 51. Message Level Profile Example
- 52. Message Level Profile Example
- 53. Message Level Profile Example
- 55. Segment Level Profile Example (PID)
- 56. Segment Level Profile Example (PID)
- 66. HL7
- 67. Constrainable
- 69. Implementation
- 70. Message Profile
- 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)
- 89. 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
- 108. California Department of Health Services Electronic Laboratory Reporting Project
- 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
- 116. California State Immunization Information System System Interface Project
- 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
- 137. SIIS SIP Use Case Diagram
- 138. SIIS SIP Activity Model 1 2 3 4 6 5
- 139. SIIP SIP Interaction Model
- 146. Application Testing
- 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]
Notas del editor
- 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 &quot;NTE|&quot; 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. <PID.3/>.
- 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, &quot;Table&quot; . 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 , &quot; Static definition - segment level &quot;).
- 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, &quot;Message profile document&quot;). 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