Docstoc

Artemis Deliverable D3

Document Sample
Artemis Deliverable D3 Powered By Docstoc
					IST-2103 STP ARTEMIS
"A Semantic Web Service-based P2P Infrastructure for the Interoperability of Medical Information systems"
SPECIFIC TARGETED RESEARCH PROJECT PRIORITY 2.3.1.11 eHealth

Realization of the Pilot Application Scenarios on the hybrid infrastr ucture developed
D7.3.1
Due Date: Actual Submission Date: Project Dates: 30.06.2006 To be provided Project Start Date: January 1, 2004 Project End Date: June 30, 2006 Project Duration: 30 months Leading Contractor Organisation: IT Innovation

Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006)
Dissemination Level PU PP RE CO Public Restricted to other programme participants (including the Commission Services) Restricted to a group specified by the consortium (including the Commission Services) Confidential, only for members of the consortium (including the Commission Services)



IST-2103 STP ARTEMIS

11/3/2009

Short Description:
This document provides a detailed description of realization and deployment process of the pilot application scenarios over the ARTEMIS infrastructure.

ARTEMIS Consortium Contacts:
Organisation METU-SRDC OFFIS SEBT ALTEC Tepe Technology IT Innovation Name Asuman Dogac Phone Fax E-Mail +90-312-2105598 +90-312-2101004 asuman@srdc.metu.edu.tr

Marco Eichelberg +49 441 9722 +49 441 9722 eichelberg@offis.de 147 102 Leslie Finlay +44 28 90565261 +44 28 90565806 leslie.finlay@sebt.n-i.nhs.uk Adamantios Koumpis Bulent Kunac Mike Boniface +30 2310 595659 +30 2310 595630 akou@altec.gr +90-312-2919100 +90-312-2662998 bkunac@tepeteknoloji.com.tr +44 23 8076 0834 +44 23 8076 0833 mjb@itinnovation.soton.ac.uk

Document History:
Version 1 2 3 4 Date 14/06/2006 21/06/2006 23/06/2006 26/06/2006 Changes Initial version Minor updates Updates Updates and recommendations Updated and added partners recommendations From IT Innovation SEBT TEPE OFFIS Review All IT Innovation IT Innovation IT Innovation

5

30/06/2006

IT Innovation

ALL

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 2 of 39

IST-2103 STP ARTEMIS TABLE OF CONTENTS

11/3/2009

Abbreviations .............................................................................................................................5 1 2 Introduction........................................................................................................................6 ARTEMIS Infrastructure ...................................................................................................7 2.1 2.2 3 3.1 3.2 3.3 Overview ....................................................................................................................7 Architecture ................................................................................................................7 Scenario ....................................................................................................................10 Services ....................................................................................................................11 Deployment ..............................................................................................................11 Setup Phase.......................................................................................................13 Ontology Deployment ..................................................................................13 Organisation and Service Registration .........................................................13 YPC Setup ....................................................................................................14 Implementation Phase.......................................................................................14 Referring the patient to the YPC ..................................................................15 Discovering patient information during assessment .....................................15 Requesting a collaboration agreement ..........................................................15 Retrieving clinical information from other healthcare providers .................15 Creating a Care Plan .....................................................................................16 3.3.1.1 3.3.1.2 3.3.1.3 3.3.2 3.3.2.1 3.3.2.2 3.3.2.3 3.3.2.4 3.3.2.5 4 4.1 4.2 4.3

SEBT Pilot Application ...................................................................................................10

3.3.1

TEPE Pilot Application ...................................................................................................17 Scenario ....................................................................................................................17 Services ....................................................................................................................18 Deployment ..............................................................................................................19 Setup Phase.......................................................................................................21 Ontology Deployment ..................................................................................21 TEPE Hospital Setup ....................................................................................23 Care2X Setup................................................................................................26 Implementation Phase.......................................................................................28 Admit Patient from Ambulance ....................................................................30 Retrieve Critical Health Data of Istanbul Hospital .......................................30 Retrieve History of Hacettepe Hospital ........................................................32 Retrieve History of Istanbul Hospital ...........................................................33 Place Lab Order of Cankaya Laboratory ......................................................33 Push Lab Results of TEPE Hospital .............................................................35 On-Line Claim Processing of Insurance Company ......................................35 4.3.1.1 4.3.1.2 4.3.1.3 4.3.2 4.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4 4.3.2.5 4.3.2.6 4.3.2.7

4.3.1

5

SEBT-TEPE Integrated Scenario.....................................................................................36 Page 3 of 39

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

IST-2103 STP ARTEMIS 5.1 5.2 6

11/3/2009

Overview ..................................................................................................................36 Deployment ..............................................................................................................37

Conclusions......................................................................................................................39

TABLE OF FIGURES Figure 1: ARTEMIS Architecture ..............................................................................................8 Figure 2: SEBT pilot application components .........................................................................12 Figure 3: TEPE Scenario Standards .........................................................................................19 Figure 4: Ontology Deployment ...............................................................................................22 Figure 5: TEPE Hospital Setup Steps .......................................................................................24 Figure 6: Patient Registration in Care2x ..................................................................................27 Figure 7: Patient Diagnosis ......................................................................................................27 Figure 8: Patient Allergies ........................................................................................................28 Figure 9: Implementation Phase Steps .....................................................................................29 Figure 10: corTTex Worklist ....................................................................................................30 Figure 11: Initial Diagnosis ......................................................................................................31 Figure 12: PID Query Input ......................................................................................................31 Figure 13: PID Query Result ....................................................................................................32 Figure 14: History of Patient Data............................................................................................32 Figure 15: Place Lab Order ......................................................................................................33 Figure 16: External Lab Order –TEPE Hospital ......................................................................34 Figure 17: Care2X Pending Lab Order Panel ...........................................................................34 Figure 18: TEPE-SEBT Scenario Integration General Overview ............................................37 Figure 19: SEBT-TEP Integrated Scenario ..............................................................................38

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 4 of 39

IST-2103 STP ARTEMIS

11/3/2009

Abbreviations
The following abbreviations and acronyms are used in this document. BUT CCO CPT EDI FO GP HIPAA HL7 LOINC MO OWL OWL-S RDF RDFS SEBT XML XSD WSDL YPC Budget Application Directive (Bütçe Uygulama Talimatı) Clinical Concept Ontology Current Procedural Terminology Electronic Data Interchange Functionality Ontology General Practice Health Insurance Portability and Accountability Act Health Level Seven Logical Observation Identifiers Names and Codes Message Ontology Web Ontology Language Web Ontology Language for Services Resource Description Framework Resource Description Framework Schema South & East Belfast HSS Trust eXtensible Markup Language XML Schema Definition Web Service Description Language Young Persons Centre

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 5 of 39

IST-2103 STP ARTEMIS

11/3/2009

1 Introduction
The goal of the ARTEMIS project was to develop a semantic Web Services based interoperability framework for the healthcare domain. ARTEMIS has provided interoperability of medical information systems through semantically enriched Web Services, interoperability of Electronic Health Records through Web Services, and an integration environment for disparate applications both within the healthcare domain and with the organizations they communicate with. The resulting infrastructure provides support for interoperability at the semantic level through ontology mediation and facilitating resource discovery through the peer-to-peer technology. Healthcare professionals using systems connected to the ARTEMIS network can access medical information in different domains of control securely and seamlessly through a peer-to-peer infrastructure, regardless of where their patients or their records might be. This document outlines how ARTEMIS infrastructure supports the interoperability of healthcare information in two different pilot application scenarios. These application scenarios, namely SEBT and TEPE show how healthcare organizations using different information systems can describe web service message structures using ontologies and allow healthcare professionals to transparently discover this information regardless to their location. The details are also given for the services implemented, their semantic description and how they are published and discovered over the ARTEMIS P2P network.

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 6 of 39

IST-2103 STP ARTEMIS

11/3/2009

