A top-down approach to Telemedicine provisioning by moving the service intelligence into the Telecomm Domain

Transcription

1 A top-down approach to Telemedicine provisioning by moving the service intelligence into the Telecomm Domain Marko Stiglic, Hu Hanrahan Centre for Telecommunications Access and Services School of Electrical and Information Engineering University of the Witwatersrand, Johannesburg m.stiglic, Abstract Todays implementations of telemedicine suffer from lack of defined standards and frameworks. Interoperation is achieved on a system-by-system basis with high ownership costs.the resulting design is based on moving the service intelligence into the service provider domain, hence streamlining the interoperation. The approach to telemedicine in this work relies on Object Oriented principles, to contain complexity, and to develop a generic core model of the service. The model is expandable to suit particular telemedicine service implementations. Index Terms Telemedicine, RM-ODP, Enterprise View, Information View. I. INTRODUCTION Telemedicine is a broad concept as illustrated in one of its common definitions: use of telecommunications to provide medical information and services [1]. The development of telemedicine has closely followed the development of technology. It is not suprising, then, that telemedicine development has met with problems similar to those found in the world of telecommunications. At present, telemedicine equipment consists of terminals containing the service intelligence which are connected using ISDN lines or virtual private networks (VPN). Each telemedicine system requires integration with other existing systems. The telemedicine industry as it is now can be thought of as the telecommunications industry was prior to the acceptance of open standards. Only some of the standards required are defined and accepted. This results in suboptimal telemedicine implementations. Two major factors limit the widespread use of telemedicine: first the necessity to integrate telemedicine solutions on a system-by-system basis, and second, the limited value and effectiveness of standards. In addition to these problems, telemedicine systems suffer from poor management of complexity. There are numerous medical conditions that need to be solved by a wide range of health professionals using a wide range of data sources resulting in a complex service definition. It is this complexity that has not been controlled in present telemedicine systems. This work attempts to control this complexity by developing a generic core model that is expandable. The Center is supported by Telkom SA Limited, Siemens Telecommunications, Sun Microsystems SA and the THRIP Programme of the Department of Trade and Industry Telemedicine can be modelled using numerous, simple, object interactions. This presence of objects leads itself to the use of Object Oriented Design (OOD). OOD is topdown design philosophy where major interactions are defined first and the remaining minor interactions are defined to complement the more important interactions. Furthermore, the interactions of these objects can be represented on different levels. This is where OOD will interact with the Reference Model for Open Distributed Processing (RM-ODP). RM-ODP is an established way of designing of a complex system with many interacting objects. The organisation of the paper is as follows: section II outlines present status of telemedicine delivery, section III discusses the challenges of designing for a telemedicine service, section IV is the proposed solution of the problem, section V explains the system functionality through use of a real life medical case and finally section VI gives the conclusions. II. PRESENT TELEMEDICINE DELIVERY Presently there are many telemedicine testbeds around the world. Increasingly, there is an amalgamation of these efforts by large government funded organisations. Two prominent organisations are the National Library of Medicine for America [2] and Tele-Medicine Alliance for Europe [3]. The three most prominent standards that are widely recognised are Digital Imaging and Communications in Medicine (DICOM), Picture Archiving Communication System (PACS) and Health Level 7 (HL7). The DICOM standard aims to define standards for communication of biomedical diagnostic and therapeutic information in disciplines that use images and associated data. However DICOM does not define an architecture for an entire system [4]. The PACS standard can be thought of as a sub-standard to DICOM as it concentrates solely on the standards of compression and quality of reproduction of medical images [5]. HL7 is a free standard trying to map and standardise the messages needed to deliver telemedicine services. However implementation times for this standard are vendor dependant and industry sees a need for improvements [6]. Although the standards work is extensive it is still far from delivering strict guidelines on service provisioning that would ensure wide interoperability.

