- Email: [email protected]
Cross-enterprise search and access to clinical information based on IHE Retrieve Information for Display
International Congress Series 1281 (2005) 986 – 991
www.ics-elsevier.com
Cross-enterprise search and access to clinical information based on IHE Retrieve Information for Display Thomas AdenT, Marco Eichelberg OFFIS e.V., Escherweg 2, 26121 Oldenburg, Germany
Abstract. One important problem of information systems in healthcare is the localisation and access to electronic patient records across healthcare institute boundaries, especially in an international setting. The Integrating the Healthcare Enterprise initiative proposes the Retrieve Information for Display integration profile that enables a user to retrieve and display patient related documents on systems other than the document keeping systems. The starting point for retrieval is a patient ID that a user must be aware of. The research project ARTEMIS is developing a semantic web based P2P interoperability infrastructure for healthcare information systems. To allow access to patient related documents with the Retrieve Information for Display profile in an ARTEMIS P2P network beyond enterprise boundaries it is inevitable to locate such documents and to retrieve the patient ID first in conformance with access authorisation and privacy regulations. The Patient Identification Protocol established in the ATRTEMIS framework allows such retrieval and thus enables the binding to the Retrieve Information for Display profile. D 2005 CARS & Elsevier B.V. All rights reserved. Keywords: Integrating the Healthcare Enterprise; Retrieve Information for Display; Patient identification protocol; P2P; Cross-enterprise document sharing
1. Introduction After more than 30 years of development in the field of healthcare information systems, the digital communication of clinical information across hospitals’ boundaries is still a rather rare event outside the limited scope of telemedicine applications. The exchange of discharge letters, diagnostic reports and medical imagery most often takes place in conventional paper-based form, or on storage media such as CD or DVD at best, given the T Corresponding author. E-mail address: [email protected] (T. Aden). 0531-5131/ D 2005 CARS & Elsevier B.V. All rights reserved. doi:10.1016/j.ics.2005.03.131
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
987
absence of central electronic healthcare record archives in most countries. In many cases it would be of significant benefit if a doctor had direct access to prior clinical documentation for the patient, even if it was just a simple visual presentation along the lines of a web page. 2. Methods The Integrating the Healthcare Enterprise (IHE) initiative proposes a solution for retrieving and displaying patient-centric clinical information from a system other than the user’s current application within one hospital or a trust of hospitals. The bRetrieve Information for DisplayQ (RID) integration profile is described in the IHE Technical Framework [1]. THE RID profile describes access to existing persistent documents in well-known presentation formats such as the HL7 Clinical Document Architecture (CDA), PDF, JPEG, etc., as well as access to specific key patient-centric information such as allergies, current medications, summary of reports, etc., for presentation to a clinician. The RID integration profile describes two bactorsQ (IT systems involved in the document retrieval), called the bInformation SourceQ, and the bDisplayQ. The Information Source is a system that maintains a database of persistent clinical documents and specific key patientcentric information such as allergies, current medications, summary of reports, etc. The Display is a system that accesses the Information Source, retrieves patient-centric information or persistent documents, and displays them to a human observer. IHE defines the transactions (i. e. communication events) between both systems that implement the document retrieval process. Communication between Display and Information Source is always initiated by the Display and is implemented as a Web service. The WSDL description of different Information Sources may vary according to the RID features implemented, but there is a generic template defined by IHE that very much restricts the possible variations. There are two different transactions that a Display may use with the Information Source: Retrieve Document for Display: this transaction is used to request transmission of a persistent document. The Display needs to provide a unique identifier (UID) for the persistent document along with some additional parameters, such as the preferred format the document is to be provided (JPEG, CDA or PDF) and the formats which are acceptable for the response at all (JPEG, CDA, PDF or others). If successful, the Information Source returns the requested document as payload of the HTTP response. Finally, the Display renders the document in a human-readable form. Retrieve Specific Information for Display: This transaction is used to access information available on the Information Source actor that is not represented as a persistent document, because it needs to be updated rather frequently. This includes lists (list of allergies and adverse reactions for a patient, list of medications currently taken by or administered to a patient) and summaries (of reports, i.e. persistent documents). The result of the request, if successful, is returned as a XHTML web page that may contain hyperlinks, in particular to persistent documents that can be retrieved using the Retrieve Document for Display transaction. In the case of a list request, the Display provides a patient ID (which has to be known apriori or communicated by a means outside the scope of the RID profile) and the desired type of list (allergies or medications). The Information Source returns a XHTML web page as payload of the HTTP response.
988
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
In the case of a summary request, the Display also provides a patient ID. In addition it provides the type of summary requested (all reports, radiology reports, cardiology reports, etc.), the number of most recent results to be included into the response and optionally a constraint on the earliest or latest date/time of reports. Again the Information Source responds with a XHTML web page containing hyperlinks to the persistent documents referenced in the summary formulated as Web service calls to Retrieve Document for Display. The focus of the integration is visual presentation, not a complete integration of the structured databases on which the actors might be based. It is the responsibility of the Information Source to convert the healthcare specific semantics into a suitable presentation format. The Display, on the other hand, may process and render this presentation format with only generic healthcare semantics knowledge, but will in general not be able to provide any processing of the healthcare information beyond document Display. The number of commercial implementations of the RID integration profile is still limited, which is natural since the initial bfor trial implementationQ revision of the RID profile has only been published in August 2003. Nevertheless, implementations of Information Source and Display actors from several companies have already been successfully tested during IHE cross-vendor testing events in late 2003 and early 2004. This suggests that the market uptake might be rather quick. Although the RID profile is well suited for use in a single hospital or a trust of hospitals that belong to a single Patient Identifier Domain (i.e., use the same set of patient IDs), it is not designed for cross-boundary access on information stored in different hospitals infrastructure (see Fig. 1) that do not share a unified or at least compatible IT. One obvious reason for this limitation is that the Display actor needs a-priori knowledge about the patient ID of the patient to query for but many countries do not have a nationwide unique patient identification that could be used to identify a patient across hospitals. To solve the problem of cross Patient Identifier Domain access to information, for example via the Retrieve Information for Display the IHE proposes the Patient Identifier Cross-referencing Integration Profile (PIX) [1]. The PIX integration profile describes three bactorsQ, called the Patient Identity Source, the Patient Identifier Cross-reference Consumer, and the Patient Identity Cross-reference Manager. The Patient Identity Cross-reference Manager is a system that receives Patient Identity Feed messages from the Patient Identity Source actor, i.e. the Patient Identity
Fig. 1. Retrieve information for Display across Patient Identifier Domains.
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
989
Source actor sends notification messages about newly created, updated, or merged datasets about patient identifying data. Receiving such messages the Cross-reference Manager is responsible for linking together patient identifiers from those Patient Identifier Domains it manages by means of patient identifying data. The Cross-reference Consumer is a system (e.g. an Information Source) that queries the Cross-reference manager for a list of corresponding patient identifiers for a given patient ID (e.g. in a Retrieve Information for Display request) from a system that does not belong to the same Patient Identifier Domain. Although this profile is useful for managing multiple Patient Identifier Domains in a single enterprise or across cooperating enterprises it is not feasible in an international and scalable setting. The IST project ARTEMIS [2,3] addresses some of these problems. The objective of the ARTEMIS project is to develop a semantic Web services based interoperability framework for the healthcare domain. In particular, ARTEMIS aims at enabling medical practitioners to access medical information securely and seamlessly through a low-cost 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 provision of access to clinical records across enterprise and possibly even country boundaries requires a service for locating clinical records pertaining to a particular patient, and accessing the records found, under consideration of the high confidentiality constraints on patient records. Within the ARTEMIS network, clinical records can be located using the bPatient Identification ProtocolQ (PID Protocol) that has already been presented in an earlier paper [4]. The PID Protocol is a scalable cryptographic protocol that allows to identify and to locate institutes which have clinical records for a specific patient available. The protocol makes sure that the request itself cannot be interpreted by any party involved in the request, i.e. no information can be derived from the request or the responses to the request, except for a probability that requestor and provider have identifying information pertaining to the same person. Once a requestor has identified and located one or more institutes that have clinical records for a specific patient available, access to the record needs to be negotiated, given that the requestor can demonstrate the right to access the records. Thus the PID Protocol is in conformance with access authorisation and privacy regulations required e.g. by [5–9]. 3. Results Applied to the ARTEMIS infrastructure, the RID Information Source and Display actors may be located in different institutions using different Patient ID domains and different sets of demographic data. From the perspective of an enterprise that wants to connect an existing Information Source to the ARTEMIS network, i.e. provide clinical documents to requestors in the ARTEMIS network, the connection seems to be straightforward at first, given that IT security and access rights are provided: a Web service that implements the RID protocol may be provided through the ARTEMIS peer and registered at the mediator. From the perspective of an enterprise that wants to connect a Display actor to the ARTEMIS network, i.e. retrieve clinical documents over the
990
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
ARTEMIS network the issue seems more complex, because in this case neither the location of all Information Source actors is known a priori (due to the dynamic nature of the peer to peer network), nor are the remote Patient IDs known that are needed to retrieve lists of documents or clinical information from each Information Source. This is the point where the PID Protocol comes into play. The result of a query that is processed by the PID Protocol is a possibly large set of pairs of URIs and candidate identifiers and each of these pairs represents a peer that possibly provides information about the desired patient. Candidate identifiers are related to a single patient in the context of a single PID transaction and do not provide any semantic meaning to the requestor, i.e. a requestor cannot get any information about a patient from a candidate identifier directly. Since the PID Protocol provides candidate IDs which are not identical to local patient IDs, mainly because of data protection considerations, but the RID protocol is based on patient IDs, a mapping of the IDs must take place at the site that has generated the candidate IDs. Some simple components are needed to achieve those mappings and routing of requests and responses through the ARTEMIS network. Fig. 2 shows a simplified schema of those components necessary to combine an existing RID information source at the record repository site and an existing RID display system at the requestor site with an additional middleware layer to provide medical record access in combination with the PID protocol. On the repository site, a bsimulated displayQ receives the incoming requests from the requestor, replaces the candidate ID generated during the patient identi?cation process by the real patient ID locally used in the hospital and forwards the request to the existing information source, to which this actor looks like any local display actor. Before forwarding the response back to the requestor, all hyperlinks in the response have to be replaced with links pointing to the simulated display, because these hyperlinks will typically refer to resources that typically cannot be reached directly from outside the local network. Subsequent requests for these mapped hyperlinks would simply be redirected from the simulated display to the original resource. In a similar manner, a hyperlink lookup scheme can be implemented on the requestor site inside the bsimulated information source. As a side effect, the two bsimulatedQ actors can provide a secure tunnelling of the request and response message, which are usually transmitted in clear text form within a hospital, using any available transport level security protocol. A
Fig. 2. Retrieve information for Display integration into ARTEMIS.
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
991
detailed analysis about the protocol and combination of the PID protocol with the IHE RID profile can be found in [10]. 4. Conclusion The middleware infrastructure developed in the ARTEMIS project allows to extend the IHE RID protocol for cross-enterprise search, and access to patient-related clinical information, even if no Master Patient Index is available, and without modifications to existing Information Source actors (document repositories). The cryptographic protocol Patient Identification Protocol can also be combined with the IHE Cross-enterprise Document Sharing (XDS) Integration Profile [11], a new IHE work that also addresses the domain of exchange of clinical documents beyond enterprise boundaries. Acknowledgements The ARTEMIS project has received research funding from the EC’s Sixth Framework Programme (project IST-2103 STP under the eHealth Action Line of the Information Society Technologies Programme). References [1] HIMSS, RSNA, Integrating the Healthcare Enterprise (IHE)-IT Infrastructure Technical Framework Revision 1.1, http://www.rsna.org/IHE/tf/ihe_iti_tf_1.1_vol1_FT.pdf, http://www.rsna.org/IHE/tf/ihe_ iti_tf_1.1_vol2_FT.pdf (23 Feb. 2005). [2] A. Dogac, et al., Artemis: Deploying Semantically Enriched Web Services in the Healthcare Domain, Information Systems Journal special issue on Semantic Web and Web Services, Elsevier, in press. [3] Artemis Project, http://www.srdc.metu.edu.tr/webpage/projects/ (23 Feb. 2005). [4] T. Aden, M. Eichelberg, W. Thoben, A fault-tolerant cryptographic protocol for patient record requests, in: P. Inchingolo, P. Mucelli (Eds.), Proceedings of EuroPACS-MIR 2004 in the Enlarged Europe; 2004 Sept. 16–18, E.U.T. Edizioni Universita` di Trieste, Trieste (Italy), 2004, pp. 103 – 104. [5] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, OJ L, 23 Nov. 1995, http://europa.eu.int/com-m/internal_market/privacy/law_en.htm (23 Feb. 2005). [6] Council of Europe, European Convention for the Protection of Human Rights and Fundamental Freedoms, 4 November 1950 http://conventions.coe.int/Treaty/en/Treaties/Html/005.htm (23 Feb. 2005). [7] Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002, concerning the processing of personal data and the protection of privacy in the electronic communications sector, OJ L 201/37, 31 July 2002, http://europa.eu.int/information_society/topics/ecomm/useful_information/library/ legislation/index_en.htm (23 Feb. 2005). [8] Council Of Europe-Committee of Ministers, Recommendation No. R(97)5 of The Committee Of Ministers to Member States on the Protection Of Medical Data, Council of Europe Publishing, Strasbourg, 12 February 1997. [9] ISO/TC 215-International Organization for Standardization, ISO/DIS 22857 (Draft International Standard): Health Informatics—Guidelines on data protection to facilitate trans-border flows of personal health information, 2003. [10] T. Aden, M. Eichelberg, J. Riesmeier, Relevant Electronic Healthcare Record Standards and Protocols for Accessing Medical Information (ARTEMIS Deliverable D5.1.1), ARTEMIS Consortium, Oldenburg, Germany, 2004. [11] IHE IT Infrastructure Technical Framework, Supplement 2004–2005, Cross-Enterprise Document Sharing (XDS), Trial Implementation Version, http://www.rsna.org/IHE/tf/IHE_ITI_Cross-enterprise_Doc_Sharing_ 2004_08-15.pdf (23 Feb. 2004).
www.ics-elsevier.com
Cross-enterprise search and access to clinical information based on IHE Retrieve Information for Display Thomas AdenT, Marco Eichelberg OFFIS e.V., Escherweg 2, 26121 Oldenburg, Germany
Abstract. One important problem of information systems in healthcare is the localisation and access to electronic patient records across healthcare institute boundaries, especially in an international setting. The Integrating the Healthcare Enterprise initiative proposes the Retrieve Information for Display integration profile that enables a user to retrieve and display patient related documents on systems other than the document keeping systems. The starting point for retrieval is a patient ID that a user must be aware of. The research project ARTEMIS is developing a semantic web based P2P interoperability infrastructure for healthcare information systems. To allow access to patient related documents with the Retrieve Information for Display profile in an ARTEMIS P2P network beyond enterprise boundaries it is inevitable to locate such documents and to retrieve the patient ID first in conformance with access authorisation and privacy regulations. The Patient Identification Protocol established in the ATRTEMIS framework allows such retrieval and thus enables the binding to the Retrieve Information for Display profile. D 2005 CARS & Elsevier B.V. All rights reserved. Keywords: Integrating the Healthcare Enterprise; Retrieve Information for Display; Patient identification protocol; P2P; Cross-enterprise document sharing
1. Introduction After more than 30 years of development in the field of healthcare information systems, the digital communication of clinical information across hospitals’ boundaries is still a rather rare event outside the limited scope of telemedicine applications. The exchange of discharge letters, diagnostic reports and medical imagery most often takes place in conventional paper-based form, or on storage media such as CD or DVD at best, given the T Corresponding author. E-mail address: [email protected] (T. Aden). 0531-5131/ D 2005 CARS & Elsevier B.V. All rights reserved. doi:10.1016/j.ics.2005.03.131
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
987
absence of central electronic healthcare record archives in most countries. In many cases it would be of significant benefit if a doctor had direct access to prior clinical documentation for the patient, even if it was just a simple visual presentation along the lines of a web page. 2. Methods The Integrating the Healthcare Enterprise (IHE) initiative proposes a solution for retrieving and displaying patient-centric clinical information from a system other than the user’s current application within one hospital or a trust of hospitals. The bRetrieve Information for DisplayQ (RID) integration profile is described in the IHE Technical Framework [1]. THE RID profile describes access to existing persistent documents in well-known presentation formats such as the HL7 Clinical Document Architecture (CDA), PDF, JPEG, etc., as well as access to specific key patient-centric information such as allergies, current medications, summary of reports, etc., for presentation to a clinician. The RID integration profile describes two bactorsQ (IT systems involved in the document retrieval), called the bInformation SourceQ, and the bDisplayQ. The Information Source is a system that maintains a database of persistent clinical documents and specific key patientcentric information such as allergies, current medications, summary of reports, etc. The Display is a system that accesses the Information Source, retrieves patient-centric information or persistent documents, and displays them to a human observer. IHE defines the transactions (i. e. communication events) between both systems that implement the document retrieval process. Communication between Display and Information Source is always initiated by the Display and is implemented as a Web service. The WSDL description of different Information Sources may vary according to the RID features implemented, but there is a generic template defined by IHE that very much restricts the possible variations. There are two different transactions that a Display may use with the Information Source: Retrieve Document for Display: this transaction is used to request transmission of a persistent document. The Display needs to provide a unique identifier (UID) for the persistent document along with some additional parameters, such as the preferred format the document is to be provided (JPEG, CDA or PDF) and the formats which are acceptable for the response at all (JPEG, CDA, PDF or others). If successful, the Information Source returns the requested document as payload of the HTTP response. Finally, the Display renders the document in a human-readable form. Retrieve Specific Information for Display: This transaction is used to access information available on the Information Source actor that is not represented as a persistent document, because it needs to be updated rather frequently. This includes lists (list of allergies and adverse reactions for a patient, list of medications currently taken by or administered to a patient) and summaries (of reports, i.e. persistent documents). The result of the request, if successful, is returned as a XHTML web page that may contain hyperlinks, in particular to persistent documents that can be retrieved using the Retrieve Document for Display transaction. In the case of a list request, the Display provides a patient ID (which has to be known apriori or communicated by a means outside the scope of the RID profile) and the desired type of list (allergies or medications). The Information Source returns a XHTML web page as payload of the HTTP response.
988
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
In the case of a summary request, the Display also provides a patient ID. In addition it provides the type of summary requested (all reports, radiology reports, cardiology reports, etc.), the number of most recent results to be included into the response and optionally a constraint on the earliest or latest date/time of reports. Again the Information Source responds with a XHTML web page containing hyperlinks to the persistent documents referenced in the summary formulated as Web service calls to Retrieve Document for Display. The focus of the integration is visual presentation, not a complete integration of the structured databases on which the actors might be based. It is the responsibility of the Information Source to convert the healthcare specific semantics into a suitable presentation format. The Display, on the other hand, may process and render this presentation format with only generic healthcare semantics knowledge, but will in general not be able to provide any processing of the healthcare information beyond document Display. The number of commercial implementations of the RID integration profile is still limited, which is natural since the initial bfor trial implementationQ revision of the RID profile has only been published in August 2003. Nevertheless, implementations of Information Source and Display actors from several companies have already been successfully tested during IHE cross-vendor testing events in late 2003 and early 2004. This suggests that the market uptake might be rather quick. Although the RID profile is well suited for use in a single hospital or a trust of hospitals that belong to a single Patient Identifier Domain (i.e., use the same set of patient IDs), it is not designed for cross-boundary access on information stored in different hospitals infrastructure (see Fig. 1) that do not share a unified or at least compatible IT. One obvious reason for this limitation is that the Display actor needs a-priori knowledge about the patient ID of the patient to query for but many countries do not have a nationwide unique patient identification that could be used to identify a patient across hospitals. To solve the problem of cross Patient Identifier Domain access to information, for example via the Retrieve Information for Display the IHE proposes the Patient Identifier Cross-referencing Integration Profile (PIX) [1]. The PIX integration profile describes three bactorsQ, called the Patient Identity Source, the Patient Identifier Cross-reference Consumer, and the Patient Identity Cross-reference Manager. The Patient Identity Cross-reference Manager is a system that receives Patient Identity Feed messages from the Patient Identity Source actor, i.e. the Patient Identity
Fig. 1. Retrieve information for Display across Patient Identifier Domains.
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
989
Source actor sends notification messages about newly created, updated, or merged datasets about patient identifying data. Receiving such messages the Cross-reference Manager is responsible for linking together patient identifiers from those Patient Identifier Domains it manages by means of patient identifying data. The Cross-reference Consumer is a system (e.g. an Information Source) that queries the Cross-reference manager for a list of corresponding patient identifiers for a given patient ID (e.g. in a Retrieve Information for Display request) from a system that does not belong to the same Patient Identifier Domain. Although this profile is useful for managing multiple Patient Identifier Domains in a single enterprise or across cooperating enterprises it is not feasible in an international and scalable setting. The IST project ARTEMIS [2,3] addresses some of these problems. The objective of the ARTEMIS project is to develop a semantic Web services based interoperability framework for the healthcare domain. In particular, ARTEMIS aims at enabling medical practitioners to access medical information securely and seamlessly through a low-cost 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 provision of access to clinical records across enterprise and possibly even country boundaries requires a service for locating clinical records pertaining to a particular patient, and accessing the records found, under consideration of the high confidentiality constraints on patient records. Within the ARTEMIS network, clinical records can be located using the bPatient Identification ProtocolQ (PID Protocol) that has already been presented in an earlier paper [4]. The PID Protocol is a scalable cryptographic protocol that allows to identify and to locate institutes which have clinical records for a specific patient available. The protocol makes sure that the request itself cannot be interpreted by any party involved in the request, i.e. no information can be derived from the request or the responses to the request, except for a probability that requestor and provider have identifying information pertaining to the same person. Once a requestor has identified and located one or more institutes that have clinical records for a specific patient available, access to the record needs to be negotiated, given that the requestor can demonstrate the right to access the records. Thus the PID Protocol is in conformance with access authorisation and privacy regulations required e.g. by [5–9]. 3. Results Applied to the ARTEMIS infrastructure, the RID Information Source and Display actors may be located in different institutions using different Patient ID domains and different sets of demographic data. From the perspective of an enterprise that wants to connect an existing Information Source to the ARTEMIS network, i.e. provide clinical documents to requestors in the ARTEMIS network, the connection seems to be straightforward at first, given that IT security and access rights are provided: a Web service that implements the RID protocol may be provided through the ARTEMIS peer and registered at the mediator. From the perspective of an enterprise that wants to connect a Display actor to the ARTEMIS network, i.e. retrieve clinical documents over the
990
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
ARTEMIS network the issue seems more complex, because in this case neither the location of all Information Source actors is known a priori (due to the dynamic nature of the peer to peer network), nor are the remote Patient IDs known that are needed to retrieve lists of documents or clinical information from each Information Source. This is the point where the PID Protocol comes into play. The result of a query that is processed by the PID Protocol is a possibly large set of pairs of URIs and candidate identifiers and each of these pairs represents a peer that possibly provides information about the desired patient. Candidate identifiers are related to a single patient in the context of a single PID transaction and do not provide any semantic meaning to the requestor, i.e. a requestor cannot get any information about a patient from a candidate identifier directly. Since the PID Protocol provides candidate IDs which are not identical to local patient IDs, mainly because of data protection considerations, but the RID protocol is based on patient IDs, a mapping of the IDs must take place at the site that has generated the candidate IDs. Some simple components are needed to achieve those mappings and routing of requests and responses through the ARTEMIS network. Fig. 2 shows a simplified schema of those components necessary to combine an existing RID information source at the record repository site and an existing RID display system at the requestor site with an additional middleware layer to provide medical record access in combination with the PID protocol. On the repository site, a bsimulated displayQ receives the incoming requests from the requestor, replaces the candidate ID generated during the patient identi?cation process by the real patient ID locally used in the hospital and forwards the request to the existing information source, to which this actor looks like any local display actor. Before forwarding the response back to the requestor, all hyperlinks in the response have to be replaced with links pointing to the simulated display, because these hyperlinks will typically refer to resources that typically cannot be reached directly from outside the local network. Subsequent requests for these mapped hyperlinks would simply be redirected from the simulated display to the original resource. In a similar manner, a hyperlink lookup scheme can be implemented on the requestor site inside the bsimulated information source. As a side effect, the two bsimulatedQ actors can provide a secure tunnelling of the request and response message, which are usually transmitted in clear text form within a hospital, using any available transport level security protocol. A
Fig. 2. Retrieve information for Display integration into ARTEMIS.
T. Aden, M. Eichelberg / International Congress Series 1281 (2005) 986–991
991
detailed analysis about the protocol and combination of the PID protocol with the IHE RID profile can be found in [10]. 4. Conclusion The middleware infrastructure developed in the ARTEMIS project allows to extend the IHE RID protocol for cross-enterprise search, and access to patient-related clinical information, even if no Master Patient Index is available, and without modifications to existing Information Source actors (document repositories). The cryptographic protocol Patient Identification Protocol can also be combined with the IHE Cross-enterprise Document Sharing (XDS) Integration Profile [11], a new IHE work that also addresses the domain of exchange of clinical documents beyond enterprise boundaries. Acknowledgements The ARTEMIS project has received research funding from the EC’s Sixth Framework Programme (project IST-2103 STP under the eHealth Action Line of the Information Society Technologies Programme). References [1] HIMSS, RSNA, Integrating the Healthcare Enterprise (IHE)-IT Infrastructure Technical Framework Revision 1.1, http://www.rsna.org/IHE/tf/ihe_iti_tf_1.1_vol1_FT.pdf, http://www.rsna.org/IHE/tf/ihe_ iti_tf_1.1_vol2_FT.pdf (23 Feb. 2005). [2] A. Dogac, et al., Artemis: Deploying Semantically Enriched Web Services in the Healthcare Domain, Information Systems Journal special issue on Semantic Web and Web Services, Elsevier, in press. [3] Artemis Project, http://www.srdc.metu.edu.tr/webpage/projects/ (23 Feb. 2005). [4] T. Aden, M. Eichelberg, W. Thoben, A fault-tolerant cryptographic protocol for patient record requests, in: P. Inchingolo, P. Mucelli (Eds.), Proceedings of EuroPACS-MIR 2004 in the Enlarged Europe; 2004 Sept. 16–18, E.U.T. Edizioni Universita` di Trieste, Trieste (Italy), 2004, pp. 103 – 104. [5] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, OJ L, 23 Nov. 1995, http://europa.eu.int/com-m/internal_market/privacy/law_en.htm (23 Feb. 2005). [6] Council of Europe, European Convention for the Protection of Human Rights and Fundamental Freedoms, 4 November 1950 http://conventions.coe.int/Treaty/en/Treaties/Html/005.htm (23 Feb. 2005). [7] Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002, concerning the processing of personal data and the protection of privacy in the electronic communications sector, OJ L 201/37, 31 July 2002, http://europa.eu.int/information_society/topics/ecomm/useful_information/library/ legislation/index_en.htm (23 Feb. 2005). [8] Council Of Europe-Committee of Ministers, Recommendation No. R(97)5 of The Committee Of Ministers to Member States on the Protection Of Medical Data, Council of Europe Publishing, Strasbourg, 12 February 1997. [9] ISO/TC 215-International Organization for Standardization, ISO/DIS 22857 (Draft International Standard): Health Informatics—Guidelines on data protection to facilitate trans-border flows of personal health information, 2003. [10] T. Aden, M. Eichelberg, J. Riesmeier, Relevant Electronic Healthcare Record Standards and Protocols for Accessing Medical Information (ARTEMIS Deliverable D5.1.1), ARTEMIS Consortium, Oldenburg, Germany, 2004. [11] IHE IT Infrastructure Technical Framework, Supplement 2004–2005, Cross-Enterprise Document Sharing (XDS), Trial Implementation Version, http://www.rsna.org/IHE/tf/IHE_ITI_Cross-enterprise_Doc_Sharing_ 2004_08-15.pdf (23 Feb. 2004).