HL7 Version 3: Developed Globally, Implemented Locally Mark Shafarman HL7 Chair with additional HL7 “roles” of past co-chair International Committee past co-chair Control/Query TC ex-officio member Architectural Review Board member Early Adopters Forum Applications Architect, Oracle Corporation mark.shafarman@oracle.com 1 415 491 8104 24 March, 2004 Copyright 2004, HL7 1 Acknowledgements With major help from George W. Beeler, Jr. Ph.D. Leader, HL7 Version 3 Acceleration Project Emeritus Staff, Mayo Clinic CEO, Beeler Consulting LLC woody@beelers.com 507-254-4810 And some additional contributions from Peter Schloeffel and Dipak Kalra And major contributions from the HL7 International Affiliates 24 March, 2004 Copyright 2004, HL7 2 Agenda • Introduction to HL7.org • Why Version 3 • Brief overview of v 3, including support for patient data: physical measurements – HL7 RIM – model of clinical information content – Creating model based message standards with RIM – Refinement with Constraints – Producing a simple example – Lab result example • How HL7 supports the EHR: Recent trends towards interoperability. • Examples of Contributions to version 3 from International affiliates 24 March, 2004 Copyright 2004, HL7 3 Interoperability & Innovation • Main Entry: in·ter·op·er·a·bil·i·ty Function: noun Date: 1977 : ability of a system (as a weapons system) to use the parts or equipment of another system Source: Merriam-Webster web site • interoperability : ability of two or more systems or components to exchange information and to use the information that has been exchanged. Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990] Functional interoperability 24 March, 2004 Copyright 2004, HL7 Semantic interoperability 4 Interoperability & Innovation HL7’s mission is clinical interoperability “To provide 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. Specifically, to create flexible, cost effective standards, guidelines, and methodologies to enable healthcare information system interoperability and sharing of electronic health records.” (Source: HL7 Mission statement, revised 2001) HL7’s strategy is innovation – both by ourselves and by our users 24 March, 2004 Copyright 2004, HL7 5 Who is HL7? • Over 500 organizational members, about 1500 total members • Up to 500 attend Working Group Meetings - including about 100 international attendees at the January 2004 WG) • 26 International affiliates in (in addition to “HL7/US”) – Argentina - Australia –Canada - China – Czech Republic- Denmark – Germany - Greece – Ireland - Italy – Korea - Lithuania – New Zealand - Poland – South Africa - Switzerland – The Netherlands 24 March, 2004 Copyright 2004, HL7 - Brazil - Croatia - Finland - India - Japan - Mexico - Spain - Taiwan - The United Kingdom 6 What has HL7 produced? • Founded in 1987 • Produced Version 1.0 and 2.0 in ‘87 and ‘88 • Approved HL7 message standards –2.1, 2.2, 2.3, 2.3.1, 2.4 and 2.5 in ‘90, ‘94, ‘97, ‘99 and ’00, and ’03. • Approved CCOW standards –1.0, 1.1, 1.2, 1.3 in ’99, ’00 and ‘01 • Approved XML-based Clinical Document Architecture standard in ’00 • Accredited as an SDO by ANSI in 1994 –All HL7 approvals since ‘94 are “American National Standards” • Published implementation recommendations for: –Object broker interfacing ‘98 –Secure messaging via e-mail ‘99 –HIPAA Claims attachments ‘99 –XML encoding of Version 2 ’00 • Approved Arden Syntax standard in ‘99 2003 -V3 Methodology: RIM + Vocabulary + Tooling 24 March, 2004 Early Adopters, Copyright 2004, HL7 v3 Core to ANSI status 7 2004 –V3 DSTUs, In Ballot, December 2003 Version 3 Normative: Clinical Document Architecture, Rel 2 Version 3: Data Types Rel 1 - Abstract Specification, XML ITS, UML ITS XML Implementation Technology Specification - Structures, Rel 1 Medical Records, Rel 1 Regulated Studies, Rel 1, – Periodic Reporting of Clinical Trial Laboratory Data – Annotated ECG Public Health Reporting, Rel 1 Scheduling, Rel 1 Claims and Reimbursement, Rel 1 Accounting and Billing, Rel 1 24 March, 2004 Common Message Elements, Rel 1 Infrastructure Management, Rel 1 Shared Messages, Rel 1 HL7 Message Transport Spec. Version 3 DSTU Patient Administration, Rel 1 Pharmacy, Rel 1 Version 3 Informative or Draft for comment Copyright 2004, HL7 Laboratory, Rel 1 Patient Care, Rel 1 Clinical Genomics Personnel Management Regulated Studies: Product Stability Content 8 In Ballot, December 2003, cont. Version 3 Informative or Draft for comment , continued Version 3 Guide Version 3 Backbone Attachments for CDA Release 1 Structured Product Labeling (Drug/clinical products “inserts”) 24 March, 2004 Copyright 2004, HL7 9 V3 Normative Status Note: some changes underway as negatives are still being resolved… • • • • • • • • • • • • RIM (March 03) Refinement and Localization (March 03) Datatypes: UML ITS, XML ITS, Abstract (ITS Independent) XML ITS (Message) Structures Message Transport Specifications (EBXML, WSDL/SOAP) CMETS (Common Message Element Types) Shared Messages (Application Acknowledgments) Infrastructure Management CDA Release 2 Patient Administration Medical Records Management Scheduling 24 March, 2004 Copyright 2004, HL7 Key: Normative, membership, committee, DSTU 10 V3 Normative Status Note: some changes underway as negatives are still being resolved… • • • • • • • • • Patient Administration Personnel Management Public Health Reporting (notifiable condition, patient safety) Regulated Studies (annotated ECG, clinical trial lab observation) Accounting and Billing Claims and Reimbursements –REL 1 Lab observations Pharmacy CTS: Common Terminology Services Key: Normative, membership, committee, DSTU 24 March, 2004 Copyright 2004, HL7 11 In ballot opening 24 March • Common Terminology Services • Infrastructure Management, Rel 1 • CMETS (Common Message Element Types), Rel 1 • Shared Messages, Release 1 Transport Specification – MLLP, Rel 1 • Datatypes: UML ITS, XML ITS, Abstract (ITS Independent) • XML ITS (Message) Structures XML Implementation Technology Specification – Data Types, Rel 1 • XML ITS – Structures, Rel 1 Key: Normative, membership, committee, DSTU, as planned– final ballot may vary from this list 24 March, 2004 Copyright 2004, HL7 12 In ballot opening 24 March • • • • • • • • • Claims and Reimbursement, Rel 2 Accounting and Billing, Release 1 Laboratory, Rel 1 Pharmacy, Rel 1 Patient Administration, Rel 1 Personnel Management Rel 1 Drug Stability Reporting, Rel 1 Individual Case Safety Report, Rel 1 Notifiable Condition Report, Rel 1 Key: Normative, membership, committee, DSTU, , as planned– final ballot may vary from this list 24 March, 2004 Copyright 2004, HL7 13 Related ballots opening March 24 EHR Functional Requirements DSTU Archetype and Template Architecture (1st committee) CCOW v 1.5 (1st membership) GELLO (Common expression language standard) (1st committee) Structured Product Labeling (1st membership) ** Structured Clinical Trial Protocol (1st committee) ** For comment only: – HL7 Version 3 Standard: Blood Bank, Release 1 XML Implementation Technology Specification – Guide, Release 1 – Study Data Tabulation Model – ** Based on CDA rel 2 (still at committee level, and not itself in ballot this cycle) 24 March, 2004 Copyright 2004, HL7 14 HL7 – Collaboration with other organizations utilizing/building standards X12N (US: Edifact) US FDA and US CDISC/ Pharma DICOM US Veterans Hospitals CEN TC 251 ISO TC 215 NIST (US: Nat’l Institute for Standards and Technology) HIMSS/IHE UK: NHS National “spine” and GP-to-GP projects 24 March, 2004 Copyright 2004, HL7 15 Agenda • Introduction to HL7.org • Why Version 3 • Brief overview of v 3, including support for patient data: physical measurements – HL7 RIM – model of clinical information content – Creating model based message standards with RIM – Refinement with Constraints – Producing a simple example – Lab result example • How HL7 supports the EHR: Recent trends towards interoperability. • Examples of Contributions to version 3 from International affiliates 24 March, 2004 Copyright 2004, HL7 16 Background: why standard interfaces? • Some history: – Back in the early 80’s, people developing distributed healthcare application systems noted that the number of interfaces increases as one half of the square of the number of systems being interfaced. For example: 2 systems, 1 interface System A System B B 3 systems, 3 interfaces A 24 March, 2004 C Copyright 2004, HL7 **standard induction proof available on request…or draw your own 17 Background: why standard interfaces? B 4 systems, 6 interfaces A C D B 5 systems, 10 interfaces A C E 24 March, 2004 D Copyright 2004, HL7 **standard induction proof available on request…or draw your own 18 Background: why standard interfaces? – Notice that the number of interfaces needed increases much faster than the number of systems – Those of you who liked algebra in high school may remember the formula for the “number of combinations of n things taken r at a time: n!/(n-r)!r! – For r=2, and arbitrary n, this is n(n-1)/2, which gives**: Systems: Interfaces: 3 3 4 6 5 10 24 March, 2004 Copyright 2004, HL7 **standard induction proof available on request… 19 Background: why standard interfaces? Systems: 6 8 10 20 30 40 50 100 Interfaces: 15 28 45 190 435 780 1225 4950 2 But n(n-1)/2=(n –n)/2 is not maintainable ! 24 March, 2004 Copyright 2004, HL7 20 Background: why standard interfaces? • Note that large organizations in the U.S., such as Mayo Fdn or Duke typically have between 50-100 such interfaces. The situation is similar for regional or national systems in Europe • At a cost of 50-100k per custom interface, it’s clearly much cheaper to have an interface standard. This reduces the number of interfaces for n systems to the cost of (n-1) interfaces, a huge savings. • This also allows, in most cases, a single interface to be changed without impacting the others. • This last feature enables a practical maintenance approach, as well as a practical systems evolution approach. 24 March, 2004 Copyright 2004, HL7 21 Remember our 5 systems with 10 interfaces: B: a Drug Order management System A C: A Lab System D E • This actually means that whatever vendor makes “C”, their internal lab data structures and vocabulary are mapped into a common (standard) semantic structure. And systems A, B, D and E all map the standard-defined semantic lab structures into their internal lab data structures. • Interfacing means MAPPING to/from Standard semantic structures. 24 March, 2004 Copyright 2004, HL7 22 Use case for a Reference Information Model B1: a Drug Order mgmnt System A1 C1: A Lab System Lab RIM D1 E1 B2: Drug Order B3: Drug Order A2 C2: Lab A3 D2 24 March, 2004 E2 C3:Lab Copyright 2004, HL7D3 23 E3 Use case for a Reference Information Model • In other words, at a particular site, Systems A1…E1, a local lab standard or reference information model will be developed. • But if that site needs to interoperate with other sites (site 2: A2…E2, and site 3: A3…E3), there needs to be an overall lab reference model that each site can map its information into and out of. 24 March, 2004 Copyright 2004, HL7 24 Use case for a Reference Information Model • The same is true for other patient related data: administrative/encounter management, financial, other types of clinical information. The overall reference model needs to accommodate each of these domains, with several additional constraints: – Non-clinical healthcare-related domains need to be able to use clinical domain data without it being stored and maintained in multiple models/structures. • Thus the non-clinical domain application may need to map its lab data needs into and out of the common lab reference model. • But this is the same concept as our original 5 systems, just on a much broader scale. – Vocabulary and identifiers must be coordinated across local domains. 24 March, 2004 Copyright 2004, HL7 25 The RIM is important “beyond just messaging” • The HL7 RIM is a mature version of a common (reference) healthcare applications information model – It supports both interfaces and system design • See not just MDF (message development framework), but the HDF (health development framework) • Not just messages, but CDR/E.H.R. applications, Structured Documents, templates, rules, etc. • Not just clinical but patient administrative, financial, public health, genomics 24 March, 2004 Copyright 2004, HL7 26 Additional reasons for Version 3 • Version 2 has no formal information model; the model is implicit, not explicit. • Version 2 models are similar to programming language “structures”, but without formal operations and without important OO concepts, such as generalizationspecialization hierarchies. • Version 2 has no formal binding of standard vocabularies to structures. The bindings are ad hoc and always site specific. • Version 2 identifier datatypes are insufficient for large-scale integration. 24 March, 2004 Copyright 2004, HL7 27 Additional reasons for version 3 • Diminishing returns from increased work on 2.X • Compatibility with previous versions is getting very heavy • The tower of Babel, or a New Dark Age – “Won’t HL7 go away now that we have XML?” – Niche groups proposing their own style of XML, and not understanding the difference between the ability to create an interface between any two systems, versus creating an standard on which to base interfaces between “n” systems. 24 March, 2004 Copyright 2004, HL7 28 New capabilities offered in Version 3…. • New capabilities offered in Version 3…. – Top-down message development emphasizing reuse across multiple contexts and semantic interoperability – Representation of complex temporal and non-temporal relationships – Formalisms for vocabulary support – Support for large scale integration • Solving the identifiers problem • Solving re-use and interoperability across multiple domain contexts – Creating a uniform set of models – Expanded scope to include community medicine, epidemiology, veterinary medicine, clinical genomics, security, etc. 24 March, 2004 Copyright 2004, HL7 29 Semantic interoperability To understand the data being received you must know both: 1. The definition of each element of data, and its relationship with each of the other elements – you must have a semantic model of the data and 2. The terminology to be used to represent coded elements, including the definitions, and relationships within the terminology 3. The HL7 V3 RIM and associated methodologies promote and facilitate semantic interoperability 24 March, 2004 Copyright 2004, HL7 30 In sum, how is V3 “better” than v2? • A conceptual foundation in a single, common Reference Information Model to be used across HL7 – RIM is in the process of becoming an ANSI and ISO standard • A strong semantic foundation in explicitly defined concept domains drawn from the best terminologies – Vocabulary-level interoperability • An abstract design methodology that technologyneutral – able to be used with whatever is the technology de jour – Separation of content and syntax 24 March, 2004 Copyright 2004, HL7 31 Agenda • Introduction to HL7.org • Why Version 3 • Brief overview of v 3, including support for patient data: physical measurements – HL7 RIM – model of clinical information content – Creating model based message standards with RIM – Refinement with Constraints – Producing a simple example – Lab result example • How HL7 supports the EHR: Recent trends towards interoperability. • Examples of Contributions to version 3 from International affiliates 24 March, 2004 Copyright 2004, HL7 32 Why do we need a RIM? • The creation of a ‘reference information model’ for healthcare supports – The creation of a standard set of structures (models) to use for the sharing of healthcare information • And the ability to bind a set of standard terminologies to these models supports – The sharing of these standard structures with standard (coded) names and also – The extension of the model via structural (coded) terminology 24 March, 2004 Copyright 2004, HL7 33 Why do we need a RIM? • Thus (a formal word!), we can create standard structures (models) with standard names (codes) – An ‘ontology of structures’ can be created • And if we can create sufficiently generic and granular models in our ontology of structures, we can map any healthcare application’s “domain” model into (and out of) the “reference” model 24 March, 2004 Copyright 2004, HL7 34 Why do we need a RIM? • Once we have done this for a given application, (and we only need to do this one time for a given application), we can re-use the information from that application in (any) other healthcare application. This guarantees both interoperability and re-use of all healthcare data. • But how do we do this…? 24 March, 2004 Copyright 2004, HL7 35 Core concepts of HL7 v3 RIM • The “Act” class and its specializations represent every action of interest in health care. • Specifically – “an action of interest that has happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. An act is an intentional action in the business domain of HL7. Healthcare (and any profession or business) is constituted of intentional actions. An Act instance is a record of such an intentional action.)” 24 March, 2004 Copyright 2004, HL7 36 Core concepts of RIM • Every happening is an Act – Procedures, observations, medications, supply, registration, etc. • Acts are related through an Act_relationship – composition, preconditions, revisions, support, etc. • Participation defines the context for an Act – author, performer, subject, location, etc. • The participants are Roles – patient, provider, practitioner, specimen, healthcare facility etc. • Roles are played by Entities – persons, organizations, material, places, devices, etc. 24 March, 2004 Copyright 2004, HL7 37 RIM Class Diagram V1.16 – July 2002 Language_communication language_cd : CE mode_cd : CE proficiency_level_cd : CE preference_ind : BL Entity class_cd : CS determiner_cd : CS id : SET<II> cd : CE communicates_withqty : SET<PQ> nm : BAG<EN> 1 desc : ED status_cd : SET<CS> existence_time : IVL<TS> telecom : BAG<TEL> risk_cd : CE 1..n handling_cd : CE importance_status_txt : ED serves used_by 0..n plays is_played_by 0..1 scopes 0..n is_scoped_by 0..1 1 Role class_cd : CS id : SET<II> cd : CE negation_ind : BL addr : BAG<AD> telecom : BAG<TEL> status_cd : SET<CS> effective_time : IVL<TS> certificate_txt : ED qty : RTO position_nbr : LIST<INT> 0..n 0..n is_target_for 1 Role_link has_target type_cd : CS 0..n effective_time : IVL<TS> is_source_for has_source Participation type_cd : CS function_cd : CD context_control_cd : CS sequence_nbr : INT note_txt : ED time : IVL<TS> mode_cd : CE awareness_cd : CE has_as_participant signature_cd : CS signature_txt : ED 0..n for has 0..n 1 Participation participates_in 1 Managed_participation id : SET<II> status_cd : SET<CS> Act class_cd : CS mood_cd : CS id : SET<II> cd : CD negation_ind : BL txt : ED status_cd : SET<CS> effective_time : GTS activity_time : GTS availability_time : TS priority_cd : SET<CE> confidentiality_cd : SET<CE> repeat_nbr : IVL<INT> interruptible_ind : BL context_lock_ind : BL independent_ind : BL reason_cd : SET<CE> language_cd : CE is_source_for has_source 1 0..n is_target_for has_target 1 0..n Act_relationship type_cd : CS inversion_ind : BL context_control_cd : CS sequence_nbr : INT priority_nbr : INT pause_qty : PQ checkpoint_cd : CS split_cd : CS join_cd : CS negation_ind : BL conjunction_cd : CS originates_in_context_of 1..* Living_subject administrative_gender_cd : CE birth_time : TS deceased_ind : BL deceased_time : TS multiple_birth_ind : BL birth_order_nbr : INT organ_donor_ind : BL 0..* Entity_heir Organization addr : BAG<AD> standard_industry_class_cd : CE Entity Material form_cd : CE Manufactured_material lot_nm : ST expiration_time : TS stability_time : IVL<TS> Place mobile_ind : BL addr : AD directions_txt : ED position_txt : ED gps_txt : ST Person addr : BAG<AD> marital_status_cd : CE education_level_cd : CE ambulatory_status_cd : CE disability_cd : CE living_arrangement_cd : CE religious_affiliation_cd : CE special_accommodation_cd : SET<CE> race_cd : SET<CE> ethnic_group_cd : SET<CE> Non_Person_living_subject taxonomic_classification_cd : CE breed_cd : CE strain_txt : ED gender_status_cd : CE euthanasia_ind : BL Device manufacturer_model_nm : ST software_nm : ST local_remote_control_state_cd : CE alert_level_cd : CE last_calibration_time : TS Container capacity_qty : PQ height_qty : PQ diameter_qty : PQ cap_type_cd : CE separator_type_cd : CE barrier_delta_qty : PQ bottom_delta_qty : PQ Imaging_modality pixel_intensity_relationship_cd : CE spacial_resolution_qty : PQ pixel_padding_qty : PQ Role_heir Employee job_cd : CE job_title_nm : ST job_class_cd : CE salary_type_cd : CE salary_qty : MO hazard_exposure_txt : ED protective_equipment_txt : ED Certified_entity recertification_time : TS Guarantor credit_rating_cd : CE Role Patient confidentiality_cd : CE very_important_person_cd : CE Access approach_site_cd : CD target_site_cd : CD gauge_qty : PQ Schedulable_resource slot_size_increment_qty : PQ served_by Enitites Roles • • • • • Infrastructure (Structured documents) 5 44 192 7 39 Acts (Clinical) Acts (Financial) Infrastructure (Message control) Billboard produced by: Rochester Outdoor Advertising Device_task parameter_value : LIST<ANY> Referral authorized_visits_qty : REAL Diagnostic_image subject_orientation_cd : CE Control_event : II Public_health_case detection_method_cd : CE transmission_mode_cd : CE disease_imported_cd : CE Act_heir Financial_act net_amt : MO Account nm : ST currency_cd : CE interest_rate_qty : RTO<MO,PQ> allowed_balance_qty : IVL<MO> Financial_contract payment_terms_cd : CE response_cd : CS Transmission creation_time : TS id : II is_contained_by security_txt : ST 0..* 1 0..n 1..* Financial_transaction credit_exchange_rate_qty : REAL debit_exchange_rate_qty : REAL interest_rate_qty : RTO may_have 1 can_include can_accompany value Query_event query_id : II 1 occurs_with 0..1 Clinical_document set_id : II version_nbr : INT completion_cd : CE storage_cd : CE copy_time : TS has_payload Sort_control element_nm : ST sequence_nbr : INT direction_cd : CS Primary Subject Areas Classes Attributes Associations Generalizations has occurs_with 0..1 0..n Message accept_ack_cd : CS application_ack_cd : CS attachment_txt : ED interaction_id : II processing_cd : CS processing_mode_cd : CS profile_id : SET<II> sequence_nbr : INT version_id : ST is_for 0..n 1 is_acknowledged_by Query_ack query_response_cd : CS message_query_cd : CE result_total_qty : INT result_current_qty : INT result_remaining_qty : INT Query_spec execution_and_delivery_time : TS initial_qty : INT has initial_qty_cd : CE message_query_cd : CE 1 modify_cd : CS response_modality_cd : CS response_priority_cd : CS response_element_group_id : SET<II> is_part_of may_contain 0..n Parameter has nm : ST is_parameter_of id : II 0..n 0... 0..1 Parameter_list Query_by_parameter Parameter_item value : ANY semantics_txt : ST Query_by_selection 1 0..n is_for Selection_expression has_ex pression Relational_expression element_nm : ST value : ST relational_operator_cd : CS Table_cell rowspan : INT colspan : INT abbr : ST axis : ST headers : SET<ED> scope : CS 1 has_right_side 1 has_left_side is_lhs_for 0..n Table rules : CS cellspacing : ST cellpadding : ST summary : ST width : ST border : INT frame : CS Local_attr name : ST value : ST Query_continuation continuation_qty : INT start_result_nbr : INT acknowledges 0..* Acknowledgement type_cd : CS note_txt : ED error_detail_cd : CE expected_sequence_nbr : INT Table_structure halign : CS char : ST charoff : ST valign : CS local_id : ST Table_column_structure span : INT width : ST Link_html title : ST name : ST href : ED rel : SET<CE> rev : SET<CE> Local_markup ignore_cd : CS descriptor : ST render : ST is_rhs_for 0..n Logical_expression relational_conjunction_cd : CS Copyright 2004, HL7 Invoice_element modifier_cd : CE unit_qty : PQ unit_price_amt : RTO<MO,PQ> factor_nbr : REAL points_nbr : REAL coverage_source_cd : CE notify_subject_ind : BL Financial Acts is_communicated_as Attention_line key_word_txt : ST : ST provides_context_for Act_context level_cd : CE Context_structure local_id : ST 0..1 structure_type_id executed_by executes 0..1 Batch nm : ST reference_control_id : II batch_total_nbr : SET<INT> batch_comment : SET<ST> transmission_qty : INT 24 March, 2004 Observation value : ANY interpretation_cd : SET<CE> method_cd : SET<CE> target_site_cd : SET<CD> derivation_expr : ST Infrastructure (Structured documents) Communication_function type_cd : CS telecom : TEL contains Working_list ownership_level_cd : CE Substance_administration route_cd : CE approach_site_cd : SET<CD> dose_qty : IVL<PQ> rate_qty : IVL<PQ> dose_check_qty : SET<RTO> max_dose_qty : SET<RTO> potency_qty : PQ substitution_cd : CE Clinical Acts Procedure method_cd : SET<CE> approach_site_cd : SET<CD> target_site_cd : SET<CD> Assigned_entity position_cd : CE primary_care_ind : BL 0..n Version reflects RIM changes through Harmonization on 03/07/2002 that were approved for implementation following the release of the second committee-level ballot of Version 3. Diet energy_qty : PQ carbohydrate_qty : PQ Message Control 0..* HEALTH LEVEL 7 REFERENCE INFORMATION MODEL VERSION 1.15 (RIM_0115) Supply qty : PQ expected_use_time : IVL<TS> Patient_encounter acuity_level_cd : CE admission_source_cd : CE birth_encounter_ind : BL discharge_disposition_cd : CE length_of_stay_qty : PQ pre_admit_test_ind : BL referral_source_cd : CE special_courtesies_cd : SET<CE> urgency_cd : CE valuables_desc : ED valuables_location_desc : ED 38 RIM Core Classes & Attributes Relationship Link Act Relationship Type_CD : CS Effective_TMR : IVL<TS> Type_CD : CS 0..1 0..* Entity Class_CD : CS CD : CV Determiner_CD : CS Status_CD : CS ID : II 0..1 0..1 0..* 0..* Role 1 validates Class_CD : CS CD : CV Effective_TMR : IVL<TS> Status_CD : CS ID : II 1 1 0..* Type_CD : CS TMR : IVL<TS> Status_CD : CS 0..* 0..* Act plays 0..* 1 Participation 0..1 0..* Class_CD : CS CD : CD Mood_CD : CS Status_CD : CS Activity_Time : GTS ID : II Six kinds of attributes: type_cd(class_cd), cd, time, mood(determiner), status, id 24 March, 2004 Copyright 2004, HL7 39 How does HL7 manage this abstraction? • In older HL7 models, each concept had a visible (physical) class or association to represent it • In current RIM: – only include a class when it adds new attributes and associations – for the rest, use coded “structural” attributes – ‘class’ or ‘type’ codes • Why are these named structural attributes? – because they use codes to represent concepts that would previously have been part of the model structure. 24 March, 2004 Copyright 2004, HL7 40 RIM Core Attribute Value Sets Entity Class Code • Living Subject • Person • Organization • Material • Place • ... Entity • Performer • Author • Witness • Subject • Destination • ... Participation Type Code Role 1 Participation 1 Act plays 0..* Class_CD : CS CD : CV Determiner_CD : CS Status_CD : CS • Observation • Procedure Act • Supply • Substance Adm ClassCode • Financial • ... 1 Class_CD : CS CD : CV Effective_TMR : IVL<TS> 1 0..* Type_CD : CS TMR : IVL<TS> Status_CD : CS 0..* validates Class_CD : CS CD : CD Mood_CD : CS Status_CD : CS Activity_Time : GTS 0..* Entity Determiner Code • Kind • Instance • (Qualified Group) 24 March, 2004 Role Class Code • Patient • Employee • Assigned Entity • Certified Entity • Guarantor • ... Copyright 2004, HL7 • Definition • Intent • Order • Event • Criterion • ... Act Mood Code 41 Vocabulary Domains and Codes • Coded attributes in the RIM must be associated with one and only one Vocabulary Domain prior to being used in a message specification. • A vocabulary domain is “The set of all concepts that can be taken as valid values in an instance of a coded field or attribute.” • Each concept in the vocabulary domain is represented using a code from a specific vocabulary. • A vocabulary is a defined set of coded concepts. • A vocabulary may be specified as an enumerated list of coded concepts (HL7 defined) or as a reference to an externally maintained list of coded concepts (e.g., SNOMED, LOINC, CPT, . . .). 24 March, 2004 Copyright 2004, HL7 42 Agenda • Introduction to HL7.org • Why Version 3 • Brief overview of v 3, including support for patient data: physical measurements – HL7 RIM – model of clinical information content – Creating model based message standards with RIM – Refinement with Constraints – Producing a simple example – Lab result example • How HL7 supports the EHR: Recent trends towards interoperability. • Examples of Contributions to version 3 from International affiliates 24 March, 2004 Copyright 2004, HL7 43 From abstraction to ‘concrete’ concepts • How can this “skinny” RIM and its codes represent the large, sophisticated sets of concepts that must be communicated to support modern health care? • Answer: The RIM is the starting point, the source or pattern, from which specific models are constructed to define a particular set of messages. • The messages are based on RIM-derivatives known in HL7-ese as Message Information Models 24 March, 2004 Copyright 2004, HL7 44 Refinement from RIM to Message 24 March, 2004 Copyright 2004, HL7 45 Agenda • Introduction to HL7.org • Why Version 3 • Brief overview of v 3, including support for patient data: physical measurements – HL7 RIM – model of clinical information content – Creating model based message standards with RIM – Refinement with Constraints – Producing a simple example – Lab result example • How HL7 supports the EHR: Recent trends towards interoperability. • Examples of Contributions to version 3 from International affiliates 24 March, 2004 Copyright 2004, HL7 46 Refined Model of Example in Visio • Development tools for HL7 design committees • Automation in Visio exports to repository • Automation on repository auto-generates Hierarchical Message Description • HMD-specific tools support addition of further constraints • Automatic expression of HMD in XML 24 March, 2004 Copyright 2004, HL7 • XSL converts HMD to Message schemas 47 Message structure from RMIM 2 1 ObservationOrder class_cd : CS mood_cd : CS id : SET<II> cd : CD activity_time : GTS observationOrder author 0... 3 Author type_cd : CS signature_cd : CS signature_txt : ED 4 PersonPractitioner class_cd : CS determiner_cd : CS certificate id : SET<II> subjectPerson nm : BAG<EN> 1... telecom : BAG<TEL> 0... CertifiedEntity class_cd : CS id : SET<II> 1... telecom : BAG<TEL> origination certifiedEntity 0... 0... subject 0... 0... performer observationOrder 8 Subject type_cd : CS 1... 9 Patient subjectOfclass_cd : CS id : SET<II> 1... addr : BAG<AD> patient 0... patient 10 healthCareProvider 0... 1... 1... observationOrder Performer type_cd : CS healthCareProvider 0... performance 1... 5 24 March, 2004 HealthCareProvider class_cd : CS id : SET<II> telecom : BAG<TEL> 6 Person class_cd : CS determiner_cd : CS id : SET<II> nm : BAG<EN> telecom : BAG<TEL> administrative_gender_cd : CE birth_time : TS healthCareOrganization Organization class_cd : CS 0... healthCareProviderLicense 1... determiner_cd 7 : CS id : SET<II> nm : BAG<EN> Copyright 2004, HL7 48 HMD expressed in XML 24 March, 2004 Copyright 2004, HL7 49 Message Instance Fragment 24 March, 2004 Copyright 2004, HL7 50 Agenda • Introduction to HL7.org • Why Version 3 • Brief overview of v 3, including support for patient data: physical measurements – HL7 RIM – model of clinical information content – Creating model based message standards with RIM – Refinement with Constraints – Producing a simple example – Lab result example • How HL7 supports the EHR: Recent trends towards interoperability. • Examples of Contributions to version 3 from International affiliates 24 March, 2004 Copyright 2004, HL7 61 HL7 supports the EHR: Recent trends towards interoperability • See: www.hl7.org/ehr/ • Electronic Health Record System Functional Model and Standard. – The Electronic Health Record SIG has recognized the need for a common industry standard for EHR functionality that will serve to set common benchmarks for the industry, to inform industry stakeholders (patients, providers, practitioners, payers, etc.) of vital EHR functions and to qualify EHR systems in terms of completeness and readiness for adoption. – 2nd DSTU ballot just announced – Significant participation from HL7 International Affiliates 24 March, 2004 Copyright 2004, HL7 62 HL7 supports the EHR: Recent trends towards interoperability • HL7 Clinical Document Architecture -- Release 2 – Working towards • complete interoperability with CEN 13606 extracts and openEHR documents • CDA Release 2 RMIM supports EHR document concepts See CDA Release 2 Committee Level Ballot 1 (available at www.hl7.org) (TC’s and SIGs->structured documents ->documents) • Recent related developments – HL7 UK GP to GP project – RIM Harmonization proposals add Act.classCode values needed for formally mapping CEN 13606 and openEHR into v3 RMIMs • This allowed the creation of an RMIM for CEN 13606/EHRCom (in process) as a step in this process 24 March, 2004 Copyright 2004, HL7 63 HL7 supports the EHR: Recent trends towards interoperability • HL7 templates harmonization project: – Testing interoperability between HL7 templates, CEN Entries, and openEHR archetypes by mapping each into v3 RMIM-based models – Demonstrating formal interoperability between the 3 approaches. – Go to “www.hl7.org” and select ‘online balloting’ to download current ballot document 24 March, 2004 Copyright 2004, HL7 64 Some related references A Shared Archetype and Template Language Part II (A Position Paper for HL7, CEN TC251, ISO/TC 215, openEHR and other organisations) – Available at: www.deepthought.com.au/health/archetypes/archetype_languag e_2v0.6.2.doc – Also, the Archetype Definition Language (ADL) will be available at this site, and will have the ability to represent Archetypes as HL7 v3 RMIMs. 24 March, 2004 Copyright 2004, HL7 65 Interoperability: CDA, CEN 13606 & openEHR Interoperability between EHR standards HL7 CDA (rel.2) HL7 Templates Harmonisation: ShARM Shared Archetypes Model/Templates openEHR CEN ENV 13606 24 March, 2004 Diagram courtesy Dipak Kalra Reference model Archetype model Copyright 2004, HL7 66 Interoperability between EHR standards Or…have the v3 RIM at the “center” openEHR Reference Model CEN 13606 HL7 V3 RIM Reference Model HEALTH LEVEL 7 REFERENCE INFORMATION MODEL RIM_0100 released January 2001 reflects RIM changes through Harmonization on 11/17/2000 Enitites Acts (Services) Roles Message_control Entity id : SET<II> type_cd : CC determiner_cd : CS importa nce_status_txt : ED Entity_name Role-role relationships Appointments & scheduling Healthcare_finances effective_tmr : IVL<TS> nm : EN is_for purpose_cd : CV Participation 0..* 1 Role is_played_by pl ays_a_role i s_source _of i s_target_for 1 1 has qty has_as_particip ant pa rticipates_in type_cd : cc effective_tmr : IVL<TS> addr : SET<AD> telecom : SET<TEL> sends 1..1 shall_receive 1..* type_cd : CS tmr : IVL<TS> 0..*note_text : ED signature_cd : CV for function_cd : CD awareness_cd : CV 0..* signature_txt : ED encounter_accommodation_cd : CV status_cd : CS 0..1 telecom : SET<TEL> 1 desc 0..* Billboard produced by: Rochester Outdoor Adv ertis ing status_cd : CS has 1 Military_person Notary_public notary_county_cd : CE notary_state_cd : CE Healthcare_provider specialty_cd : CV military_branch_of_service_cd : CV military_rank_nm : ST military_status_cd : CV Act id : SET<II> mood_cd : CS type_cd : CC txt : ED status_cd : CS activity_time : GTS critical_time : GTS confidentiality_cd : SET<CV> max_repeat_nmr : IVL<INT> interruptible_ind : BL priority_cd : SET<CV> orderable_ind : BL availability_dttm : TS is_source_for has_source 1 0..* i s_target_for has_target 1 0..* Act_relationship type_cd : CS inversion_ind : BL s equence_nbr : INT priority_nbr : INT pause_qty : PQ checkpoint_cd : CS split_cd : CS join_cd : CS negation_ind : BL c onjunction_cd : CS o ri ginates_i n_context_of 1..* Place gps_txt : ST position_txt addr : AD directions_txt Health_chart 1 Material form_cd : CV danger_cd : CE effective_tmr : IVL<TS> handling_cd : CE Organization org_nm : SET<ON> s tandard_industry_class_cd : CE addr : SET<AD> 0. .* Healthcare_facility licensed_bed_nbr : REAL mobile_ind : BL 1 is_site_f or 1 0..* has_as_target Person disability_cd : CE ethnic_group_cd : CE race_cd : CE ambula tory_status_cd : CV birth_order_nbr : INT edu cation_level_cd : CV living_arrangement_cd : CV marital_status_cd : CV religious_affiliation_cd : CV student_cd : CV credit_rating_cd : CV addr : SET<AD> special_ accomm odation_cd : SET<CV> Non_Person_living_subject ta xonomic_classification_cd : CE breed_cd : CE strain_txt : ED euthanasia_ind : BL production_class_cd : CE gen der_status_cd : CE h as_as_source 0..* has_parts 0..1 Patient_encounter discharge_disposition_cd : CV acuity_level_cd : CV birth_encounter_ind : BL status_reason_cd : CV classification_cd : CV encounter_classification_cd : CV practice_setting_cd : CV valuables_desc : ED pre_admit_test_ind : BL source_cd : CV special_courtesies_cd : CV valuables_location_desc : ED effective_tmr uses Access gauge_qty : PQ entry_site_cd : CD body_site_cd : CD Specimen body_site_cd : CE Manufactured_material expiration_dttm : TS lot_nbr : ST 1 com municates_in 0. .* Person_Language 1 is_specif ied_by Clinical_document_header availa bility_status_cd : CV chan ge_reason_cd : CV com pletion_status_cd : CV confidentiality_status_cd : CV content_presentation_cd : CV docum ent_creation_dttm : TS file_nm : ST las t_edit_dttm : TS reporting_priority_cd : CE results_report_dttm : TS storage_status_cd : CV transcription_dttm : TS document_change_cd : CV version_nbr : INT version_dttm : TS Consent Procedure entry_site_cd : SET<CD> method_cd : SET<CV> body_site_cd : SET<CD> form_cd : CD route_cd : CD dose_qty : PQ s trength_qty : PQ rate_qty : PQ dose_check_qty : PQ method_cd : SET<CV> body_site_cd : SET<CD> subs titution_cd : CV Document_service completion_cd : CV set_id : II storage_cd : CV version_nbr : INT copy_dttm : TS origination_dttm : TS energy_qty : PQ carbohydrate_qty : PQ effective_tmr : IVL<TS> reason_cd : CE status_dttm Act_context level_cd Message_interaction is_ communi cated_as Observation value : ANY derivation_expr : ST method_cd : SET<CV> body_site_cd : SET<CD> interpretation_cd : SET<CS> 0..1 Healthcare_benefit_product_policy Diagnostic_related_group_definition Patient_billing_account assignment_of_benefits_ind : BL base_rate_qty : MO adjustment_cd : CV benefit_product_desc : ED capital_reimbursement_qty : MO certification_required_ind : BL benefit_product_nm : ST cost_weight_qty : MO current_unpaid_balance_qty : MO benefit_product_type_cd : CE major_diagnostic_category_cd : CE expected_insurance_plan_qty : REAL benefits_coordination_ind : BL operating_reimbursement_qty : MO expected_payment_source_cd : CV cob_priority_nbr : REAL reimbursement_qty : MO notice_of_admission_dttm : TS combine_baby_bill_ind : BL standard_day_qty : PQ notice_of_admission_ind : BL group_benefit_ind : BL standard_total_charge_qty : MO patient_financial_class_cd : CV mail_claim_party_cd : CE trim_high_day_qty : PQ price_schedule_id : II release_information_cd : CE trim_low_day_qty : PQ report_of_eligibility_dttm : TS status_cd : CS retention_ind : BL coverage_type_cd : CE 1 def ines signature_on_file_dttm : TS agreement_type_cd : CE special_program_cd : CV policy_category_cd : CE is_def ined_by 0. .* stoploss_limit_ind : BL access_protocol_desc : ED suspend_charges_ind : BL Encounter_drg total_adjustment_qty : MO approval_ind : BL total_charge_qty : MO confidential_ind : BL total_payment_qty : MO cost_outlier_qty : MO separate_bill_ind : BL des c : ED grouper_review_cd : CE bad_debt_recovery_qty : MO Champus_coveragebad_debt_transfer_qty : MO grouper_version_id : II Practitioner_Certifier Employee_Employer Patient_Provider 0..* Practitioner_provider position_cd : CV primary_care_ind : BL 0. .* is_sited_at Encounter_facility_association effective_tmr : IVL<TS> status_cd : CS transfer_reason_cd : CV addr : SET<AD> hazard_expos ure_txt : ED job_class_cd : CV job_title_nm : ST telecom : SET<TEL> protective _equipment_txt : ED s alary_qty : MO salary_type_cd : CV status_cd : CS job_cd : CE board_certification_type_cd : CV certification_dttm : TS recertification_dttm : TS residency_field_cd : CE Unmapped_financial_classes (from R IM_Heal thcare_finances) Outbreak tmr 0..1 i s_u sed_by authori zes Preauthorization authorized_encounters_qty : REAL authorized_period_begin_tmr : IVL<TS> id : II issued_dttm : TS requested_dttm : TS restriction_desc : ED status_cd : CS status _change_dttm : TS Insurance_certification certification_duration_qty : PQ effective_tmr : IVL<TS> id : II insurance_verification_dttm : TS modification_dttm : TS non_concur_cd : CE non_concur_effective_dttm : TS penalty_qty : MO report_of_eligibility_dttm : TS report_of_eligibility_ind : BL 0..* 1 has_cov erage_af f irm ed_by Guarantor_contract billing_hold_ind : BL : CE charge_adjustment_cd : CE contract_duration_cd : CE contract_type_cd : CE effective_tmr : IVL<TS> interest_rate_nbr : REAL periodic_payment_qty : MO priority_ranking_cd : CV af f irms_insurance_cov erage_f or billing_media_cd Billing_information_item condition_cd : CE occurrence_cd : CE occurrence_dttm : TS occurrence_span_cd : CE occurrence_span_from_dttm : TS occurrence_s pan_thru_dttm : TS quantity_nbr : REAL quantity_type_cd : CV value_amt value_cd : CE 0..* HL7 CDA, Rel 2 24 March, 2004 Diagram courtesy Peter Schloeffel 0..* File_of_batch has_payl oad 0..* has_recipient Message sending_application_id : II 0..* id : SET<II> has_sender Batch control_id : II name : ST creation_dttm : TS reference_control_id : II sending_application_id : II receiving_application_id : II security : ST message_count : INT 0..1batch_totals : SET<INT> is_contained_by contains batch_comment : SET<ST> 0..* creation_dttm : TS interaction_id : II version_id : ST can_i ncl ude profile_id : SET<OID> 1 process ing_cd : CV sequence_nbr : INT reply_to_com : TEL has receiving_application_id : SET<II> processing_mode_cd 1 attachment_txt : ED 1 has has 0..* Query 0..1 has occurs_wi th 1 is_for 0..* contains applies_to Query_by_selection is_response_with 1 1 has contains 1 TBL_response_control h as_response 1 has 0. .* is _f or 1 has ret urns_to has_response is_response_with 0..* Tabular_row_data Copyright 2004, HL7 1 1 Query_spec_message_type occurs_with Query_ack Query_by_parameter Element_response_control name : SET<CV> Query_response_message_type 0. .1 mess age_query_name : CV query_tag : II priority : CV modify_indicator : CV execution_an d_delivery_time : TS 1 Response_control q uantity_limited : PQ respons e_modality : CV 0. .1 acknowledges 1. .* type_cd : CV note_txt : ED error_detail_cd : CV expected_sequence_nbr : INT query_tag : II query_status_cd : CV mess age_query_name : CV hit_count_total : INT hit_count_current : INT hit_count_remaining : INT 0..* key_word_txt : ST value : ST 1 occurs_with Acknowledgement 1 has is_contained_by control_id : II name : ST creation_dttm : TS reference_control_id : II sending_application_id : II receiving_application_id : II contains security : ST file_batch_count : INT 0..1 file_comment : SET<ST> Attention_line can_accompany TBL_sort_control name : ST direction : CV 1 applies_to 1. .* 0..1 is_fa ther_to Selection_criteria 0. .* Response_field field_id : ST data_type : CV length : INT 0. .* is _f or Element_sort_control element_name : ST direction : CV Healthcare_benefit_coverage_item service_category_cd : CV service_cd : CE servic e_modifier_cd : CE authorization_ind : BL network_ind : BL assertion_cd : CE covered_parties_cd : CE qty : REAL quantity_qualifier_cd : CE time_period_qualifier_cd : CE range_low_qty : PQ range_high_qty : PQ range_units_cd : CV eligibility_cd : CE policy_source_cd : CE eligibility_source_cd : CE copay_limit_ind : BL handicapped_program_cd : CE non_avail_cert_on_file_ind : BL retirement_dttm : TS s tation_id : II outlier_days_nbr : REAL outlier_reimbursement_qty : MO outlier_type_cd : CV Public_health_case de tection_method_cd trans mission_mode_cd dis ease_imported_cd 1 manages is_managed_by Clinical_document Supply qty : PQ Transportation Diet Schedule Resource_slot status_cd : CS time_slot : GTS Device manufacturer_model_nm : ST las t_calibration_dttm : TS software_nm : ST local_remote_control_state_cd : CE alert_level_cd : CE 0..* 1 is_authorized_by status_cd : CS slot_s ize_increment_ qty 0. .* Language_ability Container capacty_qty : PQ height_qty : PQ diameter_qty : PQ barrier_delta_qty : PQ bottom_delta_qty : PQ s eparator_type_cd : CD cap_type_cd : CD is_ut ilized_during util i zes i s_ part_of Inpatient_encounter mode_cd : CV proficiency_level_cd : CV ownership_level_cd Referral authorized_vis its _qty : REAL des c : ED reason_txt : ED 1 0..* length_of_stay_qty : PQ is_comm unicat ed_by specif ies_abilit y _in Role_relationship type_cd : CC effective_tmr : IVL<TS> id : SET<II> status_cd : CS responsibility_cd : SET<CE> position_nbr : LIST<INT> qty : PQ certificate_txt : ED Medication Working_list is_assessed_against Health_chart_deficiency assessment_dttm : TS desc : ED level_cd : CV type_cd : CV Financial_act prov ides_context_f or 0..* Individual_healthcare_practitioner fellowship_field_cd : CE graduate_school_nm : ON graduation_dttm : TS board_certified_ind : BL has_an_assessm ent_of Living_subject birth_dttm : TS deceased_dttm : TS deceas ed_ind : BL administra tive_gender_cd : CE organ_donor_ind : BL mu ltiple_birth_ind : BL name : ST 0..* relational_operator_cd : CV is_son _of value : ST relational_conjunction_cd : CV 67 Financial_transaction extended_qty : MO fee_schedule_cd : CE insurance_qty : MO posting_dttm : TS qty : MO transaction_batch_id : II unit_qty : MO unit_cost_qty : MO Agenda • Introduction to HL7.org • Why Version 3 • Brief overview of v 3, including support for patient data: physical measurements – HL7 RIM – model of clinical information content – Creating model based message standards with RIM – Refinement with Constraints – Producing a simple example – Lab result example • How HL7 supports the EHR: Recent trends towards interoperability. • Examples of Contributions to version 3 from International affiliates 24 March, 2004 Copyright 2004, HL7 68 The v3 Tools Taskforce • Chaired by Laura Sato – HL7 UK, formerly HL7 Canada • Some major contributors from the HL7 Affiliates include: – Charlie McKay, HL7 UK (VISIO and documentation extensions) – Lloyd Mckenzie, HL7 Canada • HL7 VISIO tools (current) • MIF (HL7 v3 XML Model Interchange Format) 24 March, 2004 Copyright 2004, HL7 69 V3 tools taskforce • In process to become a Board-appointed HL7 Tools Committee with a formal Mission and Charter statement • Current projects include papers on: – An overview of the HL7 tools Model Interchange Format (MIF) – A proposal/plan for HL7 Requirements, Configuration and Deployment Management – A proposal/plan for HL7 Product Evaluation and Recommendation – HL7 Tools Architecture and Policy Framework 24 March, 2004 Copyright 2004, HL7 70 V3 tools taskforce A major revision (from HL7 UK) to the design tools will be made available to HL7 in the next several months, including some (tbd) of: – Design Repository (with check-in-out functions, designs in Model Interchange Format) – Automated model comparison tool (MIF Diff) – Message Schema Validation – One-click round trip from VISIO to/from Schema – Automate Visio validation to test specifications for completeness 24 March, 2004 Copyright 2004, HL7 71 V3 tools taskforce – Other affiliate projects include: • MIF design and implementation (current) (Lloyd McKenzie and others) – Allows interoperability with Off The Shelf UML xml-based tools, plus interoperability between various HL7 v3 tools (encourages the development of new v3 tools) • CMET-related features/functionality enhancements Project – Lloyd McKenzie and Ben van de Walle, also of HL7 Canada 24 March, 2004 Copyright 2004, HL7 72 Localization & Refinement principles Once an HL7 specification has been balloted and formally published, it may be further constrained for a variety of purposes, including: – definition of a region-specific profile by an HL7 International Affiliate – documentation of a profile for use in communities of interest (for example, a set of collaborating health care institutions, a community of vendors or an external standards organization) – definition of a profile for a specific project – creation of profiles to define a vendor's capability or a consumer's requirements – definition of content templates to be used when communicating HL7 messages 24 March, 2004 Copyright 2004, HL7 73 “realm” specific “localizations” • The HL7 Affiliate Organizations, working through the International Committee, studied localization and produced a report entitled "Localizing the HL7 Version 3 Standard." • This report, which has been reviewed and adopted by the HL7 Board of Directors for use by the affiliate organizations, is the basis for this part of the v3 ballot (and is now normative). 24 March, 2004 Copyright 2004, HL7 74 realm-specific profiles • These can be created via an Affiliate process that includes both the constraint process listed above, and an extension process that adds new concepts to the base, balloted message type – extensions must be produced by the same constraint processes that generates messages, CMETS, vocabulary restrictions from the RIM (and its vocabulary), and datatype constraints (under development) – affiliate-level ballot and registration requirements are defined • consistent with affiliate agreement and HL7 v3 methodology • Useful, global concepts are encouraged to be brought back into ‘global’ HL7 v3 24 March, 2004 Copyright 2004, HL7 75 realm-specific profiles • informal extensions are allowed at the ITS (implementation technology specification) only. – – – They cannot alter the intent of the standard message There must exist a site-specific agreement The ITS must support their “isolation” within the message 24 March, 2004 Copyright 2004, HL7 76 Localization & Refinement principles Summary: For “International” affiliates. – Vocabulary Realm concepts for • Vocabulary domains for specific attributes (e.g. Act.code) – In addition to localizations for • ‘abstract information artifacts’ such as – RMIMS – HMDS (Hierarchical Message Definitions) – MTs (Message Types) – A web-based EB-XML registry is being created for both HL7 “global” and “affiliate” profiles, as well as “early adopter” profiles 24 March, 2004 Copyright 2004, HL7 77 Early Adopters Forum • Administered by the Implementation Committee (see below) • Encourages v3 early adopters to share experiences – Lessons learned in specific domains – Problem-solving for common areas and specific areas – Suggestions for additions to the v3 global ‘core’ • Includes – Email list – Presentations to various TCs and SIGs at the HL7 WG meetings – Use of EBXML Registry for conformance artifacts • Also includes many international affiliate projects (see below) 24 March, 2004 Copyright 2004, HL7 78 V3 Implementation committee • A focus is “v3 for implementors” • Projects being discussed include: – Creating v3 implementation documents • Current v3 materials are ‘v3 for message designers’ • focus on how to understand and use the v3 XML-ITS for message implementors, with examples from Early Adopters Forum – creating v3 conformance methodology guide (like the corresponding v 2.x guide) • Will include many affiliate projects (see below) 24 March, 2004 Copyright 2004, HL7 79 Contributions from International affiliates V3 ballot major contributions include • Infrastructure areas – Datatypes (Australia), Queries (The Netherlands), EBXML transport specification (Canada), XML-ITS (UK) • Claims and reimbursements (e-claims) (Canada) • Pharmacy messaging and vocabulary (United Kingdom) • Vocabulary (“realm” specifications and balloting procedures) (all affiliates) • XML ITS (Australia, Canada, Germany, United Kingdom) 24 March, 2004 Copyright 2004, HL7 80 Contributions from International affiliates V3 ballot major contributions include • EHR Functional Requirements – Affiliates include: UK, Canada, Australia, and “USA” • CDA release 1 and 2 (under development) – Germany, Finland, Greece, “USA” 24 March, 2004 Copyright 2004, HL7 81 AffiliateV3 implementation projects A partial list: • Australia: – patient care and referrals, V3 technical infrastructure • Canada: e-claims, V3 tools – BCE Emergis: v3 e-claims live implementation for Chiro/Physio Claims for WSIB (Ontario Workers Comp), patient (client) and provider registries, Clinical Pharmacy, BC Lab Orders/Results (under development), • UK: – NPfit: National “Spine” ECR supporting E-booking, Eprescribing, lab requests and reports, images, allergies, problems, current medications, etc. • Germany, Finland, the Netherlands, Greece: – Clinical Document Architecture 24 March, 2004 Copyright 2004, HL7 82 AffiliateV3 standards projects A partial list: • Argentina, Mexico, Spain: – Spanish translation begun, web-based education • Mexico – Blood Bank • The Netherlands: – Perinatal Project, National Patient Registry, National Electronic Patient Record, Query and scheduling infrastructure (under development) • USA – Public Health Reporting, Adverse events, Annotated EKG 24 March, 2004 Copyright 2004, HL7 83 Notes on the Transition to v3 • Current ‘lessons learned include – Existing v 2.x implementations: “if it ain’t broke, don’t fix it” – But for new domains, start with v3 – For implementations requiring large scale integration (city, region, province, nationwide, international), v3 has ‘builtin’ support • Structural ontology guaranteeing interoperability and re-use: RIM and datatypes, integrated vocabulary support • Identifier strategy supporting wide integration • Model and Tools based design and implementation – If you need decision support, you’ll need v3 • The same information is represented the same way everywhere using the RIM with the binding to structural and standard vocabularies 24 March, 2004 Copyright 2004, HL7 84 Notes on the Transition to v3 • Translation from v 2.x: lessons learned – It is possible, and often desirable when existing v 2.x data is needed for a v3-based project – But it requires resolving the ambiguities inherent in v 2.x implementations; – If the MWB conformance profile exists already, that is a significant advantage, though it will not completely resolve the v 2.x model and vocabulary ambiguities – You’ll need to resolve the same wide-scale implementation issues as needed for v3: • Vocabulary bindings (structural and standard) • Datatypes and identifiers – A quote from the field: “I never fully understood v2.x until I understood v3” (in the context of a project mapping a 2.x conformance specification into a v3 conformance specification) 24 March, 2004 Copyright 2004, HL7 85 Of related international interest: HL7 and IHE For HIMSS 2004, HL7 and IHE cooperated on a very successful joint interoperability demo. There are plans to internationalize this demo after HIMSS 2004. URLs: • On www.hl7.org page under resources, select “HL7 IHE Joint Demo 2004” • Or go directly to http://129.41.58.87/html/index.htm 24 March, 2004 Copyright 2004, HL7 86 HL7/IHE Joint Demo HIMSS 04 The joint demonstration planned to feature healthcare scenarios such as: • identifying an adverse drug event and preventing medication errors • notifying the Food & Drug Administration and sponsors of clinical trials • viewing clinical reports with links to related images, • integrating electronic records with public health reports • driving the capture of patient charges, billing and claims attachments from clinical observations 24 March, 2004 Copyright 2004, HL7 87 …finis… • Questions? • Thank you! 24 March, 2004 Copyright 2004, HL7 88 Part II: Using v3 • A practical overview of the RIM and the version 3 methodology and Design tools. • Browsing the RIM: Rosetree example, including Structural Vocabulary • Alternate representations of the RIM in the v3 ballots: – Graphical – Textual – Vocabulary 24 March, 2004 Copyright 2004, HL7 89 A walk through a version 3 ballot • Overall organization – Informative documents on v3 – Where to find things • Standard Table of contents • DMIMS and RMIMS, HMDS and Message Types, Schemas • Interactions – A very quick tour of the datatypes – Common (message) element types -- reusable model patterns (and their relationships to message and API models, and to archetypes and templates) 24 March, 2004 Copyright 2004, HL7 90 Visio Designer • A walk through the Visio tools, featuring: – A look at an RMIM or two, such as: • Observation DMIM/CMETS/Event • CDA-Release 2/Clinical statements 24 March, 2004 Copyright 2004, HL7 91 Questions/Discussion topics • If time permits: – When is v3 “done”? – How do I represent a new domain in v3? (MDF/HDF process)? – What changes can an affiliate make to the global standard? – What about Vocabulary in different countries/jurisdictions? – What are the implementation/development considerations – How can I learn from the early adopters program? 24 March, 2004 Copyright 2004, HL7 92 Where can I get these tools? • See companion notes in: v3materials.instructions.march.2004.doc 24 March, 2004 Copyright 2004, HL7 93 THANK YOU! • Are there any last questions? --send them to: mark.shafarman@oracle.com 24 March, 2004 Copyright 2004, HL7 94