1. Version 2 Messaging Conformance Version 2 Messaging Conformance HL7 Educational Summit Chicago, Illinois Abdul-Malik Shakir Principal Consultant, Shakir Consulting July 2005

2. March 2005V2 Messaging Conformance2 of 122 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

3. March 2005V2 Messaging Conformance3 of 122 Session Outline Part I Background HL7: What, and Why Message Profile: Why and When Message Profiles: What and How Concepts and Constituents Levels and Examples Part II Messaging Workbench What and Why Features and Use Reports and Examples Contacts and Help CADHS ELR Project Project Scope Message Profiles

4. March 2005V2 Messaging Conformance4 of 122 Health Level Seven What and Why

5. March 2005V2 Messaging Conformance5 of 122 An HL7 Messaging Scenario: Why User Interface Program Module Program Module Dataset User Interface Program Module Program Module Dataset Message Creation Message Parsing A to B Transformation A to B Transformation Message Parsing Message Creation B to A Transformation 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. March 2005V2 Messaging Conformance6 of 122 Reaching the Limits of Application Interfaces Lab Order Entry ADT Pharmacy Radiology Decision Support Decision Support Electronic Health Record Electronic Health Record Administrative Systems Administrative Systems ? Enterprise Systems Enterprise Systems ? External Systems External Systems ?

7. March 2005V2 Messaging Conformance7 of 122 Health Level Seven: Why The number of interfaces between N systems is given by the formula (N 2 -N)/2. Linking 2 systems only needs 1 interface, (2 2 – 2) / 2 = 1; 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.