2 ARTEMIS Infrastructure
2.1 OVERVIEW
Unlike many other domains, healthcare is based on information that may have been gathered by health care providers in different locations using different information systems. Currently, healthcare provider may use many heterogeneous healthcare information systems to support the delivery of patient care each designed to perform specific functions. There might be an admission/discharge/transfer (ADT) system along with various other department systems that support radiology and laboratory functions. Typically, these systems are standalone, developed by many different suppliers and are incompatible with one another. The lack of integration between departmental, hospital and regional information systems in terms of welldefined business processes produces serious inefficiencies when delivering patient care. Healthcare professionals do not have access to the information they need to make decisions where they need to do so. For example, during an assessment a healthcare professional may need to directly ask a patient about current medication and recent treatments because they do not have access to the patient‟s records, which could be located within another department, hospital or region. Sharing patient information electronically between departments is typically achieved or part of most organisations IT strategy but share information across organisation boundaries is rarely seen. Most healthcare information systems tend to use incompatible messaging formats and coding schemes. In some cases, the message format is based on standards such as HL7 but the standards are complex, can be interpreted in many ways making interoperability difficult to achieve. Also, healthcare information systems operate within a strict regulatory framework that is enforced to ensure the protection of personal data against processing and outlines conditions and rules in which processing is allowed. If a healthcare provider wants to access personal data within another organisation they must first contact the data controller at the organization and obtain a data processor‟s consent from the patient involved. Prior to gaining access to data, a contract between the two parties must be established to define conditions such as the type of data processing and how long the data can be stored by the data processor. Even after data processing conditions are agreed there are still technical challenges in terms of security and privacy mechanisms that need to be resolved before electronic healthcare records can be automatically shared between healthcare organizations. In most cases healthcare providers have different security policies that state a diverse set of security requirements and capabilities. Authentication and authorisation mechanisms for healthcare professions may also be different. As distributed systems become more and more integrated with increasing interoperability of emerging industry standards, increasing network capabilities by providing solutions based on these standards also becomes more important. Even though there are many diverse systems and standards exist in healthcare domain, it‟s obvious that interaction between these systems is very important in terms of providing health services. Therefore the scale of this possible benefit from integration justifies all the attempts for integrating different systems.

2.2 ARCHITECTURE
The main objective of the ARTEMIS project was to develop a semantic Web Services based interoperability framework for the healthcare domain. ARTEMIS infrastructure raises the
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 7 of 39

IST-2103 STP ARTEMIS

11/3/2009

quality of health care by providing an interoperability infrastructure which extends the health care enterprises by making their own services to others; extends the life of the existing software by exposing previously proprietary functions as Web services; opens the door to new business opportunities by making it easy to connect with other parties in the health care domain. The high-level architecture is depicted in Figure 1.

Figure 1: ARTEMIS Architecture In particular, ARTEMIS enables medical practitioners to access medical information securely and seamlessly through a peer-to-peer infrastructure, regardless of where their patients or their records might be. Any approach for an interoperability framework for the healthcare domain has to take the installed base of medical information systems into account. ARTEMIS does this by encapsulating existing applications within the Web service model and providing access to clinical data in a standard way. The ARTEMIS project resolves the interoperability problem in the healthcare domain where organizations have proprietary application systems to access data. To exchange information there are different standards like HL7, GEHR or CEN's ENV 13606. ARTEMIS project provides an interoperability platform where organizations keep their proprietary systems, but expose the functionality through Web services. To enable healthcare professionals to access remote patient records hosted by heterogeneous information systems, ARTIMES utilizes a PID/RID infrastructure that comprises a set of integrated components responsible for searching and retrieving matching patient datasets based on specific demographic data. The infrastructure PID components is the key component responsible for finding patients according to their demographics data, while the DISPLAY, AIS and IHE-IS components are the main components responsible for mapping and transferring the patient-related documents and/or information from the source healthcare
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 8 of 39

IST-2103 STP ARTEMIS information system to the requesting healthcare professional.

11/3/2009

Ontologies describing the healthcare domain functionalities and clinical concepts are the primary tool for the mediation process in the ARTEMIS framework. Clinical Concept Ontologies (CCO) have been developed based on prominent healthcare standards. They can be thought of basic building blocks of messages in healthcare domain. The healthcare institutes are not expected to conform to these CCOs. They can develop their own ontologies (which are referred as Message Ontologies) that conform to the data model of their own legacy application.The Message Ontologies describe the structure of input/output messages of exposed Web Services. After developing the Message Ontologies, the mapping between Message Ontologies and Clinical Concept Ontologies should be provided in order to establish the mediation between the Message Ontologies of different institutes. In ARTEMIS, this is achieved through a mediator component that utilizes an ontology mapping tool that can semantically map between different ontologies at runtime. In a typical healthcare peer-to-peer network each time a healthcare professional wants to discover healthcare services or medical information, a request has to be broadcasted to all peers on the network to search their repositories. This process can be very time consuming with a large number of connected organisations. ARTEMIS alleviated this problem by means of semantic routing, which allows query requests to be propagated to specific mediators and HIS peers rather than the whole network. This is achieved through HIS peers advertising their services/knowledge to their local mediators, which stores them in a local repository after indexing them. When a mediator receives a request that matches the services/knowledge advertisements in its local repository, it forwards the request to selected peers that are able to respond to this kind of requests

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 9 of 39

IST-2103 STP ARTEMIS

11/3/2009

3 SEBT Pilot Application
3.1 SCENARIO
The SEBT pilot application scenario is based on the treatment of a young person with a variety of behavioral problems. The scenario consists of a three healthcare organizations within Belfast, Northern Ireland collaborating in the provision of medical care; a General Practice (GP), a Young Persons Centre (YPC) and SEBT‟s community system. The GP provides primary care to patients and provides the entry point to the healthcare system. The YPC is a secondary care with a Regional Adolescent Psychiatric Inpatient Service for young people aged 13-18 with mental illness and psychological problems. The centre utilizes a multi-disciplinary team approach to treatment and offers a wide variety of therapeutic interventions with a focus on mid to long-term treatment. The SEBT community system is a trust wide IT service that provides access and management of Electronic Healthcare Records that can be accessed by different healthcare providers within the trust. The YPC maintains its own information systems and works autonomously but within the SEBT organization. Currently, SEBT create care pathways using an out-of-band referral process rather than an integrated infrastructure allowing healthcare professions to referral using healthcare information systems. In addition, once referred medical records of any current or previous treatment cannot be easily shared. Under most circumstances the healthcare professional use their judgement as to what other organizations within SEBT they will contact to obtain further medical information during an assessment. The SEBT pilot application scenario demonstrates how healthcare providers participating in the treatment of patients can create care pathways and can share Electronic Healthcare Records that are subsequently generated. The overall sequence for the care pathway is described below: 1. The patient is assessed by a GP (primary care provider) 2. The GP refers the patient to the YPC for assessment and further care providing initial diagnosis information on systems using Read Codes classification. The diagnosis presents some behavioural problems including a failure to mix with children of own age group since starting primary school and tendency to aggressive behaviour. The child is also now a Fussy eater, as child now obsessed with appearance, but tends to overeat and is now obese. The GP states that these are the present problems and that they are not simply medical. The GP requests an assessment and if found necessary that appropriate treatment given. 3. On receipt of the referral a clinical officer registers the patient to the YPC 4. The YPC reviews the referral, as part of a referrals meeting to determine if the centre can treat the patient 5. During the assessment the referral team discovers that medical records for the patient are stored at the SEBT community trust system and a Turkish hospital in Ankara 6. The YPC negotiates a collaboration agreement with both healthcare providers, whilst obtaining consent from the patient 7. The team requests specific medical documents on the patient 8. The referral is accepted and an appointment is scheduled with a key worker, who is responsible for the referral throughout treatment
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 10 of 39

IST-2103 STP ARTEMIS

11/3/2009

9. The patient then attends the appointment and is assessed using a specific method to produce a diagnosis. Following the assessment if further treatment is required a care plan is generated consisting of a set of activities. Activities can be varied including psychotherapy, speech therapy, etc at both the YPC and further referrals to other healthcare clinics as appropriate 10. The patient will have regular appointments with the key worker who will continue to assess the patient and update the care plan accordingly 11. On completion of the care plan the patient is discharged and a referral discharge message is sent back to the GP

