J. M. Smith CESO April 28, 2004 Communication jej tajwIj, jej mInwIj je Heghbej muqaDbogh Hoch Klingon Language Institute  Language  Lexicon  Syntax  Semantics

J. M. Smith CESO April 28, 2004 Communication Standards  A standard is an agreement which may be voluntary, government mandated, or International law  Standards allow devices and systems from different vendors to communicate with each other  Standards encourage the dissemination of communications technology  Standards reduce the cost of communications

J. M. Smith CESO April 28, 2004 Examples of communications standards  HL7 application layer health information clinical data communication  DICOM 3.0 image communication  Ethernet  TCP/IP  RS 232 serial communication

J. M. Smith CESO April 28, 2004 Scheduled Workflow

J. M. Smith CESO April 28, 2004 Integrating the Healthcare Enterprise - IHE  A Framework for the operation and integration of existing standards, in particular HL7 and DICOM  Consensus view of data fields/objects that need to be communicated  Identification of use workflow profiles/scenarios  Conformance testable  Approaches plug and play

J. M. Smith CESO April 28, 2004 Integrating the Healthcare Enterprise - IHE  Standards based communication between systems  Actors: perform communications roles between systems  Transactions: messages sent between systems  Integration Profiles: grouping of actors and transactions to perform specific workflows Note: IHE IT Technical Infrastructure Vol pages

J. M. Smith CESO April 28, 2004 IHE Integration profiles Access to Radiology Information Consistent Presentation of Images Scheduled Workflow Basic Security - Evidence Documents Key Image Notes Simple Image and Numeric Reports Presentation of Grouped Procedures Post- Processing Workflow Reporting Workflow Charge Posting PatientPatient InformationInformation ReconciliationReconciliation

J. M. Smith CESO April 28, 2004

J. M. Smith CESO April 28, 2004 Grouped Procedures

J. M. Smith CESO April 28, 2004 What Does IHE Offer?  Systems Integration  To achieve clinical goals  Using non-proprietary methods  Improve the efficiency and effectiveness of clinical practice by:  Improved Information Flow  Advanced Multi-System Functions  Reduction of errors

J. M. Smith CESO April 28, 2004 IHE Availability Integration Profiles Vendors

J. M. Smith CESO April 28, 2004 Contract language examples The RIS shall meet the requirements of the IHE Technical Framework for the following profiles:The RIS shall meet the requirements of the IHE Technical Framework for the following profiles:

J. M. Smith CESO April 28, 2004 ISO Reference Model  ApplicationFile transfer,  PresentationData formatting  SessionSynchronisation  TransportEnd to end communication  NetworkInternetworking  Data linkEthernet FDDI  PhysicalFiber, coax, UTP, microwave

J. M. Smith CESO April 28, 2004 Health level 7 (HL7)  Primary Goal  To provide standards for the exchange of data among health computer applications that eliminates or substantially reduces the custom interface programming and program maintenance that would otherwise be required  Related Goals  Independence of programming languages and operating systems  Support of a variety of environments from a full OSI compliant 7 level stack to point to point communication using RS 232  Support single and multiple transactions  Accommodation of site specific data elements and site specific message segments (Z segments)

J. M. Smith CESO April 28, 2004 HL7 Messages

J. M. Smith CESO April 28, 2004 HL7 and Philips PDI

J. M. Smith CESO April 28, 2004 Characteristics of HL7  Interoperability  Ability of two or more systems to exchange information…(functional interoperability)  Formatting so that parsing can take place at receiver end  and to use the information that has been exchanged (semantic interoperability)  Sender and receiver share a common model and use a common set of terms  Facilitates selection of best of breed

J. M. Smith CESO April 28, 2004 HL7: Limitations  Diversity within healthcare prevents the development of a data model to support a definition of HL7’s target environments  HL7 does not make a priori assumptions about the architecture of healthcare information systems, nor does it attempt to resolve architectural differences between healthcare information systems  Therefore HL7 cannot be a true “plug and play” standard  Standard is intended to standardise data interchanges, not application systems

J. M. Smith CESO April 28, 2004 HL7: Features  It conforms to conceptual definition of an application to application interface placed at the seventh level of the ISO model. Lower level protocols may also be used  It addresses interfaces among various systems that send or receive patient ADT data, queries, orders, results billings and master file updates  It does not assume any particular architecture re the placement of data within applications  It is a structure for the communication of information between applications, and the events triggering it  It cannot guarantee transparency for lower level protocols  HL7 does not follow ANSI Basic encoding rules  HL7 is simplifies and aimed at programmers with limited skills