8. March 2005V2 Messaging Conformance8 of 122 Abstract Message Specification MSHMessage Header EVNEvent Type PIDPatient Identification [PD1]Additional Demographics [ { NK1 } ]Next of Kin /Associated Parties PV1Patient Visit [ PV2 ]Patient Visit - Additional Info. … [ { GT1 } ]Guarantor [ { IN1Insurance [ IN2 ]Insurance Additional Info. [ IN3 ] Insurance Add'l Info - Cert. } ] … [ ] optional { } may repeat Segment IDSegment Name

9. March 2005V2 Messaging Conformance9 of 122 MSH Segment Definition

10. March 2005V2 Messaging Conformance10 of 122 MSH Segment Definition SEQ - position within segment LEN - length of field DT - data type for field OPT - optionality for field RP/# - repeatability TBL# - table number for codes ITEM# - HL7 element number ELEMENT NAME - name

11. March 2005V2 Messaging Conformance11 of 122 Sample HL7 v2.x Message Segments MSH: Message Header PID: Patient Identification OBR: Observation Request OBX: Observation Result MSH|^~\&|LABGL1||DMCRES||199812300100||ORU^R01|LABGL1199510221838581|P|2.3 |||NE|NE PID|||6910828^Y^C8||Newman^Alfred^E||19720812|M||W|25 Centscheap Ave^^ Whatmeworry^UT^85201^^P||(555)777-6666|(444)677-7777||M||773789090 OBR||110801^LABGL|387209373^DMCRES|18768-2^CELL COUNTS+DIFFERENTIAL TESTS (COMPOSITE)^LN|||199812292128||35^ML|||||||IN2973^Schadow^Gunther^^^^MD^UPIN ||||||||||^Once||||||CA20837^Spinosa^John^^^^MD^UPIN OBX||NM|4544-3^HEMATOCRIT (AUTOMATED)^LN||45||39-49 |||| F|||199812292128||CA20837 OBX||NM|789-8^ERYTHROCYTES COUNT (AUTOMATED)^LN||4.94|10*12/mm3 |4.30-5.90||||F|||199812292128||CA20837 Delimiters | Field ^ Component & Subcomponent ~ Repetition \ Escape Character

12. March 2005V2 Messaging Conformance12 of 122 Message Profiles Why and When

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

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

15. March 2005V2 Messaging Conformance15 of 122 Message Profiles provide a language that allows us to unambiguously express our understanding and assumptions about the information in a message structure used in a particular scenario Reduce Ambiguity MSH EVN PID [PD1] [ { NK1 } ]

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

17. March 2005V2 Messaging Conformance17 of 122 Consolidate Viewpoints 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

18. March 2005V2 Messaging Conformance18 of 122 Value of Message Profiling Reveal Assumptions Reduce Ambiguity Highlight Conflicts Consolidate Viewpoints

19. March 2005V2 Messaging Conformance19 of 122 Compliance and Conformance Compliance Messages that adhere to the rules and conventions for constructing of a specific version of a standard are compliant to that version of the standard. Conformance Messages that adhere to the constraints of a precise and unambiguous specification called a message profile are said to be conformant to the profile. ComplianceConformance

20. March 2005V2 Messaging Conformance20 of 122 Conformance Project Background Began in 1997 by the HL7 Conformance SIG The SIG, in conjunction with the Andover Working Group (AWG), prepared this specification to: Define the HL7 Message Profile Recommend a specification for defining specific message profiles of HL7 messages Facilitate HL7 interpretation by users familiar with the HL7 standard, reducing interface analysis time and dissatisfaction with the HL7 standard

21. March 2005V2 Messaging Conformance21 of 122 Conformance SIG HL7 Conformance has two objectives: Interoperability Implementable message profiles Certification Conformance Statement Normative Documentation Chapter 2 Message Profile Schema/DTD Tutorial - education You are invited to participate! Bi-weekly calls List server

22. March 2005V2 Messaging Conformance22 of 122 Message Profiles What and How

23. March 2005V2 Messaging Conformance23 of 122 Message Profile Defined Unambiguous specification of a standard HL7 message for use within a particular set of requirements Prescribes a set of precise constraints upon one or more standard messages Supported by use case analysis and interaction modeling Measurable What data will be passed in a message The format in which the data will be passed The acknowledgement responsibilities of the sender and receiver

24. March 2005V2 Messaging Conformance24 of 122 Message Profile Defined (continued) Based on HL7, although may further constrain Static structure and content of each message The dynamic interactions Parts of a valid message profile Use Case Model Static Definition Dynamic Definition Represented as an XML document Can be registered with HL7 May be reused by other HL7 users May be used for documentation

25. March 2005V2 Messaging Conformance25 of 122 Conceptual Overview Message Profile = Static Profile + Dynamic Profile Critical Care Unit ADT System Initiating Message Response Message Initiating Message Clinical Data Repository

26. March 2005V2 Messaging Conformance26 of 122 Use Case Model Documents the scope and requirements for an HL7 Message Profile or set of Message Profiles May include a use case diagram or detailed text Provides a name that clearly and concisely defines the exchange Defines the actors, including the sending and receiving applications Defines the responsibilities of these actors Documents the situations in which the exchange of a particular HL7 Message Profile is required Documents the purpose V3.0 Message Development Framework (MDF 99)

27. March 2005V2 Messaging Conformance27 of 122 Static Definition A specification for a message structure intended to support the use case Based on a message defined in HL7 Std Defined at the message, segment, and field levels Follows the HL7 rules (chapter 2) May further constrain Identifies only those specific elements used in the exchange Removes all instances of optionality, defining explicitly Segments, segment groups, fields and components usage rules Cardinalities Value sets and coding systems Implementation notes

28. March 2005V2 Messaging Conformance28 of 122 Static Definition Example... NK1 MSH EVN PID NK1 PV1 PV2 OBX AL1 HL7 Message Structure... NK1 MSH EVN PID 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

29. March 2005V2 Messaging Conformance29 of 122 Dynamic Definition Defines interaction between the sender and receiver Acknowledgment mode supported Conditions under which an accept and/or application level acknowledgment is expected Always Never Only on success Only on error Interaction Model Defines specific interactions between the applications that support message profile communication requirements Includes interaction diagrams that illustrate the sequence of trigger event and resulting message flows between the sending and receiving applications Dynamic can refer one to many static definitions

30. March 2005V2 Messaging Conformance30 of 122 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

31. March 2005V2 Messaging Conformance31 of 122 How it all ties together

32. March 2005V2 Messaging Conformance32 of 122 Message Profiles Concepts and Constituents

33. March 2005V2 Messaging Conformance33 of 122 Profiling Concepts Profile Types HL7 Standard Constrainable Implementable Future type to allow for expected receiver behavior Generic term element used Segment groups Segments Fields Components Sub-components Cardinality Usage Message Constituents

34. March 2005V2 Messaging Conformance34 of 122 Profile Types HL7 Standard Profile represents a specific HL7 published standard creation and publication limited to HL7 use Constrainable May have optionality - not implementable Narrower profiles may be defined based on this Realm Specific (National, Regional, SIGs, etc.) Supplier / Consumer Specific Implementation Further constrained No optionality

35. March 2005V2 Messaging Conformance35 of 122 Cardinality Identifies minimum and maximum number of repetitions Special values for cardinality Minimum number of repetitions is 0, the element may be omitted from a message The maximum value may have no practical limit (In this case, it may be identified as *)

36. March 2005V2 Messaging Conformance36 of 122 Cardinality Examples Examples of common cardinality combinations are: Element Cardinality

37. March 2005V2 Messaging Conformance37 of 122 Usage The circumstances under which an element appears in a message Some elements must always be present others may never be present others may only be present in certain circumstances Rules governing the expected behavior of the sending and limited restrictions on the receiving application with respect to the element

38. March 2005V2 Messaging Conformance38 of 122 Usage (continued) R - Required A conforming sending application populate all R elements with a non-empty value A conforming receiving application process (save/print/archive/etc.) or ignore the information conveyed by required elements must not raise an error due to the presence of a required element, but may raise an error due to the absence of a required element For complete compatibility with HL7, any element designated as required in a standard HL7 message definition shall also be required in all HL7 Message Profiles of that standard message

39. March 2005V2 Messaging Conformance39 of 122 Usage (continued) RE - Required but may be empty May be missing from the message, but must be sent by the sending application if there is relevant data A conforming sending application must be capable of providing all RE element if it knows the required values for the element, then it must send that element if the conforming sending application does not know the required values, then element will be omitted A conforming receiving applications will be expected to process (save/print/archive/etc.) or ignore data contained in the element must be able to successfully process the message if the element is omitted (I.e. no error message should be generated because the element is missing

40. March 2005V2 Messaging Conformance40 of 122 Usage (continued) Optional This code indicates that the Usage for this element has not yet been defined May NOT be used in Implemention profiles (no-optionality profiles) Conformance cannot be tested on an Optional field

41. March 2005V2 Messaging Conformance41 of 122 Usage (continued) C - Conditional Predicate associated with this element that identifies the conditions under which the element must be present must be testable and based on other values within the message may be expressed as a mathematical expression or in text and may utilize operators such as equivalence, logical AND, logical OR and NOT The conforming sending and receiving applications shall both evaluate the predicate If the predicate is satisfied: See rules for R (Required) If the predicate is NOT satisfied: A conformant sending application must NOT send the element A conformant receiving application must NOT raise an error if the condition predicate is false and the element is not present, though it MAY raise an error if the element IS present

42. March 2005V2 Messaging Conformance42 of 122 Usage (continued) CE - Conditional but may be empty This usage also has an associated condition predicate similar to Conditional (C) If the predicate is satisfied: See rules for RE (Required but may be empty) If the predicate is not satisfied: The conformant sending application must NOT send the element The conformant receiving application MAY raise an application error if the element IS present X - Not supported Conformant sending applications will NOT send the element Conformant receiving applications MAY ignore the element if it IS present, or may raise an application error

43. March 2005V2 Messaging Conformance43 of 122 Optionality / Usage Relationship Conformance Usage codes are more specific than HL7 Optionality codes HL7 OptionalityAllowed Conformance UsageComment R - RequiredR O - OptionalR, RE, O*, C, CE, XO is only permitted for constrainable profiles C - ConditionalC, CE, R**, RE**** If satisfied by use case X – Not SupportedX B – Backward Compatibility R, RE, O*, C, CE, XO is only permitted for constrainable profiles W – WithdrawnX

44. March 2005V2 Messaging Conformance44 of 122 Usage / Cardinality Relationship Both Usage and Cardinality govern the appearance of a field in a message Cardinality constrained by the usage code If Required (R), the minimum and maximum cardinality for the element shall always be >= 1 If the usage of an element is not Required (R) (i.e. any code other than R), the minimum cardinality shall be 0 except in the following condition: where an element will not always be present but, when present, must have a minimum number of repetitions greater than one, this may be indicated by specifying –the non-required Usage code –the minimum cardinality representing the minimum number of repetitions when the element is present.

45. March 2005V2 Messaging Conformance45 of 122 Usage-Cardinality Combinations

46. March 2005V2 Messaging Conformance46 of 122 Usage Within Hierarchical Elements Messages are constructed using a hierarchy of elements At least one lower level element must be present for the higher level element to be considered to be present Adds an implicit conditional constraint on elements that enforce the presence of an element Places constraints on what combinations of usage codes may be used within a hierarchy

47. March 2005V2 Messaging Conformance47 of 122 Message Profiles Levels and Examples

48. March 2005V2 Messaging Conformance48 of 122 Message Level Profile Segment Definitions The set of segments and segment groups included within the message of an HL7 Message Profile shall be defined Any segments or segment groups that are required by HL7 shall be included Segment Usage Segment Cardinality Profile does not allow for empty segment HL7 abstract message syntax PLUS Usage Cardinality

49. March 2005V2 Messaging Conformance49 of 122 Message Level Profile Example

50. March 2005V2 Messaging Conformance50 of 122 Message Level Profile Example

51. March 2005V2 Messaging Conformance51 of 122 Segment Level Profile The set of fields of each instance of a segment within the Message Profile If a segment occurs multiple times, it may be represented by different segment profiles Field Usage Field Cardinality Null Syntax (tabular HL7 segment definitions) Length (updated) Usage (new column) Cardinality (new column)

52. March 2005V2 Messaging Conformance52 of 122 Segment Level Profile Example (PID)

53. March 2005V2 Messaging Conformance53 of 122 Field Level Profile Field definitions Each individual field is completely defined to eliminate any possible ambiguity If HL7 2.x field descriptions are not sufficient, a precise semantic definition shall be specified Exact allowed value set shall be specified Coded Values (ID and IS) HL7 tables (ID) may be extended User defined (IS) may be redefined and/or extended Coded Entry (CE, CF, CWE, and CNE) Composite Data (CM) types Appendix for 2.3.1 and 2.4 for XML encoding Deprecated and all CM fields are using new data types as of 2.5

54. March 2005V2 Messaging Conformance54 of 122 Proposed for v2.6 (in membership ballot) Annotations Implementations (from v2.5) Design Comments Other Vocabulary Definition (collection of tables) Constraints Textual and, optionally, Formal Testable Pattern Matching Element Relationships Condition Predicate (from v2.5)

55. March 2005V2 Messaging Conformance55 of 122 Profile Registration Tool Message Profile registration utility on the HL7 Members Page of the HL7 WWW (www.hl7.org/memonly/conformance)www.hl7.org/memonly/conformance Valid Conformance Documents (XML) Message Profile Identifier generated Repository of Message Profile Catalogue of Message Profile Users (future) application name and version contact person application role (whether the application sends or receives messages described by the profile) Search Capabilities

56. March 2005V2 Messaging Conformance56 of 122 Message Profile Identifier Uniquely identifies static and dynamic profile The static profile identifier is a means to uniquely identify a message profile, expressed as an ASN.1 Object Identifier (OID) The sending application uses the profile identifiers to determine the specific HL7 Message Profile to send Branch from ISO to HL7 and Message Profile 2.16.840.1.113883.9

57. March 2005V2 Messaging Conformance57 of 122 Message Profile Pub/Subscribe Topics SeqTopic Element NameValue 1Conformance SIG IDconfsig 2An organization identifierAbbreviated version of the organization name 3The HL7 versionRefer to HL7 Table 0104 - Version ID for valid valuesHL7 Table 0104 - Version ID 4Topic Typeprofile 5Accept AcknowledgementThe accept acknowledgement responsibilities.(refer to HL7 Table 0155 – Accept/application acknowledgment conditions for valid values)HL7 Table 0155 – Accept/application acknowledgment conditions 6Application AcknowledgementThe application acknowledgement responsibilities (refer to HL7 Table 0155 – Accept/application acknowledgment conditions for valid values) HL7 Table 0155 – Accept/application acknowledgment conditions 7Acknowledgement ModeDeferred or Immediate An example of message profile publish/subscribe topics: confSig-MyOrganization-2.4-profile-AL-NE-Immediate

58. March 2005V2 Messaging Conformance58 of 122 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 and/or publish/subscribe systems. Prior to v2.5, the field was called Conformance Statement ID. For backward compatibility, the Conformance Statement ID can be used here.

59. March 2005V2 Messaging Conformance59 of 122 Certification The process by which an applications conformance claim in verified against the actual application implementation Certification is a very important part of conformance Conducted by providers, national or regional health organizations Not conducted by HL7

60. March 2005V2 Messaging Conformance60 of 122 Verification (Validation) The process by which message instance(s) are verified against the message profile on which it is based Verification is a very important part of conformance Conducted by providers, national or regional health organizations Not conducted by HL7

61. March 2005V2 Messaging Conformance61 of 122 Australian Healthcare Messaging Laboratory (http://www.ahml.com.au)http://www.ahml.com.au

62. March 2005V2 Messaging Conformance62 of 122 Considerations Message profile is independent of message instance encoding - ER7/XML XML Message Instance It represents an XML document and it contains data and meta-data (tags) as described by its schema/DTD XML DTD/Schema Contains the rules (structure, content, data types, cardinality) for constructing and validating an XML document Version 2.xml specification from XML SIG (informative -> normative)

63. March 2005V2 Messaging Conformance63 of 122 Conformance Benefits Consistent Documentation Reuse of Specification Lower Cost of Integration Similar to Version 3 Conformance SIG is developing Implementation guide Chaos -> order Site Specific Profiles Supports specific needs Required of third-party application vendors RFP Simplifies introduction/acquisition of new applications

64. March 2005V2 Messaging Conformance64 of 122 Conformance Support in the HL7 Standard Version 2.4, 2.5, 2.6 MSH:21 Profile identifier OID data type for ASN.1 identifiers Conformance Section Implementation Guide Version 3 At the core of the Message Development Process Chapter 7 of HDF Implementation Guide

65. March 2005V2 Messaging Conformance65 of 122 Domain Use Case Profiled App Role1 Sends-------- -------- Receives -------- Role1 Sends-------- -------- Receives -------- Role1 Sends-------- -------- Receives -------- Role1 Sends-------- -------- Receives -------- Sends-------- -------- Receives -------- Application Profile Leaf-level Use Cases Analogous to V2.x Profiling Static Message Structures Interaction Model Use Case Model Version 3 Deliverables (for a given domain) HMD Version 3 Conformance (for a given application) Actors V3 Conformance

66. March 2005V2 Messaging Conformance66 of 122 Break

67. March 2005V2 Messaging Conformance67 of 122 Messaging Workbench What and Why

68. March 2005V2 Messaging Conformance68 of 122 The Messaging Workbench (MWB) For those who: Design HL7 2.x messages Manage specification repositories Collaborate on varied messaging projects within and outside of their organizations Free of charge from HL7 Web site (www.hl7.org)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

69. March 2005V2 Messaging Conformance69 of 122 Design Features - 1 Rapid prototyping of message profiles derived from standard libraries, from profile inheritance or from scratch Quick and easy alteration of existing profiles to meet new requirements Design time comparison of profiles on an element by element basis Linkage of data elements or constants to message elements for a more complete specification

70. March 2005V2 Messaging Conformance70 of 122 Design Features - 2 Tools for storage and retrieval of profiles as well as updating and customizing message element libraries The ability to capture and analyze ER7 messages Capability to reverse engineer specifications from captured messages. A suite of reports that document specifications and produce example messages in text, xml and html formats Additional style sheets available for PDF

71. March 2005V2 Messaging Conformance71 of 122 HL7

72. March 2005V2 Messaging Conformance72 of 122 Constrainable

73. March 2005V2 Messaging Conformance73 of 122 Constrainable (continued)

74. March 2005V2 Messaging Conformance74 of 122 Implementation

75. March 2005V2 Messaging Conformance75 of 122 Message Profile

76. March 2005V2 Messaging Conformance76 of 122 Messaging Workbench Features and Use

77. March 2005V2 Messaging Conformance77 of 122 Capture/Analyze Message

78. March 2005V2 Messaging Conformance78 of 122 Reverse Engineer from Message

79. March 2005V2 Messaging Conformance79 of 122 New Profile Using Libraries

80. March 2005V2 Messaging Conformance80 of 122 New Profile Using Libraries (contd)

81. March 2005V2 Messaging Conformance81 of 122 New Profile Using Libraries (contd)

82. March 2005V2 Messaging Conformance82 of 122 New Profile Using Libraries (contd)

83. March 2005V2 Messaging Conformance83 of 122 New Profile Using Libraries (contd)

84. March 2005V2 Messaging Conformance84 of 122 New Profile using copy/paste

85. March 2005V2 Messaging Conformance85 of 122 New Profile Copy/Paste (contd)

86. March 2005V2 Messaging Conformance86 of 122 New Profile Copy/Paste (contd)

87. March 2005V2 Messaging Conformance87 of 122 Modifying a Profile – HL7

88. March 2005V2 Messaging Conformance88 of 122 Modifying a Profile – Constrainable

89. March 2005V2 Messaging Conformance89 of 122 Modifying Profile – Constr (contd)

90. March 2005V2 Messaging Conformance90 of 122 Modifying Profile – Implementation

91. March 2005V2 Messaging Conformance91 of 122 Modifying Profile – Impl (contd)

92. March 2005V2 Messaging Conformance92 of 122 Diagram Drawing Tool

93. March 2005V2 Messaging Conformance93 of 122 Messaging Workbench Reports and Examples

94. March 2005V2 Messaging Conformance94 of 122 Reports

95. March 2005V2 Messaging Conformance95 of 122 Reports (continued)

96. March 2005V2 Messaging Conformance96 of 122 Reports (continued)

97. March 2005V2 Messaging Conformance97 of 122 Reports (continued)

98. March 2005V2 Messaging Conformance98 of 122 Reports (continued)

99. March 2005V2 Messaging Conformance99 of 122 Reports (continued)

100. March 2005V2 Messaging Conformance100 of 122 Producing Profile Reports

101. March 2005V2 Messaging Conformance101 of 122 Producing Profile Reports (contd)

102. March 2005V2 Messaging Conformance102 of 122 Producing Profile Reports (contd)

103. March 2005V2 Messaging Conformance103 of 122 Producing Profile Reports (contd) Browser View

104. March 2005V2 Messaging Conformance104 of 122 Producing Profile Reports (contd)

105. March 2005V2 Messaging Conformance105 of 122 HL7 Message Profile

106. March 2005V2 Messaging Conformance106 of 122 Register Profile with HL7

107. March 2005V2 Messaging Conformance107 of 122 Messaging Workbench Contacts and Help

108. March 2005V2 Messaging Conformance108 of 122 MWB Contacts The Conformance SIG is interested in your feedback and suggestions for improvement of the tool Conformance SIG list server is a good source for general information about the tool and for making improvement suggestions For specific questions you may also contact Pete Rontey via Email at peter.rontey@med.va.gov

109. March 2005V2 Messaging Conformance109 of 122 Where to Get More Information MWB On-line help

110. March 2005V2 Messaging Conformance110 of 122 Where to Get More Info (contd) MWB On-line help (contd)

111. March 2005V2 Messaging Conformance111 of 122 Where to Get More Info (cont) MWB Updates/Downloads

112. March 2005V2 Messaging Conformance112 of 122 Where to Get More Info (contd) Conformance Tools Forum at Yahoo Groups

113. California Department of Health Services Electronic Laboratory Reporting Project

114. March 2005V2 Messaging Conformance114 of 122 California Electronic Laboratory Reporting System

115. March 2005V2 Messaging Conformance115 of 122 Inbound Message ProcessingOutbound Message Processing Data Persistence Business Intelligence Functional Areas of the CA-ELR System

116. March 2005V2 Messaging Conformance116 of 122 California Electronic Laboratory Reporting System 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 Respository 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

117. March 2005V2 Messaging Conformance117 of 122 Message Profiles Describe message structure and anticipated application behavior Identify required, optional, and conditional message elements Identify coding systems or value-sets for coded elements Enable message validation, transformation, and persistence Are essential for achieving system-to-system interoperability

118. March 2005V2 Messaging Conformance118 of 122 Message-Level Profile Which Segments are Supported? Which Segments are Required? How are Segments Grouped? What is the order of Segments and Segment groups Which Segments/Segment Groups are repeatable? What is the cardinality of repeating segments/segment Groups?

119. March 2005V2 Messaging Conformance119 of 122 Segment-Level Profile Which Fields are Supported? Which Fields are Required? What is the order of fields within the segment? What is the datatype of each field? Which fields are repeatable? What is the cardinality of repeating fields? What maximum field length is supported? What value tables are associated with the field?

120. March 2005V2 Messaging Conformance120 of 122 Field-Level Profile Which Field components are supported? Which Field components are Required? What is the order of components within a field? What is the datatype of each field component? Which fields components are repeatable? What is the cardinality of repeating fields components? What maximum length is supported for field components? What value tables are associated with the field components?

121. March 2005V2 Messaging Conformance121 of 122 Questions / Discussion / Feedback

122. March 2005V2 Messaging Conformance122 of 122 Thank You Abdul-Malik Shakir Principal Consultant Shakir Consulting 1911 Foothill Blvd., Suite 148 La Verne, CA 91750 Office: (909) 596-6790 Mobile: (626) 644-4491 Email: AbdulMalik@ShakirConsulting.com