3.2 SERVICES
The SEBT pilot application scenario comprises a number of web services that allow healthcare professionals to transfer and assess patients‟ information across the ARTEMIS network. The services include; PatientReferral Service for referring new patients to the YPC. This service runs at the YPC and it requires inputs such as Name, Surname, Patient ID, Date of Birth, Address, Diagnosis Code and Diagnosis Description. PARIS web Services which include both PatientRecords and PatientDetail Service. PatientRecods Service for retrieving patients records before registering or assessing a new patient. This service runs at the YPC and other healthcare providers and it takes the Patient ID as an input and returns personal and referral data as an output. PatientDetails Service for retrieving patients‟ details and IDs. This service runs at the YPC and uses the Patient Surname as an input and provides Patient ID along with other personal information. Assessment Service for assessing patients‟ situation and producing care plans. This service runs at the YPC and it requires the Referral ID as an input and produce an output that include Date of Assessment, Time of Assessment, Goal, Carried Out By, Reason, Planned Completion and Date of Completion. PatientReferralNotification Service for informing the GP with the result of the PatientReferral service. This service runs at the GP and it tells the GP either the Referral ID of the patient or the reason for reject the referral.

3.3 DEPLOYMENT
The pilot application supports interactions between three healthcare organizations located within Northern Ireland. Figure 2 shows the IT infrastructure components that supports the pilot. Each of the healthcare organizations operates IT infrastructure under their own domain of control. The organizations are connected to the network through ARTEMIS peers that are registered with a common mediator serving the Northern Ireland region. Two healthcare information systems have been integrated, Care2X and PARIS. Each healthcare organization operates ARTEMIS infrastructure along with a set of specific web services related to their healthcare function. The ARTEMIS infrastructure consists of:  A peer providing connectivity to the ARTEMIS network supporting the discovery and invocation of services, discovery and retrieval of patient information and the management of collaboration agreements and  A PID server supporting the discovery of patient information based on control numbers
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 11 of 39

IST-2103 STP ARTEMIS  An IHE-Information Source providing access to specific medical documents

11/3/2009

Each healthcare information system and organization uses different message structures and encoding schemas. The GP uses proprietary message structure with an HL7 V3.0 Patient Referral ontology using ReadCodes (coded thesaurus of clinical terms which enable GPs to use them on computer systems) to describe diagnosis information (e.g. EU50z = Fussy eater and obsessed with appearance). The YPC uses a proprietary message structure with an HL7 V3.0 Patient Referral ontology using ICD10 (International Classification of Disease, version 10) to describe diagnosis information (e.g. F50.9= Eating disorder, unspecified). Therefore, the Diagnosis Information has be mapped from ReadCodes to ICD-10 during the mediation process between the GP and the YPC to enable the key worker to understand the GP‟s diagnosis and hence the reason for referral. On the other hand, SEBT PARIS system uses a proprietary message structure, CPT and an ICD-10 diagnosis information. All organizations within the scenario have their expertise classified in accordance with the HIPAA Product Taxonomy.

Figure 2: SEBT pilot application components The GP and YPC use a Care2X client application to manage patient treatment. Care2X is highly configurable and has been setup to support each organizations specific medical function. The SEBT‟s Community System is based on the PARIS system but only as a data provider. The PARIS client application was not integrated with ARTEMIS, as it is owned by a 3rd party vendor http://www.in4tek.com/ who were not engaged as part of the ARTEMIS project. Both Care2X and PARIS have been integrated with the PID and IHE RID. A PID service is deployed with each peer support the discovery of patient information maintained by organizations connected to the ARTEMIS network. Each information system has an IHEInformation Source allowing specific medical documents to be retrieved. A Public Key Infrastructure is operated to provide authentication of the participants in the SEBT scenario. The participants are real people, JXTA peers, and service entities. A Certification Policy and Certificate Practice Statement have been documented to describe the operating procedures for the PKI. Each organization defines a security policy using WS2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 12 of 39

IST-2103 STP ARTEMIS

11/3/2009

Policy that codifies the security requirements in terms of integrity and encryption for both P2P and web service message exchanges. Each organization operates a collaboration service allowing healthcare providers to manage working relationships and access agreements. These agreements are used as the basis for authorization decisions and must be provided when accessing services and medical records.

3.3.1 Setup Phase
This section gives a summary of the key steps required to setup the ARTEMIS infrastructure to support the SEBT pilot application scenario. 3.3.1.1 Ontology Deployment Each healthcare organization in the ARTEMIS network conforms to a set of ontologies that they use to describe their organization, services and patient information. These ontologies are typically derived from commonly agreed medical standards. The ontologies need to be advertised on the ARTEMIS network prior to registration of healthcare organizations. The SEBT pilot application uses the following ontologies 1. FO based on HL7 trigger events to describe a service‟s function 2. Referral CCO based on HL7 V3.0 3. Clinical Procedure CCO based on CPT 4. Clinical Terminology CCO based on Read Codes 5. Clinical Terminology CCO based on ICD-10 In addition to the healthcare domain ontologies, ARTEMIS provides a general upper ontology describing system entities that are advertised on the ARTEMIS network. The upper ontology includes not only services but also organizations, other ontologies, ontology mappings, etc. The ARTEMIS ontology is stored within each mediator at deployment time. 3.3.1.2 Organisation and Service Registration In the setup phase, an organization registers itself within the ARTEMIS network and advertises services so that other providers can discover those services and associated patient information. The registration phase consists of the following steps: 1. An administrator registers the organization to a trusted mediator 2. An administrator advertises the ontologies (functionality, clinical concept, expertise and demographics) that the organization conforms to. 3. An administrator selects the expertise from the expertise ontology that describes the organizations clinical function Following these steps the organization will be registered on the ARTEMIS network and can be discovered by other healthcare providers. The organization can now annotate and advertise web services. The service annotation and advertisement phase consists of the following steps: 1. Generate an XML schema for the web service 2. Generate a message ontology for the web service‟s schema using the Peer GUI 3. Generate an ontology mapping from the source message ontology to the target CCO using the OWLmt 4. Generate an ontology mapping from the target CCO to the source message ontology using OWLmt 5. Create ontology mapping advertisements for both generated ontology mappings using the Peer GUI
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 13 of 39

IST-2103 STP ARTEMIS 6. Advertise both ontology mapping advertisements using the Peer GUI

11/3/2009

For organizations that have client applications wishing to invoke ARTEMIS services the procedure for very similar to the above apart from the XML schema represents the client applications request and response messages rather than the service. 3.3.1.3 YPC Setup This section describes the sequence of events for registering the YPC centre on the ARTEMIS network. 1. The administrator registers the YPC to the ARTEMIS network by selecting System>Register->Organisation. The administrator then enters information describing the YPC. 2. The administrator selects the ontologies that the YPC will confirm to including HL7FuncOnt.owl, HL7PatientReferral.owl 3. The administrator describes the expertise of the YPC by selecting the “Behavioral_HealthSocial_Service_Providers” node from the expertise ontology 4. The administrator presses the “Finish” button to advertise the organization at their trusted mediator. The YPC then needs to annotate and advertise the patient referral services on the ARTEMIS network 5. The service developer creates an XML schema for the message structure of the Care2X patient referral message using XSD. 6. The service developer creates a web service message ontology for the PatientReferral service using the Peer GUI by selecting Create->Ontology->Message Ontology from the main menu. The Peer creates a message ontology PatientReferralMO.owl that is available from the peer‟s web server 7. The administrator advertises the message ontology to the mediator using the Peer GUI 8. The service developer creates an ontology mapping definition using OWLmt between the PatientReferralMO.owl and the HL7PatientReferral.owl clinical concept ontology. 9. The administrator advertises the ontology mapping definitions for the patient referral service to the trusted mediator 10. The administrator advertises the PatientReferral service using the Peer GUI. The administrator selects the HL7 event “PatientReferralRequestServices” from the functionality ontology, enters the WSDL URI and security policy URI. The administrator then selects the input and output message types for the service before pressing the finish buttons Following these steps the YPC will be registered on the ARTEMIS network with a PatientReferral service