2 III. DESIGNING FOR MEDICINE DELIVERY To design a telemedicine system a firm understanding of health delivery process is needed. However there are no overriding standards or guidelines to achieve this understanding. In general, the health delivery process is diverse for different medical conditions, differing from one institution to another. Furthermore, within one health organization practices differ from physician to physician. This diversity presents a problem, as any engineering system can only be designed to satisfy certain operational criteria. In this instance these criteria are too vast to define. To compound this problem, these operating criteria are likely to change. The more acceptable option is to design a system that is completely void of operational specifications but where interactions between roleplayers 1 is richly defined. An appropriate analogy would be a system of Lego blocks where the interaction between blocks is well defined, but the resulting shape of the creation is in users hands. IV. PROPOSED SOLUTION A system has been designed that relies on a central service provider to provide intelligence to the service. The benefit of this approach is that less complex equipment is necessary at the service customer s premises and this will drive the cost of delivery down. Complex equipment is in the service provider s domain and will be heavily utilised. Distributed computing ideas have been put to work to ensure that the system is scalable and robust. A future system, based on this work, could consist of a few nation-wide capable server centres that would act as data repositories and computing centres for the system. Numerous users will connect to this service using Telco lines, be they phone lines or high capacity digital connections. RM-ODP definition of the Enterprise and Information Views follows. A. Enterprise View Due to the complexity of the service, the approach to developing the Enterprise Viewpoint was a simple one: Isolate the core problem and design for that problem first, assuming secondary functionality will fit in easily with the rest of the design. The core idea of the Enterprise View is to solve what the system does. The telemedicine system requirement becomes: How do we efficiently transport medical expertise? In solving the transport issue, another difficulty becomes clear. Supply and demand of medical expertise in the system is asynchronous in nature and a method of negotiating between this supply and demand was necessary. A solution to these problems lies in the brokerage object explained later. Identified enterprise level objects are: Telemedicine delivery system Network connection provider. Doctors, administrators, databases... Administration of system intelligence Brokerage body End-user Health personnel Health_Personnel Intelligence Provider Community Administration User Community Service Delivery Domain Brokering_Body Telemedicine_DS Fig. 1 ENTERPRISE VIEWPOINT -DOMAINS End_User Telco Federation Domain Network_CP 1) Telemedicine Delivery System: The enterprise object contains the actual software and hardware necessary for service deployment. 2) Network Connection Provider: This object represents the Telco community. Most importantly, this entity provides the connection control and the actual connections. All the administration for the call control and connections will be a part of this enterprise object. 3) Administration: The administration function is needed to maintain the telemedicine service. Intelligence in this system is provided by the health care professionals and this enterprise object aims to maximise the return on the input of the health professionals. In addition the administration object will be responsible stability, flexibility and accountability of the system. Stability: A large system facing many points of failure calls for a function that will create safeguards against these failures. The stability will be provided by means of redundancy in all critical components of the system and the stability function of the administration object manages these aspects. Flexibility: Flexibility is the ability to change the way the system operates without any reduction in service provision quality. Usually this would mean an improvement of the service. Accountability: From time to time, information held in the system will be required by outside agencies for audit purposes. The accountability function of the administration object will provide for these interactions. In summary standard operation and once-of needs of the system are provided by the logic in this enterprise object. 4) Brokerage Body: The legal definition of the broker is: An agent employed to effect bargains and contracts, as a middleman or negotiator, between other persons, for a compensation commonly called brokerage. He takes no possession, as broker, of the subject matter of the negotiation. [7] The telemedicine service calls for the definition of a broker to be specific:

3 An agent that negotiates to satisfy the needs of the health delivery system by securing appropriate resources from available health personnel. Essentially, in this system, the brokerage function solves the internal problem of presence and availability of telemedicine services or expertise. For example: if a General Practitioner (GP) in a rural area needs to consult with a specialist, the brokerage function will successfully solve the problem of who to contact. Also, the broker function will be able to arrange the consultation times for a telemedicine expert. There should be a dedicated time when the expert is available for consultations. The availability during these advertised times has to be 100%, so it is encouraged that specialist consultations only be done in centres with multiple specialists to prevent failure. If a specialist is in a private practice then a mechanism of posting the times of availability is recommended. This brokerage function will then dynamically allocate these resources as needed. Geographical location of the health resources will be of paramount importance. When making the appointments the telemedicine service will try to minimise travel for the patient. It is this function that will distribute the health resources in a most beneficial way for patients. 5) End-User: The end-user enterprise object represents the patient community. The main purpose of this specification is to define the allowed interactions between the patients and the system. Namely, the patient s only interaction with the telemedicine system is through a health personnel. The only requirement on the patient is to supply the appropriate identification and reference in case of a referral. The only interaction that the patient is allowed is that of human contact with a particular health personnel. 6) Health Personnel: All personnel who are in any way connected to the medicine-specific delivery of health-care. This will include all doctors, nurses, lab personnel, counselors. Other personnel may be added, for example an on-site testing equipment operator who does not require any medical knowledge but rather training in operation of the equipment. These personnel would not fall within the health personnel object, instead the administration enterprise object will contain this function. B. Domains of Enterprise View Figure 1 shows the different domains of the Enterprise View. At this stage of the design we bring the telemedicine logic into the network domain. This relationship is represented by an arrow linking thedemand service delivery domain and Telco domain. The telemedicine service provider may be a Telco. Alternatively, the parties in the service delivery domain may be in a separate envelope but would have access to connectivity via the Telco. That is to say, other viewpoints in the RM-ODP model will benefit from being able to rely on more functionality provided by the network rather that by approaching it from a less trusted domain such as the service providers domain. C. Information View In a system as complex as telemedicine, the data structure definition is large and often non-related. To minimize this apparent non-relation, the data will be split into two categories. These categories are the Operational and Structural information. Operational - Information pertaining to the health delivery ( eg. patient records, billing information...) Structural - Information needed for the running of the system(eg. object pointers, object ownership, databasestructures...) 1) Operational Information Specification: Operational information objects are displayed in Figure 2 and 3. The two graphics are connected by the Patient Record object and therefore constitute the whole Information Viewpoint of the operational information. Person +Particulars Patient +Patient_No (key) #Patient record #Patient_Private_Data Fig. 2 Support Doctor -HP Private data Specialist +Area of speciality HUMAN ACTORS CLASSIFICATION Patient_Record +No of entries #Entry List Entry +By whom +Health_Problem_ID +When More Entry sub-classes are allowed Fig. 3 PATIENT RECORD STRUCTURE Picture Video Sound Written E.C.G. The operationalspecification deals with what the system operations are. Figure 2 explains the difference between different human actors in the system. The Patient object is characterized by private data, such as addresses and banking details and the patient record. The other actors have smaller definitions as they are not the recipients of the data of the

4 Patient_Record +No of entries +Entry List Health_Resources +All availability HP_availability +Area of expertise +Availability Health_Requirements +All requirements Telemedicine_Main +Participants +Session +QoS +Allocate resources() Session Agent Patient_Requierments +Patient case specific Patient Agent HP_Agent HP - Health Personnel Fig. 4 OVERALL HEALTH DELIVERY PLAN telemedicine system but they rather create and supply this information. Therefore the only information needed for these actors is their private information and their clearance codes. Although different, the human actor objects are all part of an object hierarchy and this is core to the principle of managing complexity. The design of a specific system system can be split into different levels of complexity for analysis purposes, and at this information level the Person object will suffice in describing the information structure. Figure 3 solely describes the structure of the Patient Record. It is a database-like structure that has increasing levels of granularity ending in the information components of the different kinds of entries. The list of these entry objects is not complete and the addition of further types is anticipated. In the Entry object we see the definition of By whom and Health Problem ID. These concepts introduce the team idea. At this stage information shown is of auditory nature. The teams functionality is provided by the Structural information objects as in Figure 4. The invariant rules governing these information objects are: Each interaction between the patient and the telemedicine system will result in collection of information from all of the information objects involved. Cross-checking of the financial status of the patient will be executed according to external rules (Government laws). A treatment iteration counter will exist as an indication to physicians about the maturity of the case and the ability of this system to assist with this medical case. This is necessary to prevent infinite loops and expedite treatment. The choice of GP is set by the customer, while the choice of the specialist rests with the GP. The team building responsibility rests with the physicians while the system may only suggest alternatives. 2) Structural Information Specification: Structural information deals with two different levels of information. Telemedicine specific Telecommunications specific Telemedicine specific information deals with distribution of available resources within the system. This is the broker functionality as defined in the Enterprise View. The resources and requirements are first located in single instance cases and then they are collated into one object containing all the resources and requirements. The Allocate requirements functionality of the Telemedicine Main object is the brain with the logic to allocate the resources without any conflicts. Telecommunication specific information is much more detailed as it is necessary to overcome problems of distribution. The objects of Session and Agent type consist of all the information necessary. Information contained in these objects is as follows: Session : session participants, session initiator... Agent : identification, object id lists... Specialised Agent : owner, device capability... Structural information is further restricted by the following invariant rules: QoS is determined by the system and the type of connection is limited therein. A minimum amount of participants is two, one patient and one health personnel object or two health personnel objects. In the case where remote testing stations are implemented without doctors but using operators, the participant will be a scaled down GP object with same interfaces. V. SPECIFIC MEDICAL CASE Now that we have described the generality of the system s operation, based on medical teams, a scenario is cho-