J. M. Smith CESO April 28, 2004 HL7: Encoding Rules  Data fields of variable length are accommodated as HL7 recognises field separator characters  Rules define how various data types are encoded within a field  Data fields are combined into logical groupings called segments  Segments are separated by a segment separator  Individual fields are found in the message by their position within the segments  Null values set result to null; no data leaves current data intact

J. M. Smith CESO April 28, 2004 HL7: Control / Query  An event in the health care environment creates the need for data flow among systems  Upon admission, there will be a need for ADT data to flow to a number of other systems  These are unsolicited updates  Acknowledgement of receipt is required: i.e. the receiving application has accepted responsibility for the data  Applications may initiate queries to another application: e.g. for ADT data

J. M. Smith CESO April 28, 2004 HL7: Message types  Admission Discharge and Transfer  Order Entry  Finance  Observation Reporting  Master Files

J. M. Smith CESO April 28, 2004 Examples of ADT Messages

J. M. Smith CESO April 28, 2004 HL7: Messages  A message comprises a group of segments in a defined sequence  Each message has a message type that defines its purpose  A segment is a logical grouping of data fields  Each segment is given a name: for example  An ADT message may contain the following segments: Message Header; Event type; Patient ID and Patient visit  Data fields:  Segments comprise fields separated by field separators  A data dictionary defines HL7 fields  Z segments contain site specific fields  Fields have attributes defined by the standard

J. M. Smith CESO April 28, 2004 HL7: Data types  HL7 Supports many data types  String data  Text data (for display)  Formatted text data  Numeric data  Date and time  Time stamp  Person name  Telephone number  Address  ID coded value (e.g. religion and sex)  Other special purpose data fields

J. M. Smith CESO April 28, 2004 Supporting Lexicons: LOINC  Logical Observation Identifier Names and Codes  >26,000 laboratory and clinical observations and claims attachments  Universal identifier for laboratory and clinical observations allowing correlation in databases  Used as Observation ID in HL7 messages, removing ambiguity  Topple the Tower of Babel

J. M. Smith CESO April 28, 2004 HL7 without LOINC

J. M. Smith CESO April 28, 2004 HL7 with LOINC

J. M. Smith CESO April 28, 2004 Supporting Syntax: Arden Syntax  Setting the stage for Clinical Decision Support (CDSS)  Use of Medical Logic Models (MLM) in CDSS knowledge bases  Use of Arden Syntax in MLMs  Arden Syntax is used to structure knowledge representation  Standardization allows communication and sharing  HL7 standard for defining and sharing medical knowledge base information  Future use of XML for encoding MLMs

J. M. Smith CESO April 28, 2004 Practical applications

J. M. Smith CESO April 28, 2004 Electronic Child Health Network eCHN

J. M. Smith CESO April 28, 2004 Why HL7 V 3?  V 2.x weaknesses addressed in V 3  Too many options  Ambiguous definitions  Cannot specify or automate testing of conformance  Complicated esoteric coding rules  No standard vocabulary

J. M. Smith CESO April 28, 2004 The Move to V 3  Need for version 3 which supports semantics  Reference model and set of terminology domains  Every happening is an “ACT” (procedures/observations etc.)  Participation defines the context for an ACT (author/performer)  Participants are roles (patient/provider etc.)  Roles are played by entities (people/materials/institutions etc.) Note: The Message Development Framework for HL7 V3.3 is 344 pages long

J. M. Smith CESO April 28, 2004 HL7 V3.x Features  More trigger events and more message formats  Object oriented development methodology based on XML  Uses Reference Information Model that:  Provides explicit representation (semantic and lexicon)  Draws on codes and vocabularies from many sources  Unambiguous understanding of code definitions and code values  Testable and allow definition of conformance  More amenable to changes in clinical practice  Approaches “plug and play”

J. M. Smith CESO April 28, 2004 Acknowledgements and Follow up  CIHIwww.cihi.ca  HL7 Canadawww.cihi.ca  RSNAwww.rsna.org  IHEwww.rsna.org/IHE  HIMSSwww.himss.org  eCHNwww.echn.ca  SCARwww.scarnet.org  Klingon Language Institutewww.kli.org  OSU