3.3.2 Implementation Phase
This section provides a summary of the key steps for the execution of the SEBT pilot application scenario. The steps assume that all other healthcare organizations (GP and SEBT Community System) have registered with the ARTEMIS network in a similar way to the YPC, as described in Section 3.3.1

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 14 of 39

IST-2103 STP ARTEMIS 3.3.2.1 Referring the patient to the YPC This section describes how the GP refers a patient to the YPC.

11/3/2009

1. The GP assesses the patient and decides he requires some further specialist assessment 2. The GP accesses Care2X and selects the Refer to YPC referral plug-in 3. The GP completes the patient referral form entering the initial diagnosis symptoms using Read Codes The patient referral now appears within the YPC 4. The clerical officer checks the required referral information has been completed and creates an appointment with a key worker (i.e. doctor) who will treat the patient. 3.3.2.2 Discovering patient information during assessment This section describes how the key worker discovers medical records maintained by other healthcare providers during the initial assessment. 1. Prior to his appointment with the patient, the doctor does some preparation by searching the ARTEMIS network for previous encounters 2. The doctor accesses Care2X and selects the Patient Information Discovery plug-in 3. The doctor completes the demographics information in the form using data provided by the initial referral The ARTEMIS network provides potential medical records from both the SEBT community trust system and a Turkish hospital. 3.3.2.3 Requesting a collaboration agreement This section describes how the doctor requests access to medical records through a negotiation with SEBT‟s data guardian. 1. The doctor decides that SEBT community trust system may have important medical records related to the current treatment 2. During the assessment, the doctor asks the patient and his parent if he can request access to medical records maintained by SEBT‟s community system 3. The doctor requests access to the medical records using the ARTEMIS Collaboration Manager plug-in for Care2X stating that he needs to see the medical record to get a clear view on previous and current medication the patient has been prescribed The Data Guardian from SEBT receives the collaboration agreement request and approves access to the medical records 3.3.2.4 Retrieving clinical information from other healthcare providers This section describes the doctor retrieves specific medical documents from SEBT community health system 1. The doctor accesses the RID plug-in in Care2X 2. The doctor selects to retrieve medical prescription documents 3. The doctor examines the report and notes that the patient has been diagnosed with ADHD as a child and prescribed Ratilin. He also sees that the patient is currently prescribed Prozac for serious depression and anxiety. 4. The doctor also sees that the patient is currently prescribed a steroid based asthma inhaler.
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 15 of 39

IST-2103 STP ARTEMIS 3.3.2.5 Creating a Care Plan

11/3/2009

This section describes the doctor diagnosis of the case and the preparation of a care plan for treatment. 1. The doctor decides the patient is suffering from a psychological problem and requires a series of psychotherapy sessions. 2. The doctor estimates the outcome of the treatment and the date of expected completion and enters the rest of the assessment information onto the system.

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 16 of 39

IST-2103 STP ARTEMIS

11/3/2009

4 TEPE Pilot Application
4.1 SCENARIO
The TEPE pilot application scenario demonstrates the collaboration and data sharing between six medical service providers, each of which uses their own set of web services to provide access to their resources and medical records. Within the scope of this pilot application scenario, the six medical service providers are; The Ambulance, TEPE Hospital (providing AdmitPatient and PushLabResults services), Hacettepe Hospital (providing RetrievePatientHistory service), Istanbul Hospital (providing RetrieveCriticalHealthData and RetrievePatientHistory services), Cankaya Laboratory (providing PlaceLabOrder service) and an Insurance Company (providing ClaimProvisionRequest service). The scenario centres around a Turkish businessman living in Ankara called Alper Okcan. Mr. Okcan has an ongoing heart condition and was previously living in Istanbul. He has recently moved to Ankara and admitted to the Ankara Hacettepe hospital for a routine check-up about his heart problem. Mr. Okcan previously had a surgery related to his heart problem in Istanbul Hospital, and continued the treatment in Hacettepe Hospital. The following section describes the steps of the scenario executed. On an ordinary workday, Mr. Okcan suddenly becomes ill. A first-aid person working in the building is called and s/he quickly realises that the situation is serious and summons an ambulance. The Ambulance (Mobile Peer) 1. The ambulance crew suspects about “myocardial infarct” and searches the ARTEMIS network for a hospital with facilities to admit a patient with cardiovascular disease through a mobile device. 2. The ARTEMIS network supplies a list of hospitals and the paramedic selects the TEPE Hospital as the most appropriate one. 3. After the TEPE Hospital is selected, the user supplies the patient‟s personal information and his vital signs and obtains a local patient id, which s/he will use when delivering the patient to the emergency department (TEPE Hospital – AdmitPatient). 4. Meanwhile, the patient is placed in the worklist of the emergency doctor in TEPE Hospital in order to make him/her pre-notified about the arriving patient. TEPE Hospital Ambulance (Mobile Peer) 5. The patient in the ambulance reaches to hospital and emergency doctor validates the initial diagnosis as “acute myocardial infarct”, and transfer the patient to “cardiology intensive care unit” of the hospital. 6. The doctor in the cardiology Intensive Care Unit (ICU), requests the patient‟s history from the ARTEMIS network. In order to make the related search, the doctor first clicks the ARTEMİS button on the Patient History screen of corTTex integrated hospital information management system of TEPE Hospital after selecting the “External Data” Option. 7. Then s/he presses the “Retrieve Patient Data” (PID Query – Section 4.3.2.2) button to search the ARTEMIS Network in order to get the list of all candidate patients for
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 17 of 39

IST-2103 STP ARTEMIS enabling him/her to retrieve medical history and critical health data of Mr. Okcan.

11/3/2009

8. The critical health data and medical history of the patient is retrieved from the ARTEMIS enabled Istanbul Hospital and Hacettepe Hospital (Player 3 and Player 4) and presented to the doctor. Actually, these two data sets (critical health data and medical history) are selected because these are the most common information that a GP would like to retrieve from other institutes to continue his/her treatment. 9. The doctor realizes that, Mr Okcan has one surgical procedures in his medical history, the other is “Coronary artery bypass, vein only; single coronary venous graft”. 10. In order to decide the right treatment, the doctor places a lab order for “Creatine Kinase (CK), (CPK); MB fraction only “ and “Creatine Kinase, Total (CK)”. 11. An external lab order is invoked to Cankaya Laboratory. 12. The laboratory test request ordered from TEPE Hospital is received by Cankaya Lab. The order is processed and the Push Lab Results web service of TEPE Hospital is invoked. 13. The doctor in TEPE Hospital views the lab results and decides the health condition of Mr. Okcan is not critical. Then the provision requests are performed to the insurance company for the payment of the provided services and the patient episode for Mr. Okcan is closed in corTTex.

4.2 SERVICES
The TEPE pilot application scenario comprises a number of web services that allow healthcare professionals to exchange patient records across the ARTEMIS network. The services include; AdmitPatient Service for the admission of new patients to hospitals. This service that runs at TEPE Hospital requires inputs such as Name, Surname, Age, Breathing and PreliminaryDiagnosis. PID Query Service enables TEPE Hospital doctors to search/access the medical records of their patient held by any medical-service provider within ARTEMIS Network. PID Protocol will be used prior to invocations of services of a healthcare organization that need a specific patient or candidate id to access medical documents or medical information on a remote repository. Place Lab Order for creating and submitting Lab order requests. This service runs at Cankaya Laboratory with inputs such as Order Date, Patient Name, Patient Gender and Test Codes. Push Lab Result for sending Lab test results. This service runs at TEPE Hospital and it provides an output containing Process Identifier, Test Codes and Test Results. On-Line Claim Processing Service for processing payment orders issued to insurance companies for services provided to their clients. This service runs at TEPE Hospital with inputs such as Patient Name, Insurance Policy No, Diagnosis (ICD-10), Service Date and Service. Retrieve Patient History for the retrieval of patient‟s history from other healthcare providers. This service is provided by all hospitals accept TEPE Hospital. The service accepts the candidate patient ID as an input parameter and returns the corresponding patient history. Retrieve Patient Data for obtaining related patient‟s data from healthcare providers. This service runs at Hacettepe Hospital and Istanbul Hospital and it provides the following outputs; Admission Date, Discharge Date, Primary Diagnosis, Morbidity and Surgical Procedures. Retrieve Critical Health Data for capturing the related patient medical-critical data. This
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 18 of 39

