Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Introduction to hl7 v2

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 211 Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (18)

Publicité

Similaire à Introduction to hl7 v2 (20)

Publicité

Plus récents (20)

Introduction to hl7 v2

  1. 1. July 13, 2015 Page: 1 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner July 13, 2015 Introductions and Course Overview
  2. 2. July 13, 2015 Page: 2 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SESSION OVERVIEW • ABOUT ME • SCOPE AND LEARNING OBJECTIVES • ABOUT YOU • COURSE SYLLABUS • COURSE MATERIALS • Q&A
  3. 3. July 13, 2015 Page: 3 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner About Me • I have been, and continue to be, an active member of HL7 since 1991. • I currently co-chair the HL7 Modeling and Methodology Workgroup. • My HL7 History: o Chaired the HL7 Education Workgroup from 1996 to 2010. o Received the HL7 volunteer of the year award in 1997 o Served on the HL7 Board of Directors from 2000 to 2005 o Board appointed member of the HL7 ARB since 2001and ARB modeling facilitator since 2012 o Received the HL7 Fellowship award in 2012 AbdulMalik Shakir President and Chief Informatics Scientist Hi3 Solutions | your healthcare standards conformance partner 3500 West Olive Ave, Suite # 300, Burbank, CA 91505.
  4. 4. July 13, 2015 Page: 4 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Scope and Learning Objectives • Scope - an introduction to HL7’s health information exchange standards:  HL7 Family of Standards  HL7 v2 Messaging (v2)  HL7 v3 Messaging (v3)  HL7 v3 Clinical Document Architecture (CDA)  HL7 Compliance and Conformance Specification • Learning Objectives –  To better understand the business case for HL7,  Gain familiarity with the full suite of HL7 standards,  Receive an in-depth overview of the HL7 information exchange standards
  5. 5. July 13, 2015 Page: 5 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner About You: Show of Hands Please  Information Systems / Information Technology  Healthcare Information System Data / Databases  Health System Interface / Information Exchange  Health Level Seven (HL7)  Health Level Seven v2  Health Level Seven v3  Clinical Document Architecture
  6. 6. July 13, 2015 Page: 6 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Course Topics HL7 v2 Messaging HL7 v3 Messaging HL7 Clinical Document Architecture HL7 Family of Standards HL7 Compliance and Conformance
  7. 7. July 13, 2015 Page: 7 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Course Agenda July 13, 2015 July 14, 2015  09:00 – 09:30 Introductions and Course Overview  09:30 – 10:30 Health Level Seven and the HL7 Family of Standards  10:30 – 10:45 Break  10:45 – 12:00 HL7 v2 Abstract Message Definition  12:00 - 12:30 Break  12:30 – 02:00 HL7 v2 Message Construction Rules  02:00 - 02:15 Break  02:15 – 03:30 Local Extensions and inter-version Compatibility  03:30 – 04:00 HL7 v2 Retrospective  09:00 – 09:30 HL7 v3 History and Rationale  09:30 – 10:30 HL7 v3 Development Frameworks and Architectures  10:30 – 10:45 Break  10:45 – 12:00 HL7 v3 Messaging Artifacts  12:00 - 12:30 Break  12:30 – 02:00 HL7 v3 Clinical Document Architecture  02:00 - 02:15 Break  02:15 – 03:30 HL7 Standards Compliance and Profile Conformance  03:30 – 04:00 HL7 v3 Retrospective
  8. 8. July 13, 2015 Page: 8 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Course Materials https://drive.google.com/folderview?id=0B- 3JvLjUn5CCfk84VzNqZFY5U2NCbV95WHNNWGp0QWFIWDhZcGh1NzVnVUptZEZvNTlxYkE&usp=sharing
  9. 9. July 13, 2015 Page: 9 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Questions
  10. 10. July 13, 2015 Page: 10 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Hi3 Solutions 3500 W. Olive Ave, Suite 300 Burbank, CA 91505 ww.hi3solutions.com +1 800 918- 6520
  11. 11. July 13, 2015 Page: 11 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner July 13, 2015 Health Level Seven (HL7) and the HL7 Family of Standards
  12. 12. July 13, 2015 Page: 12 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SESSION OVERVIEW • HEALTH INFORMATION EXCHANGE STANDARDS • HISTORY OF HEALTH LEVEL SEVEN • HL7 FAMILY OF STANDARDS • HL7 HEALTH INFORMATION EXCHANGE STANDARDS • SESSION RETROSPECTIVE
  13. 13. July 13, 2015 Page: 13 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Electronic Health Information Exchange PharmaciesPhysicians Testing Organizations Lab/Images Hospitals Payors Employers County/Community Entities Patients/Consumers Government Medicare/Medicaid Lab results Patient Data Orders Results Images Eligibility Referral Process Claim Status Claims/Prescriptions Referral Process Claim/Status Health Information Insurance Updates Eligibility Medical Records Enrollment Mental Health Family Planning Medical Society Public Health
  14. 14. July 13, 2015 Page: 14 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Health Information Exchange Effective, meaningful health information exchange requires that all parties involved in information exchange adhere to predetermined transaction formats, usage constraints, and encoding rules.
  15. 15. July 13, 2015 Page: 15 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Healthcare Information System HL7 HL7 HL7, X12N HL7, X12N HL7 HL7 DICOM IEEE MIB, ASTM X12N / HL7 (Non-US only) X12N NCPDP Healthcare Data Interchange Standards
  16. 16. July 13, 2015 Page: 16 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Leading U.S. Healthcare Data Interchange SDOs IEEE Institute of Electrical and Electronic Engineers NCPDP National Council for Prescription Drug Programs X12N Insurance Subcommittee of X12 ASTM American Society for Testing and Materials DICOM Digital Imaging and Communications in Medicine HL7 Health Level Seven
  17. 17. July 13, 2015 Page: 17 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner IEEE Instrumentation communication standards and generalized information interchange standards NCPDP Standards for communication of prescription, billing, and other pharmacy material X12N Standards for exchange of healthcare insurance and billing information ASTM Lab reporting standards and standard guide for content and structure of computer-based patient records DICOM Standards for exchanging digital radiology images HL7 Inter-application interoperability standards for healthcare Leading U.S. Healthcare Data Interchange SDOs
  18. 18. July 13, 2015 Page: 18 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 and X12N  HL7 and X12N are standards development organizations accredited by the American National Standards Institute (ANSI).  Each organization adheres to a strict and well-defined set of operating procedures that ensures consensus, openness and balance of interest.  HL7 develops standards that enable disparate healthcare applications to exchange key sets of clinical and administrative data.  X12N develops specification that enable the electronic interchange of healthcare insurance and claims processing data. HL7 Clinical / Administrative X12N Insurance / Billing
  19. 19. July 13, 2015 Page: 19 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner An X12N Data Interchange Scenario User Interface Program Module Dataset Outbound Transformation Inbound Transformation User Interface Program Module Dataset Outbound Transformation Inbound Transformation B to A Transformation A to B Transformation Patient Billing Application System Claims Processing Application System Patient Billing Application System Claims Processing Application System
  20. 20. July 13, 2015 Page: 20 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner User Interface Program Module Dataset Outbound Transformation Inbound Transformation User Interface Program Module Dataset Outbound Transformation Inbound Transformation B to A Transformation A to B Transformation Order Entry Application System Laboratory Application System Order Entry Application System Laboratory Application System An HL7 Data Interchange Scenario
  21. 21. July 13, 2015 Page: 21 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Reaching the Limits of Application Interfaces Lab Order Entry ADT Pharmacy Radiology Decision Support Electronic Health Record Administrative Systems ? Enterprise Systems ? External Systems ?
  22. 22. July 13, 2015 Page: 22 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HIE Standards: 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 standard increase rapidly with the number of systems involved.
  23. 23. July 13, 2015 Page: 23 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner 2 3 4 5 6 7 8 9 10 11 12 13 14 15 W/O HL7 1 3 6 10 15 21 28 36 45 55 66 78 91 105 With HL7 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 20 40 60 80 100 120 Interfaces Nodes Interfaces Requirements With STD W/O STD HIE Standards: Why Tolerable Painful Intolerable
  24. 24. July 13, 2015 Page: 24 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner User Interface Program Module Dataset Outbound Transformation Inbound Transformation User Interface Program Module Dataset Outbound Transformation Inbound Transformation B to A Transformation A to B Transformation Order Entry Application System Laboratory Application System Order Entry Application System Laboratory Application System An HL7 Data Interchange Scenario
  25. 25. July 13, 2015 Page: 25 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner History of Health Level Seven
  26. 26. July 13, 2015 Page: 26 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner  Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited standards developing organization founded in 1987, dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.  HL7's 2,300+ members include approximately 500 corporate members who represent more than 90% of the information systems vendors serving healthcare.
  27. 27. July 13, 2015 Page: 27 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner 7 Application What does “HL7” stand for? “Level Seven” refers to the highest level of the International Standards Organization’s (ISO) communication model for Open Systems Interconnection (OSI) - the application level. ISO-OSI Communication Architecture Model 1 Physical 2 Data Link 3 Network 4 Transport Communication 5 Session 6 PresentationFunction
  28. 28. July 13, 2015 Page: 28 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner EARLY HISTORY OF HEALTH LEVEL SEVEN • The HL7 Working Group has met approximately every three to four months since March 1987. • In the initial three meetings, a Version 1.0 draft Standard was prepared covering the overall structure of the interfaces, ADT, order entry, and display-oriented queries. • HL7 v.1 was only used for a proof of concept implementation and served to define the content and structure of the standard. This draft was presented to a plenary meeting of the overall group in Tyson’s Corner, VA, on October 8, 1987. • Version 2.0, included billing; it was prepared subsequent to Plenary I in Tyson’s Corner and presented at Plenary II in Tucson, AZ in September 1988. • Although targeted to be the first release for actual use in production, HL7 2.0 served primarily to permit the implementation of a demonstration of the standard and was implemented in only a few settings. • Version 2.1 was published in June 1990, and included laboratory results reporting based on the ASTM E1238 specification. Source: http://www.ringholm.com/docs/the_early_history_of_health_level_7_HL7.htm
  29. 29. July 13, 2015 Page: 29 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Implications of ANSI Accreditation • Health Level Seven is a Standards Development Organization (SDO) accredited by the American National Standards Institute (ANSI). • Such accreditation, coupled with HL7’s own procedures, dictates that any standard that is published by HL7 and submitted to ANSI for approval be developed and ratified by a process that adheres to ANSI’s procedures for open consensus (www.ANSI.org). • Two of the most important components of these procedures are openness and balance of interest. • Openness means that anyone who is materially affected by the proposed standard must be allowed to participate in its development and/or the process by which it is ratified (voting). • Membership within HL7 cannot be a criterion for this participation, although ANSI allows standards developing organizations to charge an administrative participation fee to non-members who wish to participate.
  30. 30. July 13, 2015 Page: 30 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 Board () and Workgroup Committees  Architectural Review Board • Arden Syntax • Attachments • CCOW • Clinical Decision Support • Clinical Genomics • Clinical Guidelines  Clinical Research Outreach Committee • Community Based Health Services • Conformance • Control/Query  Education • Electronic Health Records • Financial Management • Government Project • Imaging Integration  Implementation  International Affiliates • Java • Laboratory • Laboratory, Automated, and Testing  Marketing • Medical Records/Information Management • Medication • Modeling and Methodology • Orders/Observations  Organization Review Committee • Patient Administration • Patient Care • Patient Safety • Pediatric Data Standards • Personnel Management  Process Improvement  Publishing • Regulated Clinical Research Information Mgmt. • Scheduling and Logistics • Security and Accountability • Structured Documents  Technical Steering Committee • Template • Vocabulary • XML
  31. 31. July 13, 2015 Page: 31 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 International Affiliates April 08, 2009Informatics Standards & Interoperability31 of 55 Canada New Zealand Finland Germany Netherlands Japan United States United Kingdom India Taiwan China Czech Republic Mexico France Argentina Brazil Australia Denmark Greece Ireland Italy Spain Sweden Switzerland South Korea Turkey Uruguay Singapore Romania CroatiaAustriaColombia Chile Puerto Rico Russia Pakistan Bosnia and Herzegovina
  32. 32. July 13, 2015 Page: 32 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner 32 HL7 Membership •Worldwide •1800 organizations and1000+ individuals Europe 45% Asia/Oceania 15% North America 32% Other 8% 2007 figures. Based on the “average 3 individuals per org rule”
  33. 33. July 13, 2015 Page: 33 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner 33 Membership Location 2007 figures. Based on the “average 3 individuals per org rule”
  34. 34. July 13, 2015 Page: 34 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 Family of Standards
  35. 35. July 13, 2015 Page: 35 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 Family of Standards • Fast Healthcare Interoperability Resources Specification (FHIR) FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and CDA® productlines while leveraging the latest web standards and applying a tight focus on implementation FHIR solutions are built from a set of modular componentscalled “Resources”. These resources can be easily assembled into working systems that solve real world clinical and administrative problems. • Clinical Document Architecture The HL7 Version 3 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. A CDA can contain any type of clinical content -- typical CDA documents would be a Discharge Summary, Imaging Report, Admission & Physical, Pathology Report and more. The most popular use is for inter-enterprise information exchange, such as is envisioned for a US Health Information Exchange. • Electronic Health Record System Functional Model The HL7 International EHR System Functional Model (EHR-S FM) outlines important features and functions that should be contained in an EHR system. Through the creation of functional profiles, this model provides a standard description and common understanding of functionsfor healthcare settings. HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health andvital statistic reporting. • Service Oriented Architecture The Services Oriented Architecture supports the HL7 mission to promote and create standards by identifying common architectural "services" and their behaviors. The SOA WG produces Service Functional Models (SFMs), implementation guides, and educational materials. Additionally, the workgroup will explore the implications of emerging technologies (such as Cloud computing and advanced distributed systems) for health-related environments. • Context Management Architecture Aimed at facilitating the integration of applications at the point of use, CCOW Context Management Specification is a standard for both internal applications programming and runtime environment infrastructure. By synchronizing and coordinating applications to automatically follow the patient, user, and other contexts, CCOW serves as the basis for ensuring secure and consistent access to patient information from heterogeneous sources. • HL7 Version 3 Product Suite Health Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It includesstandards for communications that document and manage the care and treatment of patients in a wide variety of healthcare settings. Version3 represents a new approach to clinical information exchange based on a model driven methodology that produces messages and electronic documentsexpressed in XML syntax. • HL7 Version 2 Product Suite HL7’s Version 2.x (V2) messaging standard is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world. This messaging standard allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems.
  36. 36. July 13, 2015 Page: 36 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 Family of Standards • Fast Healthcare Interoperability Resources Specification (FHIR) FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and CDA® productlines while leveraging the latest web standards and applying a tight focus on implementation FHIR solutions are built from a set of modular componentscalled “Resources”. These resources can be easily assembled into working systems that solve real world clinical and administrative problems.  Clinical Document Architecture The HL7 Version 3 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. A CDA can contain any type of clinical content -- typical CDA documents would be a Discharge Summary, Imaging Report, Admission & Physical, Pathology Report and more. The most popular use is for inter-enterprise information exchange, such as is envisioned for a US Health Information Exchange. • Electronic Health Record System Functional Model The HL7 International EHR System Functional Model (EHR-S FM) outlines important features and functions that should be contained in an EHR system. Through the creation of functional profiles, this model provides a standard description and common understanding of functionsfor healthcare settings. HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health andvital statistic reporting. • Service Oriented Architecture The Services Oriented Architecture supports the HL7 mission to promote and create standards by identifying common architectural "services" and their behaviors. The SOA WG produces Service Functional Models (SFMs), implementation guides, and educational materials. Additionally, the workgroup will explore the implications of emerging technologies (such as Cloud computing and advanced distributed systems) for health-related environments. • Context Management Architecture Aimed at facilitating the integration of applications at the point of use, CCOW Context Management Specification is a standard for both internal applications programming and runtime environment infrastructure. By synchronizing and coordinating applications to automatically follow the patient, user, and other contexts, CCOW serves as the basis for ensuring secure and consistent access to patient information from heterogeneous sources.  HL7 Version 3 Product Suite Health Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It includesstandards for communications that document and manage the care and treatment of patients in a wide variety of healthcare settings. Version3 represents a new approach to clinical information exchange based on a model driven methodology that produces messages and electronic documentsexpressed in XML syntax.  HL7 Version 2 Product Suite HL7’s Version 2.x (V2) messaging standard is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world. This messaging standard allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems.
  37. 37. July 13, 2015 Page: 37 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Aimed at facilitating the integration of applications at the point of use, CCOW Context Management Architecture is a standard for both internal applications programming and runtime environment infrastructure. By synchronizing and coordinating applications to automatically follow the patient, user, and other contexts, CCOW serves as the basis for ensuring secure and consistent access to patient information from heterogeneous sources. HL7 Context Management Architecture
  38. 38. July 13, 2015 Page: 38 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Context Management Architecture (CMA) • The Health Level Seven Context Management Architecture (CMA) enables multiple applications to be automatically coordinated and synchronized in clinically meaningful ways at the point-of-use. • The CMA establishes the basis for bringing interoperability among healthcare applications to the point-of-use, such as the clinical desktop. • Clinical context is state information that a user establishes and modifies while interacting with healthcare applications at the point- of-use (e.g., a clinical desktop). • The context is common because it establishes parameters that should uniformly affect the behavior or operation of multiple healthcare applications. • The context needs to be managed so that the user has a way of controlling it, and so that applications have a way of robustly coordinating their behavior as the context changes.
  39. 39. July 13, 2015 Page: 39 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Context Management Architecture (CMA) • The CMA defines the interfaces between applications, known as context participants, and a coordinating component, known as the context manager. • Applications that share a common context with each other, and the context manager that mediates the applications, are collectively referred to as a common context system. • The data that defines the common clinical context for a common context system resides in the context manager. The data is organized as a set of name/value pairs that are grouped by context subject. • When the user performs an application gesture that instructs the application to change the common clinical context the application starts a context change transaction. • When the application that instigated the transaction has completed its changes to the context data, the context manager conducts a two-phase process to coordinate the propagation of the context changes to the other applications.
  40. 40. July 13, 2015 Page: 40 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Context Management Architecture (CMA)  In the first phase, the context manager surveys the other applications to determine which ones can apply the new context, and which ones either cannot, or prefer not to.  The context manager informs the instigating application of the survey results.  If all of the applications are willing to apply the new context, then they are all instructed to do so.  If at least one of the surveyed applications is blocked (“busy”) or prefers to keep the previous context, then the user is asked by the instigating application to decide how to proceed.  The context manager broadcasts the decision to all of the context participants to complete the second phase of the transaction.  This approach ensures that the link among application is never broken unless the user has performed an explicit gesture instructing that the link be broken.
  41. 41. July 13, 2015 Page: 41 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner The Services Oriented Architecture supports the HL7 mission to promote and create standards by identifying common architectural "services" and their behaviors. The SOA WG produces Service Functional Models (SFMs), implementation guides, and educational materials. Additionally, the workgroup explores the implications of emerging technologies (such as Cloud computing and advanced distributed systems) for health-related environments. HL7 Service Oriented Architecture
  42. 42. July 13, 2015 Page: 42 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HSSP: Healthcare Services Specification Program (HL7 SOA WG and OMG HDTF) • Joint HL7-OMG effort to define standard healthcare services o HL7 does logical/functional/business model, OMG does technical implementation through RFP process • Current specifications: o Entity Identification (EIS) o Record Locate and Update (RLUS) o Common Terminology (CTS II) o Decision Support (DSS) • Defined a methodology framework and specification template.
  43. 43. July 13, 2015 Page: 43 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner What is Service Oriented Architecture • SOA is an architecture that enables business agility through the use of common services. o Services are independent, self-contained, reusable business functions (such as eligibility checking) or infrastructure functions (such as security) o Services can be combined and orchestrated to automate complex business processes o Important aspects for SOA are:  Semantics (models of process, service, information and relationships)  Behavior and mindset of business and IT staff  Clear processes, roles and responsibilities  Explicit interaction/interface specifications and contracts  Governance of Services
  44. 44. July 13, 2015 Page: 44 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Benefits of SOA • Business related benefits of SOA: o Responsiveness - to meet market demands for increased service levels o Adaptability - Process changes with minimal complexity and effort, saving time and money o Business-IT Alignment - Application services aligned with business activities and business strategy. o B2B opportunities arise and interactions are cheaper and quicker to set up. o Shared Services - cost less to maintain and enable focus on improving quality. o Consistency – Enables increased consistency of business-processes. • IT benefits of SOA o Reuse - More efficient development and delivery through reuse of shared services. o Cost Reduction - Maintenance and integration. o Cheaper and easier to implement - Can use standard, inexpensive (free?) tooling o Speed of Delivery - quicker and easier than traditional mechanisms. o Risk Reduction – Risk is reduced through modular, incremental implementation. o Reduced Error Rates – through reuse of existing services.
  45. 45. July 13, 2015 Page: 45 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner The HL7 International EHR System Functional Model (EHR-S FM) outlines important features and functions that should be contained in an EHR system. Through the creation of functional profiles, this model provides a standard description and common understanding of functions for healthcare settings. HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health and vital statistic reporting. HL7 Electronic Health Record System Functional Model
  46. 46. July 13, 2015 Page: 46 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Electronic Health Record System (EHR-S) • The HL7 EHR System Functional Model and Standard DSTU provides a reference list of functions that may be present in an Electronic Health Record System (EHR-S), from a user perspective, to enable consistent expression of system functionality. • This EHR-S Model, through the creation of Profiles, enables a standardized description and common understanding of functions sought or available in a given setting. • The EHR-S Functional Model promotes a common understanding of individual EHR-S functions and serves the following purposes: o A communication link between EHR-S functions and end user defined benefits such as patient safety, quality outcomes and cost efficiencies. o A common understanding, and eventually, conformance measures of EHR functions upon which developers, vendors, users and other interested parties can plan and evaluate EHR-S functions. o The necessary framework to drive the requirements and applications of next level standards, such as EHR content, coding, information models, constructs and interoperability. o A standards-based method by which each realm can apply these EHR functions to its individually defined care settings and priorities.
  47. 47. July 13, 2015 Page: 47 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Building the foundation of the EHR Standard EHR Functional Model
  48. 48. July 13, 2015 Page: 48 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Care Settings define the environment of care in which the functions are applied within the EHR. (Realm Specific) Priorities represent the requirements for each function to be applied, in time, for the EHR based on care setting and realm. EHR Functional Model :: Defined Functions are the prime elements of the EHR Standard. There are three “groupings” of functions.
  49. 49. July 13, 2015 Page: 49 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and CDA® product lines while leveraging the latest web standards and applying a tight focus on implementation FHIR solutions are built from a set of modular components called “Resources”. These resources can be easily assembled into working systems that solve real world clinical and administrative problems. Fast Healthcare Interoperability Resources Specification (FHIR)
  50. 50. July 13, 2015 Page: 50 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Introduction  Fast Health Interoperability Resources is HL7’s most recent standards framework. It combines the best features of HL7’s v2, v3, and CDA product lines. FHIR leverages web standards and applies a tight focus on implementation concerns.  FHIR solutions are built from a set of modular components called “Resources”. These resources can be assembled into data objects and services that solve clinical and administrative problems.  FHIR leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications. FHIR has built- in mechanisms for traceability to the HL7 RIM and other important content models.
  51. 51. July 13, 2015 Page: 51 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner FHIR DSTU
  52. 52. July 13, 2015 Page: 52 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner DSTU Resource List
  53. 53. July 13, 2015 Page: 53 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Resource anatomy  Resources have 3 parts Defined Structured Data Extensions Narrative
  54. 54. July 13, 2015 Page: 54 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Human Readable Summary Standard Data Content:  MRN  Name  Gender  Date of Birth  Provider Extension with reference to its definition
  55. 55. July 13, 2015 Page: 55 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Resource elements  Resources are defined as an XML structure  Hierarchy of elements  Each element has  Name  Either a datatype or nested elements  Cardinality  All collections are nested in a containing element  Definition  RIM mapping  But instances in XML or JSON
  56. 56. July 13, 2015 Page: 56 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner  HL7’s Version 2.x (V2) messaging standard is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world. This messaging standard allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. • HL7 Version 2 Messaging  The HL7 Version 3 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. A CDA can contain any type of clinical content -- typical CDA documents would be a Discharge Summary, Imaging Report, Admission & Physical, Pathology Report and more. The most popular use is for inter-enterprise information exchange, such as is envisioned for a US Health Information Exchang • HL7 v3 Clinical Document Architecture  Health Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It includes standards for communications that document and manage the care and treatment of patients in a wide variety of healthcare settings. Version 3 represents a new approach to clinical information exchange based on a model driven methodology that produces messages and electronic documents expressed in XML syntax. • HL7 Version 3 Messaging HL7 Health Information Exchange Standards
  57. 57. July 13, 2015 Page: 57 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SESSION RETROSPECTIVE • HISTORY OF HEALTH LEVEL SEVEN • IMPLICATIONS OF ANSI ACCREDITATION • HL7 BOARD AND WORKGROUP COMMITTEES • HL7 AFFILIATES • HL7 FAMILY OF STANDARDS
  58. 58. July 13, 2015 Page: 58 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Questions
  59. 59. July 13, 2015 Page: 59 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Hi3 Solutions 3500 W. Olive Ave, Suite 300 Burbank, CA 91505 ww.hi3solutions.com +1 800 918- 6520
  60. 60. July 13, 2015 Page: 60 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner July 13, 2015 HL7 v2 Abstract Message Definition
  61. 61. July 13, 2015 Page: 61 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SESSION OVERVIEW • Abstract Message Definition • Message Elements • Abstract Message Syntax • MESSAGE SEGMENT DEFINITION • SEGMENT FIELD SEQUENCE • SEGMENT FIELD LENGTH • HL7 V2 DATATYPES • OPTIONALITY AND REPETITION • VALUE SET TABLES • DATA ELEMENTS
  62. 62. July 13, 2015 Page: 62 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 Messaging Standard: What  HL7 v2 messaging standards - the Application Protocol for Electronic Data Exchange in Healthcare Environments - enable disparate healthcare applications to exchange clinical and administrative data.  The standard defines the data content and provides the layout of messages that are exchanged between applications based upon a particular trigger event.  A message is comprised of an ordered collection of segments. A segment is an ordered collection of data elements (Fields, Datatype Components, and Datatype Subcomponents).  The HL7 v2 standard specifies which data elements are to be sent, the data type and suggested length of each, and indicates whether the data element is required or optional and whether it may repeat.
  63. 63. July 13, 2015 Page: 63 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Divide and Conquer / Component Reuse DATA Next of Kin (NK1) Insurance (IN1) Patient Visit (PV1) Patient Demographics (PID) Guarantor (GT1) NK1 IN1 PV1 PID GT1 OBR OBX Next of KIN (NK1) Patient Visit (PV1) Patient Demographics (PID)
  64. 64. July 13, 2015 Page: 64 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner 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.
  65. 65. July 13, 2015 Page: 65 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner 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 an instance of 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.
  66. 66. July 13, 2015 Page: 66 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 v2 Message Elements Message Specification Segment Group Message Segment Segment Segment Field Data Element Data Type Composite Data Type Data Type Component Code Table Code Table Item Code System Term Code System
  67. 67. July 13, 2015 Page: 67 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Abstract Message Definition - Syntax Annotation sets cardinality: • XYZ means 1 to 1 • [XYZ] means 0 to 1 • {XYZ} means 1 to many • [{XYZ}] means 0 to many 3-character code identifies the segment [ ] means the segment or group is optional { } means the segment or group may repeat <OBR|RQD|RQ1> < > choice of segments separated by “|”
  68. 68. July 13, 2015 Page: 68 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Exercise – Abstract Message Definitions  Given the following definition –  MSH, EVN, PID, [{NK1}], PV1, [PV2], [AL1]  How many PV2 segments are allowed?  Is a message which does not contain an AL1 segment compliant?  How many NK1 segments are allowed?  Are the following message instances compliant?  MSH, EVN, PID, PV1  MSH, EVN, PD1, PV2, AL1  EVN, MSH, PID, PV1, PV2  MSH, EVN, NK1, PV1, AL1  Missing non-optional segments PID and PVI  Includes all non-optional segments, but in the wrong order  Missing non-optional PID segment
  69. 69. July 13, 2015 Page: 69 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 v2 Message Segments and Segment Groups Message Specification Segment Group Message Segment Segment Segment Field Data Element Data Type Composite Data Type Data Type Component Code Table Code Table Item Code System Term Code System  An HL7 v2 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.
  70. 70. July 13, 2015 Page: 70 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Groups  Logical grouping of segments containing more than one type of segment. A segment group might be required or optional and might be repeating or non- repeating.  The first segment in a segment group is always required; this helps ensure that message instances can be unambiguously parsed. This required first segment is known as the anchor segment.  Which of the following segment groups are valid:  MSH, {PID, [NK1]}, OBX…  MSH, [PID, [NK1]], OBX…  MSH, {[PID],NK1}, OBX…  Valid Required Repeating Group  Valid Optional Non-Repeating Group  Invalid, Optional Anchor Segment (PID)
  71. 71. July 13, 2015 Page: 71 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Exercise – Abstract Message Definitions  Create an abstract message definition for which all of the following are valid:  MSH, EVN, PID, PV1, PV2  MSH, EVN, PID, PV1, PV2, AL1  MSH, EVN, PID, PD1, NK1, NK1, PV1, PV2, AL1  MSH, EVN, PID, AL1  MSH, EVN, PID, PD1, NK1  MSH, EVN, PID, [PD1], [{NK1}], [PV1], [PV2], [AL1]  MSH, EVN, PID, [PD1], [{NK1}], [PV1, PV2], [AL1]  MSH, EVN, PID, [PD1, {NK1}], [PV1, PV2], [AL1]
  72. 72. July 13, 2015 Page: 72 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Groups  Segment Groups may be nested  Groups of groups...  How many segment groups are there in the following?  {OBR, [NTE], [{OBX, [{NTE}]}]}  {OBR, [NTE], [{OBX, [{NTE}]}]}  Repeating Group 1 = OBR (1..1), NTE (0..1), Group 2 (0..*)  Nested Optional Repeating Group 2 = OBX (1..1), NTE (0..*)  A segment group is assigned a name that is used as an identifier.  { --- Group 1  OBR  [NTE]  [{ --- Group 2  OBX  [{NTE}]  }] --- End Group 2  } --- End Group 1
  73. 73. July 13, 2015 Page: 73 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Example Abstract Message ADT^A01^ADT_A01: ADT Message Segments Description Status Chapter MSH Message Header 2 [{ SFT }] Software Segment 2 [ UAC ] User Authentication Credential 2 EVN Event Type 3 PID Patient Identification 3 [ PD1 ] Additional Demographics 3 [{ ARV }] Access Restrictions 3 [{ ROL }] Role 15 [{ NK1 }] Next of Kin / Associated Parties 3 PV1 Patient Visit 3 [ PV2 ] Patient Visit - Additional Info. 3 [{ ARV }] Access Restrictions 3 [{ ROL }] Role 15 [{ DB1 }] Disability Information 3 [{ OBX }] Observation/Result 7 [{ AL1 }] Allergy Information 3 [{ DG1 }] Diagnosis Information 6 [ DRG ] Diagnosis Related Group 6 [{ --- PROCEDURE begin PR1 Procedures 6 [{ ROL }] Role 15 }] --- PROCEDURE end [{ GT1 }] Guarantor 6 [{ --- INSURANCE begin IN1 Insurance 6 [ IN2 ] Insurance Additional Info. 6 [{ IN3 }] Insurance Additional Info - Cert. 6 [{ ROL }] Role 15 }] --- INSURANCE end [ ACC ] Accident Information 6 [ UB1 ] Universal Bill Information 6 [ UB2 ] Universal Bill 92 Information 6 [ PDA ] Patient Death and Autopsy 3 Segments Description Status Chapter MSH Message Header 2 [{ SFT }] Software Segment 2 [ UAC ] User Authentication Credential 2 EVN Event Type 3 PID Patient Identification 3 [ PD1 ] Additional Demographics 3 [{ ARV }] Access Restrictions 3
  74. 74. July 13, 2015 Page: 74 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SEGMENT DEFINITION
  75. 75. July 13, 2015 Page: 75 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 Message - Segment  An HL7 message segment is an ordered collection of data fields.  Segments in a message:  are identified by a unique three character code known as the Segment ID.  may be required or optional  may be repeating or non-repeating  may occur in multiple positions in the same message
  76. 76. July 13, 2015 Page: 76 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 v2 Fields, Data Elements and Datatypes Message Specification Segment Group Message Segment Segment Segment Field Data Element Data Type Composite Data Type Data Type Component Code Table Code Table Item Code System Term Code System  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 primitive or composite. A composite datatype is an ordered collection of one or more data type components; a primitive 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.
  77. 77. July 13, 2015 Page: 77 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MSH - Message Header Segment SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set
  78. 78. July 13, 2015 Page: 78 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MSH - Message Header Segment SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set SEQ - position within segment LEN - length of field C.LEN – conformance length DT - data type for field OPT - optionality for field RP/# - repeatability TBL# - table number for codes ITEM# - HL7 element number ELEMENT NAME - name Segment Definition Table
  79. 79. July 13, 2015 Page: 79 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SEGMENT FIELD SEQUENCE
  80. 80. July 13, 2015 Page: 80 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Definition Table  SEQ – Sequence  Definition: Ordinal position of the data field within the segment.  Sequence one follows the field separator following the segment identifier  Sequence one in the MSH segment is also the field separator.
  81. 81. July 13, 2015 Page: 81 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MSH - Message Header Segment SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set
  82. 82. July 13, 2015 Page: 82 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SEGMENT FIELD LENGTH
  83. 83. July 13, 2015 Page: 83 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Definition Table  LEN – Normative Length  Established boundaries for minimum and/or maximum length of a single field occurrence. Does not include repetitions  The minimum and the maximum length separated by two dots, e.g. m..n; or the list of possible values for length separated by commas, e.g. x,y,z.  When a normative length is asserted, compliant messages must have a length that lies within the boundaries specified. The boundaries are inclusive, so a length of 1..3 means the length of the item may be either 1, 2, or 3.  Normative lengths are only specified for fields with primitive data types.  “65536” is a conventional value used to express a very large field  “99999” indicates that the length may vary  The lengths specified for primitive datatypes may vary across the different fields  E.g. an ST in one field may be 20, in another it may be 199
  84. 84. July 13, 2015 Page: 84 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Definition Table  C.LEN – Conformance Length  Minimum length that applications must be able to store  Applications SHALL NOT truncate a value that is shorter than the length specified  Truncation Pattern (‘=‘ or ‘#’)  = - value may never be truncated  # - value truncation behavior defined by data type SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID
  85. 85. July 13, 2015 Page: 85 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Example LEN and C.LEN 1. Min 1, max 1 2. Min 4, max 5 3. Defined by HD datatype 4. Defined by HD datatype 5. Defined by HD datatype 6. Defined by HD datatype 7. Defined by DTM datatype 8. Min 40, with no truncation 9. Defined by MSG datatype 10. Min 1, max 199, with no truncation
  86. 86. July 13, 2015 Page: 86 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MSH - Message Header Segment SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set
  87. 87. July 13, 2015 Page: 87 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner DATATYPES
  88. 88. July 13, 2015 Page: 88 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Definition Table  DT – Data Type  Restrictions on the contents of the data field.  If the data type of the field is variable, the notation “varies” is used.  HL7 defines 89 different data types.  Each field is assigned a data type.  Some data types are primitive (singular value, e.g. string).  Some data types are complex (contain discernible parts or components). For example, the patient’s name is recorded as last name, first name, middle name or initial, suffix, prefix, and professional suffix.  Each component is a distinct data element separated by the component delimiter, e.g. “^” |Smith^John^J^III^Dr.^MD|
  89. 89. July 13, 2015 Page: 89 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Text/String Data Types ST String 999 TX Text data 65536 FT Formatted text 65536 SRT Sort order <sort-by field/parameter (varies)> ^ <sequencing (ID)> Name Note: Normative lengths are only specified for primitive data types. LenAlphanumeric
  90. 90. July 13, 2015 Page: 90 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner FT: Formatted Text  .sp <number> End current output line and skip <number> vertical spaces. If <number> is absent, skip one space. For compatibility with previous versions of HL7, “^.sp” is equivalent to “.br.”  .br Begin new output line.  .fi Begin word wrap or fill mode. This is the default state.  .nf Begin no-wrap mode.  .in <number> Indent <number> of spaces, where <number> is a positive or negative integer.  .ti <number> Temporarily indent <number> of spaces where number is a positive or negative integer.  .sk <number> Skip <number> spaces to the right.  .ce End current output line and center the next line
  91. 91. July 13, 2015 Page: 91 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Numerical Data Types Numerical CQ Composite quantity with units <quantity (NM)> ^ <units (CWE)> MO Money <quantity (NM)> ^ <denomination (ID)> NM Numeric SI Sequence ID SN Structured numeric <comparator (ST)> ^ <num1 (NM)> ^ <separator/suffix (ST)> ^ <num2 (NM)> Name Len
  92. 92. July 13, 2015 Page: 92 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Code & Identifier Data Types Identifier ID Coded values in HL7 table IS Coded values for user- defined table VID Version identifier <version ID (ID)> ^ <internationalization code (CWE)> ^ <international version ID (CWE) HD Hierarchic designator <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Name Len
  93. 93. July 13, 2015 Page: 93 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Code & Identifier Data Types Identifier Name EI Entity identifier <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> RP Reference pointer <pointer (ST) > ^ < application ID (HD)> ^ <type of data (ID)> ^ <subtype (ID)> PL Person location <point of care (IS )> ^ <room (IS )> ^ <bed (IS)> ^ <facility (HD)> ^ < location status (IS )> ^ <person location type (IS)> ^ <building (IS )> ^ <floor (IS )> ^ <location description (ST)> ^ <comprehensive location identifier (EI)> ^ <assigning authority for location (HD)> PT Processing type <processing ID (ID)> ^ <processing mode (ID)> Len
  94. 94. July 13, 2015 Page: 94 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Date/Time Data Types Date/time DT Date 8 YYYY[MM[DD]] TM Time 16 HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ] DTM Date/time 24 YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/- ZZZZ] [ ] Optional elements
  95. 95. July 13, 2015 Page: 95 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Coded Data Types Code Values CNE Coded with no exceptions These data types supersede CE, which has been withdrawn. <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ID)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)> ^ <coding system version ID (ST)> ^ <alternate coding system version ID (ST)> ^ <original text (ST)> ^ <second alternate identifier (ST)> ^ <second alternate text (ST)> ^ <name of second alternate coding system (ST)> ^ <second alternate coding system version ID (ST)> ^ <coding system version OID (ST)> ^ <value set OID (ST)> ^ <value set version ID (DTM)> ^ <alternate coding system OID (ST)> ^ <alternate value set OID (ST)> ^ <alternate value set version ID (DTM)>^ <second alternate coding system OID (ST)> ^ <second alternate value set OID (ST)> ^ <second alternate value set version ID (DTM)> CWE Coded with exceptions
  96. 96. July 13, 2015 Page: 96 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Extended Demographics Data Types XCN Extended composite ID number and name <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <check digit scheme (ID)> ^ <identifier type code (ID)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CWE)> ^ <name validity range (DR)> ^ < name assembly order (ID)> ^ <effective date (DTM)> ^ <expiration date (DTM)> ^ <professional suffix (ST)> ^ <assigning jurisdiction (CWE)> ^ <assigning agency or department (CWE)>
  97. 97. July 13, 2015 Page: 97 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Extended Demographics Data Types XAD Extended address <street address (SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ … XPN Extended person name <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof (ST)> ^ … XON Extended composite name and ID number for organiza- tions <organization name (ST)> ^ <organization name type code (IS)> ^ <ID number (NM)> ^ <identifier check digit (NM)> ^ <check digit scheme (ID)> ^ <assigning authority (HD)> ^ <identifier type code (ID)> ^ <assigning facility ID (HD)> ^ <name representation code (ID)> ^ <organization identifier (ST)
  98. 98. July 13, 2015 Page: 98 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Extended Demographics Data Types XTN Extended telecommunications number <telephone number> ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <communication address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <local number (NM)> ^ <extension (NM)> ^ … SAD Street address <street or mailing address (ST)> ^ <street name (ST)> ^ <dwelling number (ST)>
  99. 99. July 13, 2015 Page: 99 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MSH - Message Header Segment SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set
  100. 100. July 13, 2015 Page: 100 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner OPTIONALITY AND REPETITION
  101. 101. July 13, 2015 Page: 101 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Definition Table  OPT – Optionality  Definition: Whether the field is required, optional, or conditional in a segment.  The designations for optionality are:  R - required  RE - required but may be empty  O - optional  C - conditional on trigger event or other field(s)  X - not used with this trigger event  B - left in for backward compatibility with previous versions  W - withdrawn
  102. 102. July 13, 2015 Page: 102 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Definition Table  REP – Repetition  Indicates whether the field may repeat.  The designations for Repetition are:  N or blank - no repetition  Y - the field may repeat an indefinite number of times  (integer) - the field may repeat up to the number of times specified by integer  Each occurrence may contain the number of characters specified by the field’s maximum length
  103. 103. July 13, 2015 Page: 103 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MSH - Message Header Segment SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set
  104. 104. July 13, 2015 Page: 104 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner VALUE SET TABLES
  105. 105. July 13, 2015 Page: 105 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Definition Table  TBL# - Value Table  Definition: The table attribute of the data field definition specifies the HL7 identifier for a set of coded values.  An entry in the table number column means that the table name and the element name are equivalent.  If this attribute is not valued or blank, there is not a table of values defined for the field.  Specifies the sets of allowable code values for coded fields and datatype components  HL7-Defined Table  User-Defined Table  External Table  Imported Table  Local Table
  106. 106. July 13, 2015 Page: 106 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 v2 Message Code Tables and Code Table Items Message Specification Segment Group Message Segment Segment Segment Field Data Element Data Type Composite Data Type Data Type Component Code Table Code Table Item Code System Term Code System  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 an instance of 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.
  107. 107. July 13, 2015 Page: 107 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 Defined Tables  Normative  Set of values maintained and published by HL7.  They affect the interpretation of the messages that contain them  May not be redefined locally  The table itself may be extended with locally defined values  The ID data type is most often used for elements that are populated with value from HL7 tables
  108. 108. July 13, 2015 Page: 108 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner User-defined Tables  A user-defined table is a set of values that are locally or site defined  E.g. PV1-3 Assigned patient location, will vary from institution to institution  HL7 sometimes publishes suggested values that a site may use as a starter set (e.g., table 0001- Sex)  The IS data type is most often used for elements that are populated with values from user-defined tables.
  109. 109. July 13, 2015 Page: 109 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner External Tables  A set of coded values defined and published by another standards organization (e.g., ISO, WHO, etc.)  FT1-19 Diagnosis Code – FT1  Clinical Observations using LOINC codes  CF/CNE/CWE data type is used for elements that can be populated with values from external tables
  110. 110. July 13, 2015 Page: 110 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Imported Tables  Third-party definitions published in the HL7 Standard  Example includes list of valid units of measures imported from ISO
  111. 111. July 13, 2015 Page: 111 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Local Tables  Local definitions in non-HL7 published table
  112. 112. July 13, 2015 Page: 112 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MSH - Message Header Segment SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set
  113. 113. July 13, 2015 Page: 113 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner DATA ELEMENTS
  114. 114. July 13, 2015 Page: 114 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Segment Definition Table  Item# - Item Number  Definition: Unique identifier of data element within HL7  Element Name  Definition: Unique name of a data element within HL7
  115. 115. July 13, 2015 Page: 115 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MSH - Message Header Segment SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set
  116. 116. July 13, 2015 Page: 116 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 v2 Message Elements Message Specification Segment Group Message Segment Segment Segment Field Data Element Data Type Composite Data Type Data Type Component Code Table Code Table Item Code System Term Code System
  117. 117. July 13, 2015 Page: 117 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SESSION RETROSPECTIVE • Abstract Message Definition • Message Elements • Abstract Message Syntax • MESSAGE SEGMENT DEFINITION • SEGMENT FIELD SEQUENCE • SEGMENT FIELD LENGTH • HL7 V2 DATATYPES • OPTIONALITY AND REPETITION • VALUE SET TABLES • DATA ELEMENTS
  118. 118. July 13, 2015 Page: 118 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Q&A
  119. 119. July 13, 2015 Page: 119 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Hi3 Solutions 3500 W. Olive Ave, Suite 300 Burbank, CA 91505 ww.hi3solutions.com +1 800 918- 6520
  120. 120. July 13, 2015 Page: 120 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner July 13, 2015 HL7 v2 Message Construction Rules
  121. 121. July 13, 2015 Page: 121 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SESSION OVERVIEW • Message Delimiters • MESSAGING FRAMEWORK • PARTICIPATING APPLICATIONS • MESSAGE TYPES AND VERSION • MESSAGE ENCODING RULES • MESSAGE PROFILES • ACKNOWLEDGEMENTS • COMMUNICATION ENVIRONMENT
  122. 122. July 13, 2015 Page: 122 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MESSAGE DELIMITERS
  123. 123. July 13, 2015 Page: 123 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set MSH-1, MSH-2: Message Delimiters
  124. 124. July 13, 2015 Page: 124 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Delimiters (MSH-1, MSH-2) Delimiter Suggested Value Encoding Character Position Segment Terminator <CR> (Hex: 0D) Field Separator | Component Separator ^ 1 SubComponent Separator & 4 Repetition Character ~ 2 Escape Character 3 Truncation Character # 5
  125. 125. July 13, 2015 Page: 125 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Delimiters  Segment Terminator <CR>  Non-printing character – the four characters “<CR>” are shown in documentation for clarity  Terminates a segment record  Cannot be changed by implementers
  126. 126. July 13, 2015 Page: 126 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Delimiters  Field Separator (MSH-1)  Suggested: |  Identifies the start of a data field within a segment. Will be the first character following the Segment ID as established by the MSH segment  It may be changed by implementers
  127. 127. July 13, 2015 Page: 127 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Delimiters  Encoding Characters (MSH-2)  Component Separator (^) Separates adjacent components of data fields.  Subcomponent Separator (&) Separates adjacent subcomponents of data fields.  Repetition Separator (~) Separates multiple occurrences of a field.  Escape Character () Used to signal certain special characteristics of portions of the text field.  Truncation Character (#) Used to indicate that a value has been truncated.
  128. 128. July 13, 2015 Page: 128 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Field or Component Status  HL7 does not care how systems actually store data within an application. When fields are transmitted, they are sent as character strings  A field may exist in one of three population states in an HL7 message: Populated. (Synonyms: valued, non-blank, not blank, not empty.)  The sending system sends a value in the field. For example, if a sending system includes medical record number, that would be communicated as |1234567^^^MR^KP-CA|. Not populated. (Synonyms: unpopulated, not valued, empty, not present, missing.)  The sending system does not supply a value for the field. The Sender might or might not have a value for the field. unless there is a conformance profile governing the implementation, the receiving system can make no inference regarding the absence of an element value. Null.  Any existing value for the corresponding data base element in the receiving application should be deleted. This is symbolically communicated as two double-quotes between the delimiters (i.e., |""|).
  129. 129. July 13, 2015 Page: 129 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Sample HL7 v2.x Message Segments  MSH: Message Header  PID: Patient Identification  OBR: Observation Request  OBX: Observation Result  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
  130. 130. July 13, 2015 Page: 130 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner XML Encoding Rules for Version 2 Messages http://www.hl7.org/implement/standards/product_brief.cfm?product_id=275
  131. 131. July 13, 2015 Page: 131 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner XML Representation MSH|^~&|LAB|767543|ADT|767543|199003141304- 0500||ACK^^ACK|XX3657|P|2.4
  132. 132. July 13, 2015 Page: 132 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Messaging Framework
  133. 133. July 13, 2015 Page: 133 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 Conceptual Approach Critical Care Unit ADT System Acknowledgement Message Initiating Message Clinical Data Repository Initiating Message
  134. 134. July 13, 2015 Page: 134 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Messaging Framework Sending Application Receiving Application Message Type AcknowledgementEncoding Rules Message Profile [ ]
  135. 135. July 13, 2015 Page: 135 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MSH – Message Header SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID 11 PT R 00011 Processing ID 12 VID R 00012 Version ID 13 NM O 00013 Sequence Number 14 180= ST O 00014 Continuation Pointer 15 2..2 ID O 0155 00015 Accept Acknowledgment Type 16 2..2 ID O 0155 00016 Application Acknowledgment Type 17 3..3 ID O 0399 00017 Country Code 18 5..15 ID O Y 0211 00692 Character Set 19 CWE O 00693 Principal Language Of Message 20 3..13 ID O 0356 01317 Alternate Character Set Handling Scheme 21 EI O Y 01598 Message Profile Identifier 22 XON O 01823 Sending Responsible Organization 23 XON O 01824 Receiving Responsible Organization 24 HD O 01825 Sending Network Address 25 HD O 01826 Receiving Network Address The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. 3 5 9 12 16 21 15
  136. 136. July 13, 2015 Page: 136 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Header  MSH-3: Sending Application  MSH-5: Receiving Application  MSH-9: Message Type • MSH-9.1: Message Code • MSH-9.2: Event Type • MSH-9.3: Message Structure  MSH-12: Version ID  MSH-15: Accept Acknowledgement  MSH-16: Application Acknowledgement  MSH-21: Message Profile Identifier
  137. 137. July 13, 2015 Page: 137 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner PARTICIPATING APPLICATIONS Sending Application Receiving Application
  138. 138. July 13, 2015 Page: 138 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner PARTICIPATING APPLICATIONS  MSH-3 Sending Application (HD)  Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>  This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined. User-defined Table 0361- Application is used as the user-defined table of values for the first component.  MSH-5 Receiving Application (HD)  Components: <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>  This field uniquely identifies the receiving application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined. User-defined Table 0361- Application is used as the HL7 identifier for the user-defined table of values for the first component.
  139. 139. July 13, 2015 Page: 139 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Sample Message MSH|^~&#|REGADT|MCM|RSP1P8|MCM|200901051530 ||ADT^A45^ADT_A45|0000005|P|2.7|||AL|NE<CR> EVN|A45|200901051530<CR> PID|||MR1^^^XYZ^MR||JONES^MARY||19601010|F|||123 NORTH STREET^^NY^NY^10021|| (212)111-3333|||S||X1<CR> MRG|MR1^^^XYZ^MR||ACCT1||VISIT2<CR> PV1||O|PT||||||||||||||||VISIT4<CR>
  140. 140. July 13, 2015 Page: 140 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MESSAGE TYPES AND VERSION
  141. 141. July 13, 2015 Page: 141 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Type and Version  MSH-9 Message Type (MSG)  Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>  This field contains the message type, trigger event, and the message structure ID for the message. The receiving system uses this field to recognize the data segments, and possibly, the application to which to route this message.  MSH-12 Version ID (VID)  Components: <Version ID (ID)> ^ <Internationalization Code (CWE)> ^ <International Version ID (CWE)>  This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly. Beginning with Version 2.3.1, it has two additional "internationalization" components, for use by HL7 international affiliates. The <internationalization code> is CE data type (using the ISO country codes where appropriate) which represents the HL7 affiliate. The <internal version ID> is used if the HL7 Affiliate has more than a single 'local' version associated with a single US version. The <international version ID> has a CE data type, since the table values vary for each HL7 Affiliate.
  142. 142. July 13, 2015 Page: 142 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Type and Version HL7 Table 0104 - Version ID Value Description Comment (Date) 2.0 Release 2.0 September 1988 2.0D Demo 2.0 October 1988 2.1 Release 2.1 March 1990 2.2 Release 2.2 December 1994 2.3 Release 2.3 March 1997 2.3.1 Release 2.3.1 May 1999 2.4 Release 2.4 November 2000 2.5 Release 2.5 May 2003 2.5.1 Release 2.5.1 January 2007 2.6 Release 2.6 July 2007 2.7 Release 2.7 November 2010  Message Type |ADT^A45^ADT_A45|  MSH-9.1: Message Code (ADT)  MSH-9.2: Trigger Event (A45)  MSH-9.3: Message Structure (ADT_A45)  Version ID |2.7|  MSH-12.1 Version ID (2.7)  MSH-12.2 International Code ( )  MSH-12.3 International Version ID ( )
  143. 143. July 13, 2015 Page: 143 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Sample Message MSH|^~&#|REGADT|MCM|RSP1P8|MCM|200901051530 ||ADT^A45^ADT_A45|0000005|P|2.7|||AL|NE<CR> EVN|A45|200901051530<CR> PID|||MR1^^^XYZ^MR||JONES^MARY||19601010|F|||123 NORTH STREET^^NY^NY^10021|| (212)111-3333|||S||X1<CR> MRG|MR1^^^XYZ^MR||ACCT1||VISIT2<CR> PV1||O|PT||||||||||||||||VISIT4<CR>
  144. 144. July 13, 2015 Page: 144 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Structure  Specifies the abstract message structure code. Refer to HL7 Table 0354 – Message Structure for valid values.  Predefined abstract message definition  Message Type + Trigger Event => Message Structure  A message structure may be shared by more than one message type/event combination
  145. 145. July 13, 2015 Page: 145 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Table 0354 – Message Structure
  146. 146. July 13, 2015 Page: 146 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner HL7 v2.x Messaging Schema http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185 HL7 Version 2.3.1 Messaging Schemas
  147. 147. July 13, 2015 Page: 147 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MESSAGE ENCODING RULES Encoding Rules
  148. 148. July 13, 2015 Page: 148 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Chapter 3 Encoding Rules  To determine the exact representation of an abstract message, one applies the HL7 encoding rules to the abstract definition from the relevant transaction definition chapter. HL7 Message ADT Message A01 Admit ADT^A01^ADT_A01
  149. 149. July 13, 2015 Page: 149 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Encoding Rules - Sender  Encode each segment in the order specified in the abstract message format Segment ID identifies the segment Admit Message MSH EVN PID [ { NK1 } ] PV1 [ PV2 ] [ HL1 ] [ { AL1 } ] [ { DG1 } ] [ { PR1 } ] [ { GT1 } ] [ { IN1 [ IN2 ] [ IN3 ] } ] [ ACC ] [ UB1 ]
  150. 150. July 13, 2015 Page: 150 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Encoding Rules - Sender  Encode the data fields in the order specified in the segment definition table  Precede each data field with the data field separator  PID|||2-68708-5|253763|COX^JAMES...  Data fields ‘present, but null’ are encoded with “”  PID|||2-68708-5|253763|COX^JAMES|“”|... Data fields that are ‘not present’ require no characters SEQ LEN C.LE N DT OPT RP/# ITEM # TBL# ELEMENT NAME 1 1..1 ST R 00001 Field Separator 2 4..5 ST R 00002 Encoding Characters 3 HD O 0361 00003 Sending Application 4 HD O 0362 00004 Sending Facility 5 HD O 0361 00005 Receiving Application 6 HD O 0362 00006 Receiving Facility 7 DTM R 00007 Date/Time of Message 8 40= ST O 00008 Security 9 MSG R 00009 Message Type 10 1..199 = ST R 00010 Message Control ID
  151. 151. July 13, 2015 Page: 151 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Encoding Rules - Sender  If components, subcomponents, or repetitions at the end of a data field are ‘not present’, their separators may be omitted  If no more fields are present in a segment, the data field separators may be omitted |Marotta^David^John^^^| |Marotta^David^John| PID|...|Last Field||||||||<CR> PID|...|Last Field<CR>
  152. 152. July 13, 2015 Page: 152 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Encoding Rules - Sender  End each segment with the segment terminator PID|...|Last Field<CR>
  153. 153. July 13, 2015 Page: 153 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Decoding Rules - Receiver  If a data segment that is expected is not found, treat it as if all the data fields were ‘not present’  If a data segment is included that is not expected, ignore it; this is not an error PV1<CR> NEW|A|B|C<CR>
  154. 154. July 13, 2015 Page: 154 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Decoding Rules - Receiver • If unexpected data fields are found at the end of a data segment, ignore them; this is not an error SEG|A|B|C|New1|New2|New3<CR> SEG|A|B|C<CR>
  155. 155. July 13, 2015 Page: 155 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner MESSAGE PROFILES Message Profile [ ]Encoding Rules
  156. 156. July 13, 2015 Page: 156 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Profile Identifier  MSH-21 Message Profile Identifier (EI)  Components: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>  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.
  157. 157. July 13, 2015 Page: 157 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Profile Example ... ... ... NK1 MSH EVN PID NK1 NK1 NK1 NK1 PV1 PV2 OBX AL1 HL7 Message Structure ... 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
  158. 158. July 13, 2015 Page: 158 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner ACKNOWLEDGMENTS Acknowledgement
  159. 159. July 13, 2015 Page: 159 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Acknowledgments  With a positive accept acknowledgment, the receiving system commits the message to safe storage in a manner that releases the sending system from the need to resend the message.  After the message has been processed by the receiving system, an application acknowledgment may be used to return the resultant status to the sending system.  For example,  If a patient care system has processed the trigger event a lab test is ordered for a patient, it may send an unsolicited update to a lab application identifying the patient, the test ordered, and various other information about the order.  The ancillary system will acknowledge the order when it has processed it successfully.  For some pairings of patient care and ancillary department systems the acknowledgment may also include the order identification number that was assigned by the ancillary system.
  160. 160. July 13, 2015 Page: 160 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner General Acknowledgment Message
  161. 161. July 13, 2015 Page: 161 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Message Acknowledgment Segment
  162. 162. July 13, 2015 Page: 162 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Error Segment
  163. 163. July 13, 2015 Page: 163 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Acknowledgments  MSH-15 Accept Acknowledgment Type (ID)  This field identifies the conditions under which accept acknowledgments are required to be returned in response to this message.  MSH-16 Application Acknowledgment Type (ID)  This field contains the conditions under which application acknowledgments are required to be returned in response to this message.
  164. 164. July 13, 2015 Page: 164 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Acknowledgments Vectra XU 5/90C BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF POTASSIUM3.5-5.0 BED1OFF POTASSIUM3.5-5.0 POTASSIUM3.5-5.0 POTASSIUM3.5-5.0 BED1OFF POTASSIUM3.5-5.0 BED1OFF BED1OFF BED1OFF BED1OFFBED1OFF Critical Care Unit HIS/CIS Vectra XU 5/90C BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF BED1OFF POTASSIUM3.5-5.0 BED1OFF POTASSIUM3.5-5.0 POTASSIUM3.5-5.0 POTASSIUM3.5-5.0 BED1OFF POTASSIUM3.5-5.0 BED1OFF BED1OFF BED1OFF BED1OFFBED1OFF Clinical Data Repository A/D/T System Order Filling Application Accept Ack Accept + App ACK No ACK
  165. 165. July 13, 2015 Page: 165 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Sample Message MSH|^~&#|REGADT|MCM|RSP1P8|MCM|200901051530 ||ADT^A45^ADT_A45|0000005|P|2.7|||AL|NE<CR> EVN|A45|200901051530<CR> PID|||MR1^^^XYZ^MR||JONES^MARY||19601010|F|||123 NORTH STREET^^NY^NY^10021|| (212)111-3333|||S||X1<CR> MRG|MR1^^^XYZ^MR||ACCT1||VISIT2<CR> PV1||O|PT||||||||||||||||VISIT4<CR>
  166. 166. July 13, 2015 Page: 166 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Messaging Framework Sending Application Receiving Application Message Type AcknowledgementEncoding Rules Message Profile [ ]
  167. 167. July 13, 2015 Page: 167 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Messaging Framework Sending Application Receiving Application Message Type AcknowledgementEncoding Rules Message Profile [ ] MSH-3 MSH-5 MSH-9, MSH-12 MSH-21 MSH-15, MSH-16MSH-9.3
  168. 168. July 13, 2015 Page: 168 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Communication Environment  Error Free Transmission. Applications can assume that they correctly received all of the transmitted bytes in the order in which they were sent. However, sending applications may not assume that the message was actually received without receiving an acknowledgment message.  Character Conversion. If the two machines exchanging data use different representations of the same character set, the communications environment will convert the data from one representation to the other.  Message Length. HL7 sets no limits on the maximum size of HL7 messages. The Standard assumes that the communications environment can transport messages of any length that might be necessary. In practice, sites may agree to place some upper bound on the size of messages and may use the message continuation protocol for messages that exceed the upper limit.
  169. 169. July 13, 2015 Page: 169 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Middleware Vendor Products
  170. 170. July 13, 2015 Page: 170 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SESSION RETROSPECTIVE • Message Delimiters • MESSAGING FRAMEWORK • PARTICIPATING APPLICATIONS • MESSAGE TYPES AND VERSION • MESSAGE ENCODING RULES • MESSAGE PROFILES • ACKNOWLEDGEMENTS • COMMUNICATION ENVIRONMENT
  171. 171. July 13, 2015 Page: 171 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Q&A
  172. 172. July 13, 2015 Page: 172 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Hi3 Solutions 3500 W. Olive Ave, Suite 300 Burbank, CA 91505 ww.hi3solutions.com +1 800 918- 6520
  173. 173. July 13, 2015 Page: 173 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner July 13, 2015 HL7 v2 Inter-Version Compatibility and Local Extensions
  174. 174. July 13, 2015 Page: 174 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner SESSION OVERVIEW • Inter-version Compatibility • Local Extensions • MESSAGES • TRIGGER EVENTS AND SEGMENT GROUPS • SEGMENTS AND DATATYPES
  175. 175. July 13, 2015 Page: 175 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner INTER-VERSION COMPATIBILITY
  176. 176. July 13, 2015 Page: 176 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Version compatibility  The keys to understanding version compatibility are the following 2 axioms:  • Old receivers receiving new messages should be able to continue receiving messages without error.  • New receivers should be able to understand old messages.  A new message or a new message element of an HL7 message may be introduced.  A sending system should be able to send a new message or new message element.  The receiver, regardless of its version level, must ignore any message or message element it is not expecting without generating an application failure.  This does not preclude a receiver notifying the sender that an additional element was ignored, but the receiving application should not fail just from the existence of additional element.
  177. 177. July 13, 2015 Page: 177 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Version compatibility  HL7 versions are backwards compatible when:  New message types and structures are added  New segments are added to an existing message  New fields are added at the end of a segment  New components are added at the end of data types  Optional elements are re-designated conditional or required  Deprecated and withdrawn fields are retained as place holders  Deprecating messages or message constituents  Any required, optional or conditional constituent of an HL7 message, including the message itself, may be deprecated.  Language will be inserted stating the fact of deprecation, the version in which the deprecation occurred, and what message or message constituent, if any, replaces it.  Removing messages or message constituents  A message or message constituent may be removed from the standard immediately, only if is not referenced elsewhere in the standard or all references to it are also removed.  A message constituent, will be withdrawn and removed, no sooner than, after 2 versions in a deprecated state. For example, if a message was originally deprecated in v 2.3.1, its definition can be removed when v 2.6 is published.
  178. 178. July 13, 2015 Page: 178 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner LOCAL EXTENSIONS
  179. 179. July 13, 2015 Page: 179 0f 211Hi3 Solutions ~ Your healthcare standards conformance Partner Local Extensions  Local extensions are permitted to aid in meeting unique information or message processing needs particular to a suite of applications, community of users, or realm.  A realm is a localization group defined by geographic boundaries or jurisdiction, medical specialty area, time period, or any combination of the three. HL7 Affiliate organizations are typically designated as realms for the purpose of localization.  Localization methods exist for:  Messages  Trigger Events  Segment Groups  Segments  Data Types

×