Software Interoperability of Telemedicine Systems : ACSCW Perspective

Pronab Ganguly & Pradeep RaySchool of Information Systems, Technology and Management,

University of New South Wales, Kensington,NSW 2052, Australia

*Tel: 61 2 9385 5803, Fax: 61 2 9662 4061; Email: p.ganguly@unsw.edu.au+Tel: 61 2 9385 5890, Fax: 61 2 9662 4061; Email: p.ray@unsw.edu.au

AbstractComputer Supported Cooperative Work (CSCW)provides a fusion of the understanding oforganisational processes with communicationtechnologies. Telemedicine involves an integration ofnetworking technologies with health-care processes.Since different modalities of patient care requireapplications running on heterogeneous computingenvironment, interoperability is a major issue intelemedicine. Software interoperability provides twodistinctly classified benefits – benefits for the users ofthe system and benefits to the development andmaintenance of the system. Software interoperabilitybetween different applications can be modeled atdifferent levels of abstractions such as physicalinteroperability, data-type interoperability,specification-level interoperability and semanticinteroperability. Various mechanisms exist to resolvethe problem at different levels. This paper presentsthe design issues of an interoperable CSCW system ina distributed health-care environment through anillustrative study in the area of telecardiology.

1. IntroductionComputer Supported Cooperative Work(CSCW) provides a fusion of theunderstanding of organisationalprocesses with communicationtechnologies. Groupware, workflows anddistributed object technologies arebeing used to design and implement CSCWsystems. This paper presents designissues for a CSCW system indistributed health-care environment.Communication technologists study thisarea as “telemedicine”. Telemedicineinvolves an integration of networkingtechnologies with health-careprocesses. Telemedicine applicationsare classified as telecardiology,telepathology, telepsychology etc.depending on the discipline of health-care. Most

computerised health-care applicationsare traditionally stand-aloneapplications without integration. Inorder to integrate telemedicine

services to distributed framework,various healthcare applications runningon heterogeneous platforms mustinteract through softwareinteroperability mechanisms. Softwareinteroperability may be defined as “thecapability with which two or moreprograms can share and processinformation irrespective of theirimplementation language and platform.”[4].The interoperability problem intelemedicine is manifested in patientmonitoring, diagnostic, decisionsupport and communication systemsneeded at the point of care. Forexample, one can consider a typicaldistributed health-care scenario withradiology application supported byDigital Imaging and Communication inMedicine (DICOM) standard, thepathology laboratory applicationrunning on Health Level Seven (HL7)standard , the pharmacy applicationrunning on a Unix server, and thepatient repository in generalphysician’s practice in Windows NTenvironment. So heterogeneity innetworked computing environment iscommon in telemedicine. Softwareinteroperability provides necessarymechanism to integrate these disparatebut related resources into a singlecomputational environment to achieveeffective resource utilization. The organisation of the paper is asfollows. The next section Section 2describes the distributed ECG analysisframework. Section 3 presents anoverview of the interoperabilityproblem. Section 4 briefly describesthe component object model and ActiveXfor healthcare framework. The section 5details the prototype implementationand the concluding section describesthe scope of further research areas.

2. The Process of Distributed ECG– A Telecardiology Application

2.1 Electrocardiogram andTraditional Framework:

The ElectroCardioGram (ECG) issignature of the heart and recordsvoltage changes transmitted to the bodysurface from electrical events in theheart muscle. It provides directevidence of cardiac rhythm andconduction as well as indirect evidenceof certain aspects of myocardialanatomy, blood supply and function.Electrocardiography has been used formany years as a key, non-invasivemethod in diagnoses and early detectionof coronary heart disease, which is theleading cause of mortality in manycountries.One of the aspects of telecardiologyknown as tele-electrocardiographydeploys ECG machines to transmit ECGsover a network. Various researchstudies show that tele-electrocardiography diagnosis and ECGinterpretation is simple, reliable andsubstantially cheaper in cost incomparison to conventional referralsystem [7]. ECG computer processing canbe reduced to four principal stages: Data acquisition Encoding, transmission and storage Pattern recognition and feature