IST-2103 STP ARTEMIS

11/3/2009

service runs at Istanbul Hospital and it provides data such as Blood Type, Allergies and Chronic Diseases.

4.3 DEPLOYMENT
Figure 3 describes the main actors of the TEPE Pilot Application Scenario. Four of these actors are medical institutes, namely TEPE Hospital, Hacettepe Hospital, Istanbul Hospital and Cankaya Laboratory. Additionally there is a mobile peer located in an ambulance and an insurance company. Each one of these medical service providers uses its own system and hence utilizes its own standards for data sharing and transfer. The coding scheme and messaging structure of each healthcare provider are as follows:    

TEPE Hospital uses CPT (Current Procedural Terminology) coding scheme with HL7 v3 message structure. Hacettepe Hospital uses BUT coding scheme with HL7 v2.3.1 message structure. Istanbul Hospital uses BUT coding scheme with proprietary message structure. Cankaya Laboratory uses LOINC coding scheme with proprietary message structure.

Figure 3: TEPE Scenario Standards TEPE Hospital uses corTTex application, which uses CPT codes in order to describe health care services and procedures applied in the treatment of patients. In Turkey, there is a national directive, called Budget Application Directive (Butce Uygulama Talimati, “BUT” in Turkish) to determine the cost of healthcare services applied to the patients. This directive defines codes for the healthcare services; in this respect it has similar codes to CPT1. In our prototype

1

For example, CPT code C17340.00 corresponds to “CRYOTHERAPY (CO2 SLUSH, LIQUID N2) FOR ACNE”, and BUT code 16007 corresponds to “KRIYOTERAPI (in Turkish)”.
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 19 of 39

IST-2103 STP ARTEMIS

11/3/2009

scenario Istanbul Hospital conforms to BUT codes. Each time TEPE Hospital retrieves results of a Web service of Istanbul Hospital, the operation codes which are in BUT are mapped to CPT codes by the ARTEMIS Mediator Component. In the prototype, Istanbul Hospital and Hacettepe Hospital use Care2X application in their system. Both of these hospitals use BUT coding scheme. In addition, another Care2X is deployed for the Cankaya Laboratory operations. Cankaya Laboratory uses LOINC codes (Logical Observation Identifiers Names and Codes) to identify the laboratory observations, while TEPE Hospital uses CPT codes for the same purpose2. ARTEMIS mediator maps the parameters of the PlaceLabOrder and PushLabResults Web services in order to transform LOINC codes to CPT codes and vice versa. In the scenario, Retrieve History Web service which belongs to Hacettepe Hospital, exchanges HL7 v2.3.1 compliant EDI messages, whereas TEPE corTTex is HL7 v3 compliant XML messages. At run time when the Retrieve History Web service is invoked by corTTex in TEPE Hospital, the returned EDI messages are converted to OWL, and an OWL2OWL mapping takes place in order to provide interoperability of HL7 v3 and HL7 v2.x. This mapping process is realized by an OWL mapping tool developed by METU. Therefore, ARTEMIS provides semantics and value mediation among medical institutes. In TEPE Pilot Application Scenario, the communication between TEPE Hospital and the insurance company is performed using HIPAA based transactions. The „Health Insurance Portability and Accountability Act‟ is a federal law requiring hospitals, physicians, and managed care companies to adopt medical information security, privacy and data standards to help people buy and keep health insurance, even when they have serious health conditions, and ensure that continuously covered individuals with preexisting conditions are not excluded from group health insurance coverage, preventing fraud and abuse, and providing for medical savings accounts. In the scenario, TEPE Hospital will provide the input messages in XML format conforming to HL7 v3 RIM, and the web service provided by the insurance company will expect HIPAA messages in ANSI X12 EDI format. The tool for transformation between XML and HIPAA message has been developed. The necessary mappings will be handled by the ARTEMIS Ontology mapping tool. As mentioned in the introduction section of this document, in the ARTEMIS Platform there are three main types of ontologies: functionality, clinical concept and message ontologies. The functionality ontology is used to annotate the functionality of the Web Services and HL7 events are used to develop the ontology. The Clinical Concept Ontologies (CCO), on the other hand, are developed based on the prominent healthcare standards and they can be thought of basic building blocks of messages in healthcare domain. The healthcare institutes are not expected to conform to these CCOs. They can develop their own ontologies (which are referred as Message Ontologies) that conform to the data model of their institute. In other words, the Message Ontologies describe the structure of input/output messages of exposed Web Services. In ARTEMIS, mediation is realized both at the CCO level and also at the Message Ontology level. At CCO level mediation, the organizations are expected to map their message ontologies to one of the clinical concept ontologies. In this case, the communicating parties do not need to know each other‟s message ontologies. However, bilateral communication is also possible in ARTEMIS. In other words, one institute can directly map its message ontology to the message ontology of the institute to which it wishes to communicate. Bilateral communication takes place between the insurance company and TEPE Hospital in the demonstration.

2

For example, CPT code 80051 stands for “ELECTROLYTE PANEL”, and LOINC code 24326-1 corresponds to “ELECTROLYTES HCFA 98 PANEL”.
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 20 of 39

IST-2103 STP ARTEMIS

11/3/2009

4.3.1 Setup Phase
In the setup phase the institutes register themselves and advertise their Web services to the ARTEMIS Network. In the following subsections, the setup of TEPE Hospital is elaborated. In the setup phase mainly the following steps are performed:    

  

The user registers its institute to ARTEMIS. The user selects the ontologies (clinical concept, functionality and expertise) that his institute conforms to. The user defines the expertise areas of his institute from the expertise ontology selected in the previous step. The user creates the message ontology of the institute. In this process, the user provides the URL of the XSD documents. In ARTEMIS there are two types of XSD documents: an XSD document describing the inputs and outputs of a Web Service and an XSD document describing the message structure of a legacy application of an institute (i.e. application interface). When interacting with ARTEMIS, the legacy application uses messages in its own format and retrieves results from ARTEMIS in the same format. The XSD documents are converted to OWL to create message ontologies of either the Web Service or the institute. The user defines mappings between the CCOs he selected earlier and the message ontology generated. The user advertises the mappings to the mediator. If the medical institute has Web Services, the user advertises them to the mediator. In turn, the mediator advertises them to its Web Service registry.

In this section each of these steps will be elaborated in detail. It should be noted that prior to the setup phase, the Clinical Concept, Functionality and Expertise Ontologies and mappings among Clinical Concept Ontologies should be ready and should be deployed to the Mediator. This process is described in the next section. 4.3.1.1 Ontology Deployment There is an ARTEMIS Ontology that represents all of the entities in the ARTEMIS Platform. The ontology is used in advertisement and discovery processes. The ontology is developed based on the object model of the ARTEMIS Platform. When an institute advertises an entity (such as ontology, an ontology mapping, a service, an organization or business process template) the advertisement is dispatched from the peer to the mediator as an instance of this ontology. It should be noted that this ontology is deployed to the ontology server of the mediator at the very first step in the initialization process. After obtaining the advertisement, the mediator deploys it to its ontology server, if it is not a service advertisement. If it is service advertisement, the mediator publishes the service to its UDDI service registry. The ARTEMIS Ontology is available at http://144.122.230.64:8080/artemis/artemis-ontology.owl Afterwards, a peer which we call ontology manager, joins to the ARTEMIS network, and deploys the necessary ontologies and their associated mappings. Three types of ontologies should be deployed to the mediator, before any healthcare service requestor/provider peer joins to the ARTEMIS network: 1- Functionality Ontology: Currently we have one functionality ontology developed based on the events defined by HL7. The functionality ontology is available at http://144.122.230.64:8080/artemis/HL7FuncOnt.owl 2- Clinical Concept Ontologies: There are three standards in the demonstration: CPT, BUT and LOINC. For each of these standard term lists, one Clinical Concept Ontology (CCO) is developed. The CCOs are available at; a. http://144.122.230.64:8080/artemis/CCOBUT.owl
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 21 of 39

