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

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

CommunicationCommunication

jej tajwIj, jej mInwIj je Heghbej muqaDbogh Hoch

Klingon Language Institute

LanguageLexiconSyntaxSemantics


Communication StandardsCommunication 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


Examples of communications Examples of communications standardsstandards

HL7 application layer health information clinical data communication

DICOM 3.0 image communication Ethernet TCP/IP RS 232 serial communication


Scheduled WorkflowScheduled Workflow


Integrating the Healthcare Integrating the Healthcare Enterprise - IHEEnterprise - 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


Integrating the Healthcare Integrating the Healthcare Enterprise - IHEEnterprise - 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


IHE Integration profilesIHE 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 PostingP

atient

Information

Reconciliation



Grouped ProceduresGrouped Procedures


What Does IHE Offer?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


IHE AvailabilityIHE AvailabilityIntegration Profiles

Ven

do

rs


Contract language examplesContract language examples

• The RIS shall meet the requirements of the The RIS shall meet the requirements of the IHE Technical Framework for the following IHE Technical Framework for the following profiles:profiles:

Integration Profiles

Actors Options Implemented or available

Scheduled Workflow

Order Filler none

Charge Posting Order Filler None

Secure Node None Basic Security

Order Filler


ISO Reference ModelISO Reference Model

Application File transfer, E-mail Presentation Data formatting Session Synchronisation Transport End to end communication Network Internetworking Data link Ethernet FDDI Physical Fiber, coax, UTP, microwave


Health level 7 (HL7)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)


HL7 HL7 MessagesMessages


HL7 and Philips PDIHL7 and Philips PDI


Characteristics of HL7Characteristics 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


HL7: LimitationsHL7: 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


HL7: FeaturesHL7: 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


HL7: Encoding RulesHL7: 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 segmentsNull values set result to null; no data leaves current data

intact


HL7: Control / QueryHL7: 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


HL7: Message typesHL7: Message types

Admission Discharge and Transfer Order Entry Finance Observation Reporting Master Files


Examples of ADT MessagesExamples of ADT Messages

Event Types

Description Event Types

Description

A01 Inpatient admission A41 merge account - patient account number

A02 Inpatient Transfer A42 merge visit - visit number

A03 Inpatient Discharge A43 move patient information - internal ID

A04 Register an outpatient A44 move account information - patient account number

A05 Pre-admit/ Pre-register A45 move visit information - visit number

A06 Outpatient to Inpatient Conversion A46 change external ID

A07 Inpatient to Outpatient Conversion A47 change internal ID

A08 update patient information (Delta only). A48 change alternate patient ID

A09 patient departing - tracking A49 change patient account number

A10 patient arriving - tracking A50 change visit number

A11 cancel admit / visit notification A51 change alternate visit ID

A12 cancel transfer A23 delete a patient record

A13 cancel discharge / end visit A24 link patient information

A14 pending admit A25* cancel pending discharge

A15 pending transfer A26 cancel pending transfer

A16 pending discharge A27* cancel pending admit

A17 swap patients A28 add person information

A18 merge patient information A29 delete person information

A19 patient query A30 merge person information

A20 bed status update A31 update person information

A21 patient goes on a "leave of absence" A32 cancel patient arriving - tracking

A22 patient returns from a "leave of absence" A33 cancel patient departing - tracking


HL7: MessagesHL7: 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


HL7: Data typesHL7: 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


Supporting Lexicons: LOINCSupporting 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


HL7 without LOINCHL7 without LOINC


HL7 with LOINCHL7 with LOINC


Supporting Syntax: Arden SyntaxSupporting 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


Practical applicationsPractical applications


Public InterneteCHN secure intranet

Firewall

Physician's office

Patients and parents

Wellnessdatabase

eCHNpublic

Web site

MasterPatientIndex

St.Elizabeth

Orillia

HSCSt.

Joseph Centenary

eCHNprofessional

Intranet

Physician's office

Externalagencies

MOH,CIHI,

ICES, etc.

Electronic Child Health Network eCHN


Why HL7 V 3?Why HL7 V 3?

V 2.x weaknesses addressed in V 3

Too many optionsAmbiguous definitionsCannot specify or automate testing of conformanceComplicated esoteric coding rulesNo standard vocabulary


The Move to V 3The 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


HL7 V3.x FeaturesHL7 V3.x Features More trigger events and more message formats

Object oriented development methodologybased 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”


Acknowledgements and Follow upAcknowledgements and Follow up

CIHI www.cihi.ca HL7 Canada www.cihi.ca RSNA www.rsna.org IHE www.rsna.org/IHE

HIMSS www.himss.org eCHN www.echn.ca SCAR www.scarnet.org

Klingon Language Institute www.kli.org OSU