extraction Diagnostic classification:In the last two stages, a knowledgerepository is used by humanspecialists. Presently, such knowledge-repositories are made available withECG equipment in vendor proprietaryform in a tightly integrated manner. Ithas been suggested that the quality ofcomputer assisted ECG interpretation isperhaps better than that of generalphysicians, and such computerisedinterpretation is comparable with areview provided by a professionalcardiology service [8].

A typical framework [6] for theimplementation of atelelectrocardiography system with acommercially available ECG machinesinvolves the following activities: Acquisition of raw ECG data Presentation of ECG data in a

proprietary format to a proprietaryknowledge repository

Transmission of ECG data to healthinformatics network

Transmission of ECG diagnostic fromthe knowledge repository to a healthnetwork

But this scheme places the knowledgerepository with the ECG dataacquisition instrumentation. The higherthe quality of the knowledgerepository, the higher is the cost ofthe ECG machine. This cost andaccessibility can be improved byseparating the ECG instrumentation fromits present tightly integratedknowledge-base and sharing theknowledge-base over a network.

POINT OF NEED

SupervisoryCardiologyStation

ECG ADD-ON MODULE

ECGINTERPRETA-TIONREPOSITORY 1

HL7 HEALTH NETWORK WITHSTANDARD INTERFACE

Computerized Patient Record Repository and Further Cardiac Care Service Provider

Figure 1: Distributed Framework for ECGDiagnostic System

2.2 Distributed Framework of ECGAnalysis

Figure 1 shows a distributed frameworkfor a tele-electrocardiography system.Here the point-of-need user with thehelp of front-end ECG machine accessesand invokes the distributed knowledgerepository over the network. Theinterpretation repositories diagnosethe ECGs on-line, and forward the ECGdata along with multipleinterpretations to the on-linesupervisory cardiologist. For normalcases, results are distributed by theSupervisory Cardiology Station to thepoint-of-need and to the computerisedpatient record system over the network.For abnormal cases, further cardiaccare service provider is also alerted.The various issues related to thisdistributed framework of ECG analysisand its advantages over traditionalframework is reported in [6] .In this framework, different usersmight use heterogeneous computingplatforms, such as the point-of-needuser might use Windows NT platform witha compatible set of applicationsoftware whereas the SupervisoryCardiology Station might use Unixcomputing environment with a differentset of application software. The otherbuilding blocks in the framework mightuse various other computing platformsas well. These different computingplatforms need to interconnect, sharedata and act cooperatively with eachother. Hence there is the need forinteroperability in a telecardiology

environment. In this application, thekey issues related to interoperabilityare: How to support the interoperability

between various platforms runningdifferent parts of the application?

How to support interoperability witha pragmatic approach, using relevantstandards for ECG data andknowledge repository?

Various issues related to healthcareinformatics standards are reported in[8].

3. The Interoperability ProblemDifferent parts of a large telemedicinesystems are from various vendors, whouse different standards and informationformats. These systems are also used bypeople with different levels ofexpertise and need. As a result,interoperability of these systemspresents serious problem. Once theinteroperability problem is solved, thedevelopment and maintenance of largetelemedicine systems can be streamlinedwith data reuse, code reuse,application reuse and choice of anappropriate computing environment,using object-oriented technology.A software interoperability problem canbe viewed from following perspective[4]:

3.1. Physical Interoperability

In the first approach, theinteroperability is achieved byphysically transferring informationthrough compatible electronic mediasuch as floppy disks or magnetic tapes.

3.2. Data-type Interoperability

In the second approach, the focus isonly on the content and structure ofthe information exchanged or shared. Inour application, the format andpresentation of the data (such as ECGresults) will be such that the datastored in one program on one machine

ECGINTERPRETA-TIONREPOSITORY 2

can be used in other machines and inother application programs. Forexample, all information may be storedin html for web based access.

3.3. Specification-level Interoperability

In specification-levelinteroperability, application sharingthe data need not know the finerdetails of the aggregate data typeinformation. For example, in ourapplication, ECG data can be storedeither in a single- dimension array orin a multi-dimensional array.Applications sharing the data need notknow the finer details and treat theentity as a whole [4]. ObjectManagement Group’s (OMG) Common ObjectRequest Broker Architecture (CORBA) andMicrosoft Component Object Model (COM)provide means for achieving such anobjective.