IST-2103 STP ARTEMIS b. http://144.122.230.64:8080/artemis/CCOCPT.owl c. http://144.122.230.64:8080/artemis/CCOLOINC.owl

11/3/2009

It is worth mentioning that the BUT clinical concept ontology includes a class, called Operation, which represent an operation in medical domain, and the CCO of LOINC contains a Test class representing a laboratory test. The CPT CCO includes a description of both Operation and Test classes. When TEPE Hospital communicates with Istanbul Hospital and Cankaya Laboratory, these codes are translated from CPT to LOINC/BUT or vice versa. 3- Expertise Ontology: Furthermore, we developed an expertise ontology according to HIPAA product taxonomy. The ontology can be found at http://144.122.230.64:8080/artemis/ExpertiseOnt.owl Each of the institutes involved in the scenario use different standards. In order to provide interoperability among these institutes, mapping should be defined between their CCOs. Note that ARTEMIS platform provides not only value mappings but also semantic mappings. The semantic mapping takes place both in the HL7 v3 and HL7 v2.x interoperation through OWL mapping. These mappings are OWL2OWL mappings and defined through the OWLmt tool developed by METU. The mappings are loaded to the system when the mediator is initiated. Figure 4 shows the lifecycle of creating ontologies and advertising them in ARTEMIS. Each step is described in detail in the following section.

Figure 4: Ontology Deployment

1. Design Ontologies: In ARTEMIS, Ontologies are designed using Protégé which can be accessed through the CreateOntology Definition Menu in the user interface. Protégé was adapted in such a way that it can store ontology definitions to ARTEMIS Peer Repositories through its main menu. 2. Design Mappings: In ARTEMIS, ontology mappings are designed through the OWLmt tool (developed by METU) available at the CreateOntology Mapping Menu. OWLmt handles ontology mediation by mapping the OWL ontologies in different structures and with an overlapping content one into the other. The architecture of the system allows mapping patterns to be specified through a GUI tool based on a Mapping Schema. The Mapping Schema is also defined in OWL and available at http://144.122.230.64:8080/artemis/Mapping_Schema.owl
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 22 of 39

IST-2103 STP ARTEMIS

11/3/2009

3. Advertise Ontologies: Ontologies can be advertised through the AdvertiseOntology menu item. Ontologies saved at the peer repository are presented to the user who can select one of them and click on the advertise button to send the advertisement to the Mediator. 4. Add Ontologies to Sesame Ontology Server: When the advertisement message is received by the mediator, it adds the ontologies to its Ontology server for further use. 5. Deploy Functionality Ontology to Web Service Registries: When a functionality ontology, in our case HL7 Functionality Ontology, is advertised to the Mediator, it is also deployed to the Mediator Service Registry. The ontology will be used later to annotate the web services published to the Web service Registry. 6. Advertise Mappings: When the user advertises the ontology mappings to the mediator, the mappings are retrieved from the peer repository and presented to the user. In this step and according to the scenario, the following mappings between the clinical concept ontologies are advertised: a. LOINC  CPT b. CPT  LOINC c. BUT  CPT d. CPTBUT Likewise, an instance of “OntologyMapping” class of ARTEMIS ontology is created and sent to the mediator. 7. Add Mappings to Sesame Ontology Server: When the advertisement message is received by the mediator, it adds the ontology mapping definitions to its Ontology server for further use. 4.3.1.2 TEPE Hospital Setup In this section the setup of TEPE Hospital is described, Figure 5 illustrates the main steps to be performed during the setup phase of a healthcare institute. 1. Register ARTEMIS: After the initialization of the system, the user first registers the TEPE Hospital to the ARTEMIS Network by selecting System  Register  Organization. The user enters the information pertaining to the TEPE Hospital and presses the “Next” Button. 2. Retrieve available Ontologies: Meanwhile the ontologies previously deployed (Section 4.3.1.1) to the ARTEMIS Network are retrieved from the mediator and presented to the user. Communication between peers and mediators is performed using a generic messaging framework. Peers and mediators exchange messages that are handled by dynamically configurable processors. There is a specific message processor for handling Query Request/Response messages for remote interrogation of ARTEMIS Ontology Server by a mediator. In this step the peer obtains the ontologies from the mediator by using the discovery API, which in turn exploits this Query Request/Response processor. 3. The mediator obtains a list of the ontologies available on its Ontology server and forwards it to the peer. 4. Selects ontologies: The user selects the ontologies (functionality, clinical concept and expertise ontologies) that TEPE Hospital conforms to. The user selects the CPT clinical concept ontology and presses the “Next” button to proceed to the last step of registration. 5. Select Expertise: In this step, the selected expertise ontology is parsed and displayed to the user. The user selects the “Emergency_Medical_Service_Providers” node from
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 23 of 39

IST-2103 STP ARTEMIS the expertise ontology.

11/3/2009

6. Advertise Organization: After completing the registration process, an instance of the “Organization” class of ARTEMIS Ontology is generated and sent to the mediator along with other information gathered from the registration process. 7. Add Organization to Sesame Ontology Server: Having received the organization registration message, the mediator deploys the ontology instance to its ontology server.

Figure 5: TEPE Hospital Setup Steps 8. Create Application Message Ontology: After that the user creates the Application Message Ontology by specifying the Message Structure of the legacy application of TEPE Hospital. The message structure is in XSD and the generated message ontology is in OWL. It should be noted that the Application Message Ontology represents the structure of the messages that the legacy application exchanges in its consumer role in ARTEMIS. In the generation of OWL message ontology from XSD document, ARTEMIS Platform benefited from the Normalization Tool developed in the scope of Harmonise Project3. The Normalization Tool converts an XSD document into an RDFS document. In Harmonise, this process is called Conceptual Normalization (CNormalization) phase where the C-Normalization engine parses the XML Schema, and using a set of predefined “Normalization Heuristics”, creates the corresponding RDFS schema components for each XML Schema component automatically. However since we need OWL Schemas instead of RDFS schemas, we developed an
3

Harmonise, IST200029329, Tourism Harmonisation Network, Deliverable 3.2 Semantic mapping and Reconciliation Engine subsystems.

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 24 of 39

IST-2103 STP ARTEMIS OWL wrapper using Jena API to create OWL schemas from the RDFS files.

11/3/2009

After this step, optionally, the user specifies the URL of the XSL file which is used to transform the resulting invocation messages from XML to HTML for display purposes. In other words, if the user provides the XSL document, the Web Service invocation results delivered to the peer (as XML) are presented to the user as an HTML through XSL transformation. Create Message Ontology for “Admit Patient Service”: In the same manner the user specifies the XSD definition for the Admit Patient Service of TEPE Hospital. In the previous step the user specified the structure of the messages its legacy application exchanges. Whereas in this case the user specifies the structure of the input/output messages of the Web Service. Create Message Ontology for “Push Lab Results Service”: Likewise, the user specifies the XSD definition for the Push Lab Results Service of TEPE Hospital. 9. Advertise Application Message Ontology: After pressing the “Generate OWL” button an instance of “MessageOntology” class of ARTEMIS Ontology is generated and sent to the mediator. Similarly, the user can advertise the message ontology for the AdmitPatient Service and the PushLabResults Service. 10. Add Application Message Ontology to Sesame ontology server: The mediator deploys the received “MessageOntology” instances to its ontology server. 11. Create Mapping definition between TEPE Application Message Ontology and CPT Clinical Concept Ontology: The user defines the mapping between application message ontology and CPT clinical concept ontology. It should be noted that the mapping definition is one-way. In other words, through the OWLmt mapping tool the user defines mapping rules from a source ontology to a target ontology. Hence the user defines mappings from message ontology to CPT and vice versa. The user selects the source ontology, target ontology and presses the “Create Mapping” button. In this step, the user do not have to define a mapping from scratch, he is allowed to provide the URL of the previously created mapping definition. Create Mapping definition between “Admit Patient Service” and CPT Clinical Concept Ontology: Likewise, the user creates the mapping between the Admit Patient Web Service message ontology and CPT Clinical Concept ontology. Create Mapping definition between “Push Lab Results Service” and CPT Clinical Concept Ontology: Likewise, the user creates the mapping between the Push Lab Results Web Service message ontology and CPT Clinical Concept ontology. 12. Advertise Mapping definitions: After creation of the mappings, the user advertises the mappings created in step 11 to the mediator. After pressing the “Advertise Mapping” button, an instance of “MappingDefinition” class of ARTEMIS Ontology is created and sent to the mediator. 13. Add Mapping Definition to Sesame ontology server: Having received the mapping advertisements, the mediator deploys these instances to its ontology server. 14. Advertise “Admit Patient” Services: The advertisement of a Web Service includes two steps. In the first step the user specifies the WSDL URL of the Web Service and selects the functionality of the Web Service. In the second step, the user sets the input and output nodes of the Web Service and specifies whether the input/output is XML or EDI. In this step, the functionality ontology is parsed and displayed to the user. The user selects the “RegisterService” node from the ontology, specifies the WSDL URL and the security policy file location (if the Web service is secured) presses the “Next”
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 25 of 39

