HL7 v3 and caAdapter Overview Session Date: Session Length: 1 hour Trainer:
Session Details • Target Audience: caBIG™ community interested in HL7 v3, caAdapter users, HL7 v3 message builders, NCI Managers, Application Developers, and Domain Analysts. • Prerequisites: None
Session Details:Presenters and Participants • Who is Presenting: • Who is in attendance? • Name • Title • Cancer Center or Organization • Reason for Attending
Session Details:Online Training Environment: Centra… • Use these buttons (or choose from the Actions menu) to communicate with the trainer and other attendees. • Example: • Raise your hand to ask a question.
You can adjust what you see on screen by choosing from the View menu or by scrolling with the slide bars. Session Details:Online Training Environment: Centra
Session Details:Online Training Etiquette • Be an active learner! • Ask lots of questions. • Avoid the temptation to multi-task; keep distractions to a minimum. • When not actively asking a question or making a comment, please keep your phone on MUTE. • This will minimize background noise so that all can hear the person who is speaking. • Please do not put your phone on HOLD. • Telephone HOLD music will disrupt the call. • When asking a question or making a comment, please state your name. • This way, all participants will know who is speaking.
Session Details:Session Objectives • Upon successful completion of this session, you will be able to: • Provide an introduction to HL7 v3 • Discuss what HL7 v3 is and how it works • Explain why HL7 v3 and caAdapter are used within NCICB and caBIG™ • Describe what caAdapter is and how it works
Session Details:Lesson Plan • Introduction to HL7 • HL7 v3 Components and Process • HL7 v3 Interoperability and caBIG™ • High Level Overview of the caAdapter Tool
Introduction toHL7 • In this lesson, we will: • Explain what HL7 is and what it does • Discuss HL7 v2 and its issues • Describe what HL7 v3 is and what it does
Introduction to HL7:What is Health Level Seven (HL7)? • HL7 is an ANSI-accredited Standards Development Organization (SDO) operating in the healthcare arena. • It is a non-profit organization made up of volunteers – providers, customers, vendors, government, etc. • HL7 is an acronym for Health Level Seven • Seven represents the highest, or “application,” level of the International Standards Organization (ISO) communications model for Open Systems Interconnection (OSI) networks.
Introduction to HL7:What HL7 does… • Provides standards for data exchange to allow interoperability between healthcare information systems • What is interoperability? • It is the ability of two or more systems or components to exchange information, and to use the information that has been exchanged predictably (IEEE Standard Computer Dictionary) • HL7’s key goal of interoperability has two aspects: • Syntactic interoperability has to do with structure • Semantic interoperability has to do with meaning
Introduction to HL7:What HL7 does • HL7 focuses on the clinical and administrative data domains. • It defines data exchange standards for these domains called messages or messaging specifications (aka HL7 messages). • Messages are developed by technical committees and special interest groups in the HL7 organization. • HL7 organization defines 2 versions of the messaging standard: • HL7 v2.x (syntactic only) • HL7 v3.0 (semantic capability added) • HL7 messaging (v2.x and higher) has been recommended as a data exchange standard by the E-Government initiative.
Introduction to HL7:The Industry Standard • HL7 v2 is still the most commonly used HL7 standard • Over 90% of US hospitals have implemented some version of 2.x HL7 messages • The HL7 v2 messaging standard is considered: • The workhorse of data exchange in healthcare • The most widely implemented standard for healthcare information in the world • HL7 v2.5 was approved as an ANSI standard in 2003 • HL7 v2.6 is currently under development.
Introduction to HL7:Problems with HL7 v2… • HL7 v2 development process has no explicit methodology. • HL7 v2 does not support semantic grouping of messages to create comprehensive packets of information. • HL7 v2 messages do not specify coded terminologies as value sets. • HL7 v2 does not have conformance rules – this results in site specific implementation. • HL7 v2 is an interchange standard, notan interoperability standard. • HL7 v2 works well intra-enterprise, but does not scale well to inter-enterprise applications. Source: Charlie Mead, MD
Introduction to HL7:Problems with HL7 v2 Example HL7 v2.4 ORU^R01 for serum glucose: MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01 |CNTRL-3456|P|2.4<cr> PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES |196203520|F|||153 FERNWOOD DR.^^STATESVILLE^OH^35292||(206)3345232|(206)752-121|||| AC555444444||67-A4335^OH^20030520<cr> OBR|1|845439^GHH OE|1045813^GHH LAB|1554-5^GLUCOSE|||200202150730|||||| 555-55-5555^PRIMARY^PATRICIA P^^^^MD^^LEVEL SEVEN HEALTHCARE, INC. |||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD<cr> OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl| 70_105|H|||F<cr>
Introduction to HL7:TheHL7 v3 Solution… • HL7 v3 is not the next release of HL7 v2 - It is a paradigm shift • HL7 v3 addresses the problems of HL7 v2 by: • Reducing HL7 v2 optionality • Including testable conformance rules • HL7 v3 is based on a formal development methodology: • Follows an Object Oriented (OO) approach • Uses Universal Modeling Language (UML) principles • Most importantly, HL7 v3 supports semantic interoperability
Introduction to HL7:TheHL7 v3 Solution • Additional HL7 v3 features include: • A uniform set of models • Representation of complex relationships • Formalisms for vocabulary support • Top-down message development • Solving re-use and interoperability issues across multiple domain contexts • Scope is expanding to include community medicine, epidemiology, veterinary medicine, clinical genomics, security, etc.
Introduction to HL7:The Four Pillars of Semantic Interoperability in HL7 v3 • A common Reference Information Model (RIM) which spans the entire patient care, administrative and financial healthcare universe • A well-defined and tool-supported process for deriving data exchange specifications ("messages") from the RIM • A formal and robust Data Type Specification upon which to ground the RIM • A formal methodology for binding concept-based terminologies to RIM attributes
Introduction to HL7: Any Questions? • What HL7 is and what it does • HL7 v2 and its issues • What HL7 v3 is and what it does
HL7 v3 Components and Process • In this Lesson, we will: • Describe the components of HL7 v3 that support semantic interoperability.
HL7 v3 Components and Process:Reference Information Model (RIM) • The RIM is the cornerstone of HL7 v3messaging. • The RIM is an UML Model class diagram. • The RIM: • Is the fundamental model from which all v3 messages are derived • Is a generic, abstract model that expresses the information content of all the areas of healthcare • Forms a shared view of the healthcare domain, and is used across all HL7 messages independent of message structure
HL7 v3 Components and Process: RIM Domains Administrative Management Health & Clinical Management Accounting & Billing Clinical Document Arch. Claims & Reimbursement Medical Records Patient Administration Public Health Reporting Scheduling Regulated Studies Common Message Element Types (CMETs) Common Domains Shared Messages
HL7 v3 Components and Process: The Complete RIM Pictorial • Classes are color coded: • Green = Entity, Yellow = Role, Blue = Participation, Red/Pink = Act, Purple = Infrastructure, Lilac = message controller. Domain Related 1 1 1 1 Structured Documents Infrastructure Related
Classes are color coded: Green = Entity, Yellow = Role, Blue = Participation, Red/Pink = Act, Purple = Infrastructure, Lilac = message controller. HL7 v3 Components and Process: RIMBackbone Classes • Acts connect to Entities in their Roles through Participations, but can also connect to other Acts through Act Relationships. Entity Role Participation Act A physical thing, group of physical things or an organization capable of participating in Acts, while in a role. An association between an Act and a Role with an Entity playing that Role. Each Entity (in a Role) involved in an Act in a certain way is linked to the act by one Participation-instance. A record of something that is being done, has been done, can be done, or is intended or requested to be done. A competency of the Entity playing the Role as identified, defined, guaranteed, or acknowledged by the Entity that Scopes the Role. 0..1 1 1 0..n 0..n 0..n 0..1 0..n Act Relationship Role Link 0..n 0..n 0..n 0..n A connection between two roles expressing a dependency between those roles. A directed association between a source act and a target act.
HL7 v3 Components and Process:RIM UML Instance Scenario Entity Role Participation Act (Procedure Act) Prostectomy John Doe Patient Subject Dr. Smith HealthCare Provider Surgeon XYZ Hospital HealthCare Facility Location Has Pertinent Information Act Relationship (Clinical Trial Act) Protocol ECOG 1112 John Doe Patient Subject • Classes are color coded: • Green = Entity, Yellow = Role, Blue = Participation, Red/Pink = Act, Purple = Infrastructure, Lilac = message controller.
HL7 v3 Components and Process:Domain Related Classes of the RIM… • RIM Entity Classes
RIM Backbone Class: Entity Entity: a person, animal, organization or thing A collection of classes related to the Entity class, its specializations and related qualifying classes. The classes represent health care stakeholders and other things of interest to health care. Entity has the following sub-classes: Container Device LanguageCommunication LivingSubject ManufacturedMaterial Material NonPersonLivingSubject Organization Person Place Entity classCode : CS determinerCode : CS id : SET<II> code : CE quantity : SET<PQ> name : BAG<EN> desc : ED statusCode : SET<CS> existenceTime : IVL<TS> telecom : BAG<TEL> riskCode : CE handlingCode : CE HL7 v3 Components and Process:Domain Related Classes of the RIM…
HL7 v3 Components and Process:Domain Related Classes of the RIM… • RIM Role Classes
RIM Backbone Class: Role Roles: A responsibility or part played by an entity (e.g. Person in a role of patient, employee, etc.) –different faces of an Entity A collection of classes related to the Role class and its specializations. These classes focus on the roles participants may play in health care. Role has the following sub-classes: Access Employee LicensedEntity Patient classCode : CS id : SET<II> code : CE negationInd : BL addr : BAG<AD> telecom : BAG<TEL> statusCode : SET<CS> effectiveTime : IVL<TS> certificateText : ED quantity : RTO positionNumber : LIST<INT> HL7 v3 Components and Process:Domain Related Classes of the RIM…
HL7 v3 Components and Process:Domain Related Classes of the RIM… • RIM Participation and Act Classes
RIM Backbone Class: Participation Participation: An association between an Act and a Role with an Entity playing that Role. Participation has the following sub-class: ManagedParticipation Participation typeCode : CS functionCode : CD contextControlCode : CS sequenceNumber : INT negationInd : BL noteText : ED time : IVL<TS> modeCode : CE awarenessCode : CE signatureCode : CE signatureText : ED performInd : BL substitutionConditionCode : CE HL7 v3 Components and Process:Domain Related Classes of the RIM…
Act: A collection of classes including the Act class and its specializations. These relate to the actions and events that constitute health care services. A record of something that is being done, has been done, can be done, or is intended or requested to be done. Act has the following sub-classes: Account ControlAct DeviceTask DiagnosticImage Diet FinancialContract FinancialTransaction InvoiceElement RIM Backbone Class: Act Act classCode : CS moodCode : CS id : SET<II> code : CD negationInd : BL derivationExpr : ST text : ED title : ST statusCode : SET<CS> effectiveTime : GTS activityTime : GTS availabilityTime : TS priorityCode : SET<CE> confidentialityCode : SET<CE> repeatNumber : IVL<INT> interruptibleInd : BL levelCode : CE independentInd : BL uncertaintyCode : CE reasonCode : SET<CE> languageCode : CE HL7 v3 Components and Process:Domain Related Classes of the RIM… • Observation • Participation • PatientEncounter • Procedure • PublicHealthCase • SubstanceAdministration • Supply • WorkingList • Note: Sub-classes also include Core Infrastructure, Message Communications Control and Structured Documents classes not shown here.
ActRelationship: A directed association between a source Act and a target Act. A point from a later instance to a earlier instance OR point from collector instance to component instance. ActRelationship has no sub-classes. RIM Backbone Class: ActRelationship ActRelationship 0..n outboundRelationship typeCode : CS inversionInd : BL contextControlCode : CS source 0..n contextConductionInd : BL Act sequenceNumber : INT priorityNumber : INT pauseQuantity : PQ checkpointCode : CS splitCode : CS joinCode : CS negationInd : BL conjunctionCode : CS localVariableName : ST seperatableInd : BL 0..n inboundRelationship target 1 HL7 v3 Components and Process:Domain Related Classes of the RIM
RMIM RIM DMIM 1..* 1..* MT HMD 1..* 1..* HL7 v3 Components and Process:HL7 v3 Process & Artifacts Overview DMIM – Domain Message Information Model; RMIM- Refined Message Information Model; HMD – Hierarchical Message Description; MT – Message Type
HL7 v3 Components and Process: Domain Message Information Model (DMIM) • ADMIM is a refined subset of the RIM that includes a set of class clones, attributes and relationships that can be used to create messages for a particular domain (a particular area of interest in healthcare). • This is the DMIM for the Patient Administration Domain Example: PRPA_DM201101UV01
HL7 v3 Components and Process: Refined Message Information Model (RMIM) • The RMIM is a subset of a DMIM that is used to express the information content for a message or set of messages with annotations and refinements that are message specific. • This is the RMIM for the PatientLivingSubject Event Activate Example: PRPA_RM201101UV01
HL7 v3 Components and Process: Hierarchical Message Definition (HMD) • An HMD is a serialized version of the RMIM in a specific order. • This is the HMD for the PatientLivingSubject Event Activate Example: PRPA_HD201101UV01
HL7 v3 Components and Process: Message Type (MT) • A Message specification is a set of rules for constructing a message given a specific set of instance data • This is the XML schema for the PatientLivingSubject Event Activate message Example: PRPA_MT201101UV01
HL7 v3 Components and Process: Introduction to Data Types… • Data types are the basic building blocks of attributes • Data types define the meaning (semantics) of data values that can be assigned to a data element • Meaningful exchange of data requires that we know the definition of the values exchanged • Every attribute in the RIM is associated with one and only one data type, and each data type is associated with zero or many attributes • Data types in HL7 v3 are complex: • Each data type has attributes • Each data type attribute has a data type of its own
HL7 v3 Components and Process:Introduction to Data Types… • HL7 v3 has published a data type specification and supports 42 data types • First example of a complex data type: Physical Quantity (PQ) example <lengthOfStayQuantity value=“10”unit=“hours"/> The attributes ‘value’ and ‘unit’ are part of the complex data type Physical Quantity (PQ). Value is expressed as the data type of integer (int).
HL7 v3 Components and Process:Introduction to Data Types • Second Example of a complex data type: Coded Data type (CE, CD, CS, etc.) • <raceCodecode=“1002-5”codeSystem= “2.16.840.1.113883.5.104” • codeSystemName=“HL7 Race Vocabulary Domain"displayName=“American Indian or Alaska Native"codeSystemVersion=“3.0”/>
HL7 v3 Components and Process: Structural Attributes and Vocabulary • classCode and moodCode are both Structural Attributes. An Act of the Class Observation (OBS) with a Mood of Event (EVN). • Structural attributes/elements are used to specify the type and state of each RIM class and what it means when used in a message. • Structural attributes/elementsuse a standard vocabulary defined and controlled by the HL7 organization.
HL7 v3 Components and Process: External or User-Defined Vocabulary • User-defined vocabulary is not controlled by the HL7 organization. • This typically involves domain related vocabulary. • Some examples of user-defined vocabulary: • For capturing Observations: LOINC, SNOMED, etc. • For Adverse Events: MedDRA, CTC, etc. • caDSR/EVS
HL7 v3 Components and Process:Any Questions? • Reference Information Model (RIM) • Structured Process Components (DMIM, RMIM, HMD and MT) • Data Types • HL7 and User-defined Vocabulary
HL7 v3 Interoperability and caBIG™ • In this lesson, we will: • Explain why HL7 and HL7 v3 are used at NCICB • Discuss how caAdapter supports NCICB and caBIGTM goals of interoperability • Explain NCICB’s Clinical Architecture
HL7 v3 Interoperability and caBIG™:The Role of HL7 and HL7 v3 at NCICB • Nine out of ten US hospitals have implemented some version of 2.x HL7 messages. • Therefore, Health and Human Service (HHS) has recommended HL7 as the messaging standard for the electronic exchange of clinical data. • A goal of NCICB is to accelerate discovery through the synthesis of different types of cancer research data, thus facilitating translational research (combination of different disciplines of research). • Support for translational research requires integration of research data with clinical data at a semantic level. • Only then can it yield semantically computable data. • HL7 v3 offers the syntactic and semantic interoperability to make this integration possible.
HL7 v3 Interoperability and caBIG™:caAdapter and the caBIG™ Principles… • caAdapter supports NCICB and caBIG™ principles of: • Open source • Open access • Standards based • Open development • Collaboration with other intiatives • Provides a toolset to support a federation of data sources
HL7 v3 Interoperability and caBIG™:caAdapter and the caBIG™ Principles… • caAdapter (formerly called the HL7 SDK) is an open source tool that facilitates HL7 v3 message building, parsing and validation based on specific message definitions. • caAdapter has leveraged HL7 Java Special Interest Group (SIG) work and built new enhancements. • caAdapter provides the capability to perform vocabulary validation of core structural attributes through integration with NCICB caCORE components, such as the Enterprise Vocabulary System (EVS).
CSM HL7 v3 Interoperability and caBIG™:TheClinical Architecture Vision • HL7 v3 is a potential data exchange solution within the NCICB Clinical Architecture Vision.