3.4. Semantic Interoperability

Applications can also exchangeinformation at a semantic level. Inthis approach, a system is designed to

use different abstract views of sharedentities. This model inherentlyrepresents design intent, behavior andstructured description of the entities.In case of our application, thedifferent distributed applicationsshould be able to share and useknowledge generated by otherapplications. Intelligent agents play

an important role in this task. This isa subject of research worldwide.

4. Interoperability based on a Distributed Object Model

As discussed in Section 3.3,distributed object models, such as OMGCommon Object Request BrokerArchitecture (CORBA), Sunsoft JavaRemote Method Invocation (RMI), andMicrosoft Distributed Common ObjectModel (DCOM) provide mechanisms forinteroperability across systems usingdifferent operating systems,programming languages, and networkprotocols. This paper will now discussour work based on Microsoft DCOM objectenvironment. In this model [9], theinteroperable software is encapsulatedwith object-oriented interfaces. DCOMis based on the Open SoftwareFoundation’s DCE-RPC specifications anduses Component Object Model (COM)[9],[10].

4.1 ActiveX for Healthcare

ActiveX for Healthcare is acollaborative work amongst Microsoft,Andover Working Group[2] and HealthLevel Seven (HL7) [5] body. It isdesigned to provide easiest and lessexpensive interoperability betweenhealthcare applications and systems.

PatientDetails

KnowledgeReposito

Point of need

ECGdata

SupervisoryStation

KR1 KR2

Figure 2 Brief Use Case Diagram for Distributed ECG Systems

Active X provides a framework involvingDCOM communication environment, anddifferent levels of infrastructureobjects defined for the ease ofimplementation of a distributed objectbased systems. ActiveX is the keybuilding block for interaction betweenapplications and services – whether onthe same machine, on a local network,or over the Internet. ActiveXcomponents can be written in anylanguage and deployed across multipleoperating systems. These freely licensed components andimplementation guidelines are based onthe work done by the Special InterestGroup on Object Brokering Technologies(SIGBOT) of HL7 and specifies the HL7message profiles and ActiveX-basedversion of the messaging applicationprogramming interface (API) developedby Andover Working Group. Therelationship between Enterprise

Communication Framework (ECF) developedby Andover Working Group [2] andActiveX is represented by figure 4 [1].The ActiveX for Healthcare (AHC)Messaging Components encapsulate HL72.3 message into objects and make iteasy to connect various systems.Applications simply request theappropriate object (e.g., an admissionor a medication order), add theappropriate data elements andtransparently send the object toapplications which are configured toreceive it. A flexible architectureallows a migration path from legacysystems and interface engines tonetworked, component basedapplications. Applications can sendmessages via DCOM to another ActiveXapplication, or across a TCP/IPconnection to an existing HL7compatible application.

5. Prototype Implementation 5.1. Distributed Telecardiography

in UML

The Unified Modelling Language (UML),considered to be the de-facto-standardobject modelling language in industry,is a technique to specify, visualiseand document the artifacts of anobject-oriented system underdevelopment. For this application , the followingactors are identified: Point-of-need User ( Creator ) Knowledge Repository ( KR )

(Tracker ) Supervisory Station ( Manager )

Patient Record & Further Care( Archivist)

The Use Cases for this application arePatient details, ECG data,Interpretation Report, Normal Diagnosisand Abnormal Diagnosis.In UML, an actor is defined as the userof the system whereas A Use Case is ascenario that actor carries out. A

Supervisory Station

Abnormal Diagnosis

Interpretation

NormalDiagnosis

Point-of-need Patient

record & Further Care

brief description for each use case isas follows:

KR Ecg Analysis Module Interpretation Report

Schedule Analysis

Patient details

Ecg Details Ecg Interpretation

Figure 3: Brief Sequence Diagram for theApplication

Generic Middle-ware

Operating Systems

Figure 4: Relation between ECF and ActiveX