IST-2103 STP ARTEMIS

11/3/2009

button. In the second step, the user chooses “XML” from the combobox and selects the input and output from the Message Ontology of Admit Patient Service (created in step 8) and presses the “Finish” button. Advertise “Push Lab Results Service”: In the same manner, in the first step, the user selects the “PlacerService” node from the functionality ontology, specifies the WSDL URL and presses the “Next” button. In the second step, the user selects “XML” from the combobox, chooses the input (PLRInputMessageType) and output (PLROutputMessageType) from the message ontology of “Push Lab Results” Web Service and presses the “Finish” button. 15. Publish “Admit Patient” and “Push Lab Results” Services to Mediator Registry: After advertising each service, the peer creates an OWL-S definition of the service and sends it to the mediator. In turn, the mediator publishes the advertisement to its service registry. In this process, the mediator first queries the tModel corresponding to the service functionality ontology node. It should be noted that the functionality ontology is previously deployed to the UDDI registry, as described in Section 4.3.1.1. After that the mediator queries the businessInfo class that belongs to TEPE Hospital and creates a new serviceInfo class for each Web Service. Additionally, the mediator puts the tModel corresponding to service into the category bag of this serviceInfo class and adds its WSDL and OWL-S URL before publishing it to the UDDI registry. 4.3.1.3 Care2X Setup Care2X is an open source software which is developed for hospitals and health care organizations. It is designed to integrate the different information systems existing in these organizations into one single efficient system. It is a web based software and all its functions can be accessed with a common web. Care2X software provides developers to integrate additional functionalities through plugins. Care2x is adopted by Hacettepe and Istanbul Hospitals and Cankaya Laboratory. This section describes the steps for registering a new patient at any of these hospitals. First, the patient details are added to a registration form shown in Figure 6.

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 26 of 39

IST-2103 STP ARTEMIS

11/3/2009

Figure 6: Patient Registration in Care2x After registering the patient, the patient details are fed to ARTEMIS via the Patient Identity Feed Plugin developed by OFFIS. The next step is to set the diagnosis for the patient. This process is illustrated in Figure 7.

Figure 7: Patient Diagnosis

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 27 of 39

IST-2103 STP ARTEMIS

11/3/2009

After the patient is admitted to the hospital the user can set patients allergies, operations, notes. Etc. (Figure 8).

Figure 8: Patient Allergies

4.3.2 Implementation Phase
In this phase the scenario defined the previous section is executed. Mainly three actors operate the scenario: the first-aid person in ambulance, the doctor in TEPE Hospital and the user in Cankaya Laboratory. First the ambulance user queries and invokes the “Admit Patient Service” of TEPE Hospital. After that the user in TEPE Hospital invokes the: 1. “Retrieve Critical Health Data” and “Retrieve History” services of Istanbul Hospital 2. “Retrieve History” service of Hacettepe Hospital 3. “Place Lab Order” Service of Cankaya Laboratory 4. “Push Lab Results” service of TEPE Hospital is invoked by the user of Cankaya Laboratory 5. Finally, the user in TEPE Hospital invokes “On-line Claim Processing” service of the insurance company The ambulance user uses a PDA for connecting to the mobile peer. On the other hand, the users of TEPE Hospital and Cankaya Laboratory use the graphical user interface of their own legacy applications (corTTex and Care2X). These applications are integrated into ARTEMIS through the Web Service interface of the peer. The invocation of the discovered Web Services is depicted in Figure 9. - Creates an XML input that conforms to the requesting organization‟s application message structure. - After invocation, the result is delivered to the peer in a form that the peer can understand (i.e. an OWL instance that conforms to its message ontology or that conforms to the clinical concept ontology that the peer adheres) - Invokes the “Invoke Interface Web Service” of the peer with this XML message.
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 28 of 39

IST-2103 STP ARTEMIS - The peer normalizes the XML message to OWL and sends it to mediator

11/3/2009

- The Mediator converts the OWL message to another OWL instance that conforms to the message ontology of the Web Service provider organization either performing direct or several mappings. - If the Web Service accepts:  OWL, then mediator invokes it with this message.  XML, then mediator translates the OWL to XML and invoke the Web Service.  EDI, then mediator translates the OWL to XML and the XML to EDI and invokes the Web Service. - After invocation, the result is delivered to the peer in a form that the peer can understand (i.e. an OWL instance that conforms to its message ontology or that conforms to the clinical concept ontology that the peer adheres) - The peer converts this OWL to XML and delivers the requesting application as the result of the “Invoke Interface Web Service”.

DISCOVERY PHASE
2- Query Organization 1- Select Expertise

5- Query Web Service

3- Select Organization

11- Translate it to another OWL that conforms to the CCO to which the provider conforms

4- Select Functionality

6- Select Web Service

12- Translate it to another OWL that conforms to the MO of the Web Service

7- Generate XML input

8Generate OWL conformant to MO 13- Translate it to XML that conforms to XSD of the Web Service Secure 14- Invoke Web Service P2P Messagi ng Secure P2P Messagi ng 9- Translate it conformant to CCO to

input

OWL

10- Send Invocation Message

15- Translate the XML result to OWL

16- Translate it to another OWL that conforms to the CCO to which the provider conforms

18- Translate it to another OWL that conforms to the MO to which the requestor conforms

17- Translate it to another OWL that conforms to the CCO to which the requestor conforms

19- Convert it to XML and deliver the result either to the user or to the application

MEDIATOR
INVOCATION PHASE

PEER

Figure 9: Implementation Phase Steps
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 29 of 39

IST-2103 STP ARTEMIS 4.3.2.1 Admit Patient from Ambulance

11/3/2009

The ambulance crew suspects about “myocardial infarct” and searches the ARTEMIS network for a hospital with facilities to admit a patient with cardiovascular disease through a mobile device. The ARTEMIS network supplies a list of hospitals and the paramedic selects the TEPE Hospital as the most appropriate one. After the TEPE Hospital is selected, the user supplies patient‟s personal information and his vital signs. Meanwhile, the patient is placed in the worklist of the emergency doctor in TEPE Hospital in make him/her aware of the expected arrival of the patient. 4.3.2.2 Retrieve Critical Health Data of Istanbul Hospital After the invocation of AdmitPatient Service from the ambulance, the patient drops to Emergency Department doctor‟s worklist as shown in Figure 10.

Figure 10: corTTex Worklist The initial diagnosis from the ambulance is displayed to the doctor (Figure 11).

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 30 of 39

IST-2103 STP ARTEMIS

11/3/2009

Figure 11: Initial Diagnosis The doctor initiates the retrieval of previous data of the patient from the ARTEMIS network. At this point, the first PID Query (Figure 12) starts searching for patient demographics in other hospitals on the network. The doctor can select the right patient according to the relevance of the demographics data (matching weight - Figure 13). After that the patient‟s history is retrieved from responding hospitals and displayed to the doctor (Figure 14).

Figure 12: PID Query Input
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 31 of 39

