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

2. 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

3. 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

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

5. 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

6. 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. 2 94 pages

7. 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

8. J. M. Smith CESO April 28, 2004

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

10. 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

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

12. 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:

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

14. 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)

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

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

17. 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

18. 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

19. 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

20. 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

21. 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

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

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

24. 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

25. 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

26. 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

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

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

29. 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

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

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

32. 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

33. 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

34. 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”

35. 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