Use Case: Patient Details- Actors: Point-of-need User, KnowledgeRepository, Supervisory Station- Description: The point-of-need Useracquires and submits patient details toKnowledge Repository and SupervisoryStation. Both KR and SupervisoryStation log this information.

Use Case: ECG data- Actors: Point-of-need User, KnowledgeRepository- Description: The point-of-need Useracquires and submits the ECG data toKnowledge Repository. The KR logs andinterprets this information. Use Case: Interpretation Report- Actors: Knowledge Repositories,Supervisory Station- Description: Once the ECG isinterpreted, the ECG data andinterpretation report are presented toSupervisory Station. Use Case: Normal Diagnosis- Actors: Supervisory Station, Point-of-need User, Patient Record and Further Care- Description: The Supervisory Station

diagnoses the ECG and distributesthe diagnosis to Point-of-need Userand Patient Record &Further Care.

Use Case: Abnormal Diagnosis- Actors: Supervisory Station, Point-of-need User, Patient Record & Further Care.- Description: Additionally Further

Care is alerted to initiate action. The Overviews of the Use Case andsequence diagram are shown in Figure 2and 3.The general scenario in ActiveX forHealthCare (AHC) for an applicationis[9]: Connect to the AHCMessenger

component Request a blank message object (such

as a HL7 2.3 admission or order) Add appropriate data elements Request message to be sent by the

AHCMessenger component to adestination.

Poll for incoming messages or handlecallback requests.

Disconnect from the AHCMessengercomponent

5.2. Prototype System

For our local area network prototypeimplementation, we have used Visual

Healthcare Application

Enterprise Communicator

CORBA ActiveX

Basic version 5 with AHC version 1.1 inMS-Windows environment. Selectedmessages from HL7 2.3 have beenincorporated in HL7 message factory. Asthis architecture allows for multiplemessage factories, other requiredmessages can be implemented in asimilar fashion.

5.3. Major Programming Modules

Following modules are used for thetele-electrocardiography applicationusing the HL7 message objects whereverpossible. Patient Demography – This class used toexchange information about point-of-user need.ECG information – This class is usedfor acquiring, defining and updatingECG information related to point-of-need user.

Figure 5: Major Modules Diagram for theApplication

Knowledge Repository ( KR ) – Thisclass is used for interpretation ofECG.Supervisor – This class is used togenerate diagnostic report of ECG.Further care – This class is used toinitiate further cardiac care servicein case of abnormal ECG.Diagnostic report – This class is usedto generate diagnostic report. Figure 5 shows the major programmingmodules and their interactions. In thisdiagram, the top box is the name of theclass. The sign represents attributewhereas represents behavior. It maybe noted that HL7MsgORU needs to bemodified to include waveform.

5.4 Sample Code for MessageTransmission

The sample code for sending a messagein Visual Basic is given below [10]:‘Create an AHCMessageType object

Dim msgType As New AHCMessageType‘Identify the type of message byfilling in the properties of the object

msgType.Version = "HL7 2.3"msgType.MessageTypeCode = "ADT"msgType.EventCode = "A28"‘Declare a HCMessageEnvelope andcall the CreateMessage method on‘HCMessageManagerDim msg As HCMessageEnvelopeSet msg =msgman.CreateMessage(msgtype)

‘Declare a message object of the typecreated in the previous ‘step and get ahandle to the ‘message content.

Dim a28 As HL7MsgADTA28Set a28 = msg.Content

‘Fill in the message information.

KR ID Analyse_

Ecg()

Supervisor

ID Diagnosis()

Further Care