IST-2103 STP ARTEMIS

11/3/2009

Figure 13: PID Query Result

Figure 14: History of Patient Data 4.3.2.3 Retrieve History of Hacettepe Hospital The Web service invocation of the Retrieve History of Hacettepe Hospital occurs at the step of retrieving existing data of patient if the selected candidate found in PID Query (Section4.3.2.2) belongs to the Hacettepe Hospital.

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 32 of 39

IST-2103 STP ARTEMIS 4.3.2.4 Retrieve History of Istanbul Hospital

11/3/2009

The Web service invocation of the Retrieve History of Hacettepe Hospital occurs at the step of retrieving existing data of patient if the selected candidate found in PID Query (Section 4.3.2.2) belongs to the Istanbul Hospital (Figure 13). 4.3.2.5 Place Lab Order of Cankaya Laboratory The doctor realizes that Mr Okcan have got a reference to a surgical operation in his medical records and a reference to a “Coronary artery bypass, vein only; single coronary venous graft”. In order to decide the right treatment, the doctor places a lab order (Figure 15) for “Creatine Kinase (CK), (CPK); MB fraction only” and “Creatine Kinase, Total (CK)”.

Figure 15: Place Lab Order An external lab order is invoked to Cankaya Laboratory (Figure 16).

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 33 of 39

IST-2103 STP ARTEMIS

11/3/2009

Figure 16: External Lab Order –TEPE Hospital The Labtest request ordered from TEPE Hospital are received by Cankaya Lab (Figure 17).

Figure 17: Care2X Pending Lab Order Panel

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 34 of 39

IST-2103 STP ARTEMIS 4.3.2.6 Push Lab Results of TEPE Hospital

11/3/2009

After the lab order is processed, Cankaya Laboratory peer invokes the Push Lab Results web service of TEPE Hospital and the lab results are forwarded to the TEPE Hospital application. The doctor in TEPE Hospital reviews the lab results and decides that Mr Okcan‟s health condition is uncritical. 4.3.2.7 On-Line Claim Processing of Insurance Company After deciding that Mr. Okcan‟s condition is stable and requires no further treatment, provision requests are submitted to the relevant insurance company for payment for the services provided to Mr. Okcan.

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 35 of 39

IST-2103 STP ARTEMIS

11/3/2009

5 SEBT-TEPE Integrated Scenario
5.1 OVERVIEW
This scenario is based on merging both the SEBT and TEPE scenario into a single application that can allow the YPC users to invoke the services of the Hacettepe Hospital to complete that assessment of one of their patients. One of the patients referred by the GP to the YPC centre required further investigation before creating his care plan. During the referral assessment the Key Worker responsible for the case searches the ARTEMIS network for relevant patient information using the PID/RID infrastructure. The PID/RID process comprises three major phases, first, the PID (Person Identification) phase deals with the query for candidates matching a specific, user entered set of patient demographic data. Second, the datasets containing the patient information is searched where the RID (Retrieve Information for display) phase deals with the retrieval of information and links to documents related to the candidates found in phase 1. Finally, the RDD (Retrieve document for display) phase, handles the process of displaying related documents to the user who initiated the request. When the Key Worker enters the patient‟s demographic information into the system, it invokes the RetrieveHistory web service of Hacettepe Hospital which shows the patient has had some previous treatment for a broken arm and has no other related information to the current episode. The Key Worker considers this information as irrelevant to the current treatment and decides to carry on with the assessment process. The scenario has been realized in two different approaches (Figure 18). In the first approach, it is assumed that the PID/RID infrastructure can only work with one mediator (M1) and all ARTEMIS peers (i.e. YPS and Hacettepe Hospital) connected to that mediator. In this case the PID/RID protocol can easily search the Hacettepe Hospital database, retrieve the patient history and forward it back to the YPC centre. The second approach, uses two mediators representing the Northern Ireland and Turkish healthcare domains. Each healthcare organization registers with their regional mediator. The Key Worker can now discover the RetrieveHistory service of Hacettepe Hospital using the ARTEMIS semantic routing capabilities. The Key Worker uses the local mediator (M1) to find available services at the Hacettepe Hospital, which will forward the request to the second mediator (M2) based on the semantic information it holds on its system. The second mediator also forwards the request to the Hacettepe Hospital which retrieves the data and sends it directly to the YPC. As shown in the Figure 18, the SEBT peer conforms to the CPT CCO while Hacettepe peer conforms to the BUT CCO. Based on these, during an invocation the following mapping chain has to be executed: SEBT  CPT  BUT  RetrieveHistory In the first approach the mapping is performed by M1 which carries out all the mediation between both peers. In the second approach, the mapping is performed by M2, while M1 is only responsible for diverting search requests to M2 if it happened to have the information requested by the YPC.
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 36 of 39

IST-2103 STP ARTEMIS

11/3/2009

Figure 18: TEPE-SEBT Scenario Integration General Overview

5.2 DEPLOYMENT
The setup and implementation phase of the integrated scenario is similar to those of the separate scenarios. However, the introduction of a second mediator to the network required
2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 37 of 39

IST-2103 STP ARTEMIS

11/3/2009

ontologies to be advertised to only one mediator, as it will be discovered by the other mediator through semantic routing. Also, each peer will only advertise its messaging ontology, mappings, and web services to its local mediator. The overall deployment diagram of the SEBT-TEPE integrated scenario is shown in Figure 19. Based on the second approach of this scenario, after the Hacettepe Hospital registers itself with the Turkish Mediator M2, it sends a message to the mediator to advertise its RetrieveHistory Service. Accordingly, the Turkish Mediator creates an index denoting the availability of this service at Hacettepe Hospital and broadcast it to all mediators on the network including the Northern Ireland Mediator M1. The YPC then sends a secured JXTA message to the SEBT Mediator to find out Healthcare organizations that provide RetrieveHistory services. Based on the indices kept at the Northern Ireland Mediator, the request is forwarded to the Turkish Mediator which replies with the relevant information for invoking this service at Hacettepe Hospital. The YPC then invokes this service (using a secured SOAP message) through the Turkish Mediator which maps between the messaging structure of the YPC and the messaging structure of the Hacettepe Hospital. When the Hacettepe retrieves the requested information, it replies back through the same route in order for the Turkish Mediator to perform the reverse mapping on the message before forwarding it back the YPC.

Figure 19: SEBT-TEP Integrated Scenario Figure 19 shows not only the configuration of peers and mediators in each scenario, but it also gives a clear indication of all the necessary databases, ontology servers and UDDI registries necessary for each component to perform its function. This serves as a useful plan when taking into consideration future developments and deployment.

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 38 of 39

IST-2103 STP ARTEMIS

11/3/2009

6 Conclusions
The document has shown that the ARTEMIS project has successfully developed and deployed an infrastructure that provides interoperability of medical information systems to healthcare professionals through semantically enriched Web Services and peer-to-peer technologies. The semantically enriched Web Services utilize the ontology mapping technology supported by ARTEMIS to facilitate Healthcare organizations to communicate with each other using their own messaging standards and communication protocols. Meanwhile, the peer-to-peer infrastructure provides ARTEMIS with the resources needed to enable healthcare organizations to discover and use healthcare web services regardless to their location. During the ARTEMIS project, two pilot application scenarios have been deployed using the ARTEMIS infrastructure. The two scenarios, namely SEBT and TEPE are described in terms of their deployment mechanisms, the services they provide, the ontologies they adopt and the setup and implementation steps they require. A third application scenario was introduced to show how can SEBT application scenario users utilize the ARTEMIS semantic routing feature to discover healthcare services and information maintained by the TEPE application scenario. In this integrated scenario, both SEBT and TEPE pilot application scenarios were merged and the Hacettepe Hospital services were used by the YPC to obtain patient records and other related information. The application scenarios described in this document show how healthcare organizations using different information systems can describe their web services and medical information using different message structures and healthcare ontologies, and allow healthcare professionals to transparently discover this information regardless to their location.

2006 University of Southampton, IT Innovation Centre and other members of the ARTEMIS consortium

Page 39 of 39


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:49
posted:11/3/2009
language:English
pages:39