5 sen to highlight these concepts, especially the concept of teams. A scenario of a person with thyroid cancer is chosen as it is deemed to be complex enough to place many requirements on the system and emphasize its operation. After noting a prolonged, painless swelling in his thyroid (neck) region, a patient visits his GP. The GP makes a primary diagnosis of the swelling and orders further tests such as the ultrasound and nuclear imaging tests. At the point of ordering these tests, the GP will have certain specialists (Specialist 1, and Specialist 2) in mind, he will then request the system to make the appropriate appointments. This is where the team begins to form for this particular case. After visiting the specialists and conducting these tests the results come back and both specialists involved with the testing feel that next step would be more tests such as a Fine Needle Aspirate test. But by this time, the patient has returned to his rural dwelling and the only way to reach him would be through his GP. The system updates the patient s record and the next time the patient visits the GP, appropriate information, along with the diagnoses from specialists, is relayed. The GP then requests those further tests at locations that are closest to the patient and are recommended by the specialists 1 and 2. Additionally the GP requests that specialist 3 be brought in. The team now consists of the GP and Specialists 1, 2 and 3. The case proceeds in these broad cycles of diagnosis, testing and treatment (in this case surgery and irradiation). At any moment, any member of the team can invite new parties and request certain medical procedures. These additions, including test results and diagnoses are always available to all the team members. REFERENCES [1] N. Brown. The telemedicine research center s (trc) telemedicine primer: Telemedicine coming of age. last accessed 20 June [2] Nlm national telemedicine initiative. last accessed 20 June [3] World Health Organisation (WHO). Tm alliance project - introduction. /who/progs/tme/about/ , last accessed 20 June [4] Dicom homepage. last accessed 20 June [5] S. C. Horii & G. J. Blaine. Pacs design and evaluation : engineering and clinical issues. Proceedings of SPIE the International Society for Optical Engineering, XIV:604, [6] A. Arbor. Health level 7. last accessed 20 June [7] Dictionary.com. last accessed 20 June Biography: Marko Stiglic holds a BSc (Eng.) degree in Electrical Engineering from the University of the Witwatersrand. He is presently pursuing his MSc(Eng.) degree at the University of the Witwatersrand. Hu Hanrahan is a Professor of Communications Engineering at Wits University. he leads the Centre for Telecommunications Access and Services (CeTAS), a research and advanced teaching centre devoted to improving knowledge and practice in the evolving telecoms access networks and telecoms services. VI. CONCLUSIONS Telemedicine implementations have not reached their potential yet. Lack of complete and accepted standards is responsible for lack of interoperation between telemedicine systems and hence their reduced effectiveness. The primary cause of difficulties with telemedicine design is the lack of complexity control. A Object Oriented approach was used and the system design was grown from a core model. This approach yielded a logical flow of lesser problems that were solved efficiently using the concepts of abroker. The telemedicine service was further enhanced with a teams idea. We propose that a telemedicine service be based on a centralised logic. The Enterprise View of a telemedicine service presented here, together with the detailed Information View, will serve as the basis for a proof of concept demonstration of the core element of the approach. Furthermore the introduction of new concepts such as teams or moving the telemedicine into the Telco domain do not necessarily increase the complexity of the design.