ID Further_care(

DiagnosticReport

ID HL7Msg

ECG Information

ID Get_Ecg() Format_Ecg()

Patient Details

IDHL7MsgADT

A01()HL7MsgADT

a28.PatientIdentification.PatientName.Add(1)a28.PatientIdentification.PatientName.Item(0).GivenName = “Viral”a28.PatientIdentification.PatientName.Item(0).FamilyName = “Desai”

‘Call the SendMessage method on theHCMessageManager interface passing itthe ‘HCMessageEnvelope interface.Either specify the destinationapplication name or ‘allow theHCMessenger object to use a defaultdestination. Keep track of the message‘ID returned from the SendMessagemethod.uuid = msgman.SendMessage(msg,“DestinationApp”)‘Call the DoneWithMessage method forthe message object.

msgman.DoneWithMessage msgSet a28 = NothingSet msg = Nothing

5.5. Experiences of PrototypeDevelopment

The following observations are madeduring the development of prototypesystem: There were memory leaks while the

application is running for sometime. This is a known problem in AHCversion 1.1 which was subsequentlyrectified in later version.

As blocking RPC is used to moveinformation between networkedmachine, if the destinationapplication is not available duringsending of information – the sendingapplication sometimes hang. This wasavoided by running the applicationson different threads.

AHC is still under evolution andnot mature enough. Some newfunctionalities of HL7 are yet to beintegrated into AHC. For example, wehad to build our own messages toexchange ECG data – though thecomponents follow generalguidelines.

Figure 6: Snap-shot of a User Screen

Since HL7 does not yet cover someapplication aspects, such asknowledge repository interface forthis particular applicationscenario, we had to build our ownmessage format as per the generalguideline of HL7.

Although DCOM is available on a fewnon-Microsoft platforms, it isrealistic to conclude that at itspresent state Active X as anarchitecture is still evolving andis limited only to Microsoftplatforms[11].

Although the application model maybe suitable for conveying theinformation, the system might needadditional fine tuning toaccommodate more appealing userinterfaces.

The system needs to tested morerigorously in a hospitalenvironment.

5. Conclusion and Future WorkIn the next stage of this research, wehave undertaken the development of suchsystems in CORBA and Java platforms incollaboration with a major Australianhospital. Once these developments arecompleted, it will be possible toprovide an interoperable telemedicineenvironment encompassing legacy, DCOM,CORBA and Java platforms. Such a systemover wide area network then would beevaluated from following perspectives: Clinical adaptability

Quality of service User acceptability Cooperative management of

distributed intelligence Management of securityWe are presently working on anevaluation strategy for this purpose.

6. References[1] alSafadi Yasser et al;PACS/Information SystemsInteroperability Using EnterpriseCommunication Framework; IEEETransactions on Information Technologyin Biomedicine; June 1998; Volume 2;Number 2; page 42-47[ 2]Andover Working Group White Paper;Accelerating the movement towardsstandards-based interoperability inhealthcare;http://www.interactive.hp.com/mpgawg/whitepaper.html ; 2nd January, 1999;[3] Brandt S; The benefits ofinteroperability;http://www.bed.soton.ac.uk/sdis/interop.shtml; 10/02/99[4] Cameron T. Howie, et al; SoftwareInteroperability; Center for Integrated

Facility Engineering, StanfordUniversity, 25th November,1996; http:// www.dacs.dtic.mil/techs/interop/title.shtml; 01/09/1998[5] Health Level Seven, StandardVersion 2.3, Standards Australia, May13,1997 [6] Ganguly P & Ray. P “Enterprise-wide Networking and Computing inHealth-care Industry: A Case Study”;Proceedings of IEEE EnterpriseNetworking and Computing Conference( ENCOM’98), in conjunction withICC’98, Atlanta USA, June 1998; [7] Ganguly P & Ray P “Telecardiologyover healthcare intranet”; Advances inClinical Pathology; vol 2; No 2; 1998,165-168; Proceedings of 4th EuropeanCongress on Telepathology; EuropeanSociety of Telepathology, Udine, Italy,June 1998[8] Ganguly P & Ray P “Telemedicineover Enterprise-wide Networks : A casestudy”; Proceedings of Globecom’98;Sydney, 8 –12 November, 1998 [9] Microsoft Corporation; TheComponent Object Model: TechnicalOverview; 2nd January, 1999[10] Microsoft Healthcare Users Group,ActiveX for Healthcare Committee:ActiveX for Healthcare MessagingComponents Programmer’s Guide, Version1.1, February 1998[11] Sessions Roger; COM and DCOM:Microsoft’s Vision For DistributedObjects; Wiley Computer Publishing;1998; pages 102, 469 – 472.

Figure 7: A Snapshot of ECG Screen