 |
|||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||
Project Participants:
Total Cost( € ): 2.957.604 € Commission Funding( € ): 1.989.000 € Key issues: eHealth, Interoperability of Medical Information Systems, Web services for the medical domain, Semantically enriched Web services for the healthcare, Web Service registries, Semantic mediation of Healthcare ontologies, P2P Technologies for the discovery of healthcare services. ARTEMIS Project's Main Achievements: One
of the key problems in healthcare informatics is the inability to share patient
records across enterprises. There are several standardization efforts to
digitally represent clinical data such as HL7 CDA, EHRcom
and openEHR. These EHR standards, which are currently
under development, aim to structure and markup the clinical content for the
purpose of exchange. All of the EHR standards are based on reference
information models. Although the reference information models represent the
same information, they have different structure and content. Furthermore, since
there are very many clinical concepts in the healthcare domain, specific
clinical concepts such as blood pressure, or ECG measurements, are defined as
constraint rules, called as “archetypes" rather than distinct entities in
the reference information model. The HL7 Clinical Document Architecture (CDA) is a
document markup standard. It specifies the structure and semantics of
"clinical documents" for the purpose of exchange. CDA documents are
encoded in Extensible Markup Language (XML) and derive their meaning from the
HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types. Document-level,
section-level and entry level templates can be used to constrain the generic
CDA specification. EN 13606 (EHRcom) is a
five-part standard consisting of the Reference Model, Archetype Interchange
Specification, Reference Archetypes and Term Lists, Security Features and
Exchange Models. Currently, however, only the reference model (EN 13606-1) is
stable, whereas parts 2 - 5 are still working drafts. The EHRcom
reference model consists of four packages (Extract, Demographics, Access
Control and Message) which together describe the aspects of an EHR that are
relevant for communication of EHR extracts between information systems. The Extract package defines the root class of
the reference model ("EHR_EXTRACT") and the data structures for EHR
content. The Demographics package
provides a minimal data set to define the various persons, software agents, devices
and organisations that are referenced within the EHR
extract. However since there are more than one standard, it is
still difficult to achieve interoperability and today the clinical data is
mostly stored in proprietary formats. To address this document sharing problem
in the healthcare domain in a practical manner, an industry initiative called
“Integrating the Healthcare Enterprise" (IHE) specified the “Cross
Enterprise Document Sharing (XDS)" Profile. The basic idea of IHE XDS is
to store healthcare documents in an ebXML
registry/repository architecture to facilitate their sharing. IHE XDS is not
concerned with document content; it only specifies metadata to facilitate the
discovery of documents. Artemis project provides the interoperability of medical
information systems through semantically enriched Web services. The Artemis
project’s achievements to date are as follows: ·
An essential element
in defining the semantic of Web services is the domain knowledge. Medical
informatics is one of the few domains to have considerable domain knowledge
exposed through standards as mentioned above. These standards offer significant
value in terms of expressing the semantic of Web services in the healthcare
domain. In Artemis project, prominent healthcare standards are used to
semantically annotate Web services as follows: o
HL7 has categorized
the events in healthcare domain by considering service functionality which
reflects the business logic in this domain. We use this classification as a
basis for defining the service action semantics through a “Service
Functionality Ontology”. In this way, semantic discovery of Web services are
facilitated. o
Given the complexity
of clinical domain, the Web service messages exchanged have innumerous segments
of different types and optionality. To make any use
of these messages at the receiving end, their semantics must be clearly
defined. We annotate the Web services through the reference information models
of Electronic Healthcare Record (EHR) standards. However, the reference information
models of EHRs contain generic classes rather than
having a class for each specialized clinical concept. Therefore, given a class
in source ontology, the corresponding class in the target ontology is not clear
unless the context is known. Also different reference information models
structure their classes differently. Therefore, we annotate the Web service
messages with the OWL representation of the archetypes. Then by providing the
ontology mapping between the archetypes, we show that the interoperability of
the Web service message instances can be achieved automatically. Note that
clinical concepts are defined as constraint rules, called as “archetypes"
rather than distinct entities in the reference information model. o
The details of this
work is presented in the following publications: §
Dogac, A., Laleci, G., Kirbas S., Kabak Y., Sinir S., Yildiz A., Gurcan Y. “Artemis:
Deploying Semantically Enriched Web Services in the Healthcare Domain",
Information Systems Journal (Elsevier), accepted for publication. (Science Citation Index Core, Impact Factor: 03.327) § Bicer, V., Laleci, G., Dogac, A., Kabak, Y., “Providing
Semantic Interoperability in the Healthcare Domain through Ontology Mapping”,
eChallenges 2005, § Bicer, V., Kilic, O., Dogac, A., Laleci, G., “Archetype-based Semantic Interoperability of Web Service Messages in the Healthcare Domain”, Int'l Journal on Semantic Web & Information Systems, Vol. 1, No.4, October 2005, pp. 1-22. o
The code is
available upon request. ·
Using archetypes is
a promising approach in providing semantic interoperability among healthcare
systems. To realize archetype based interoperability, the healthcare systems
need to discover the existing archetypes based on their semantics; annotate
their archetypes with ontologies; compose templates
from archetypes and retrieve corresponding data from the underlying medical
information systems. In Artemis project, we use ebXML
Registry semantic constructs for annotating, storing, discovering and
retrieving archetypes. o
The details of this
work is presented in the following publication: §
Dogac, A., Laleci, G., Kabak, Y., Unal, S., Beale, T.,
Heard, S., Elkin, P., Najmi, F., Mattocks, C.,
Webber, D., "Exploiting
ebXML Registry Semantic Constructs for Handling
Archetype Metadata in Healthcare Informatics", accepted for
publication, International Journal of Metadata, Semantics and Ontologies. §
The code is
available upon request. ·
In the Artemis
project, AMEF (Artemis Message Exchange Framework) is developed to provide the
exchange of meaningful clinical information among healthcare institutes through
semantic mediation. The framework involves first providing the mapping of
source ontology into target message ontology with the help of a mapping tool
which produces a mapping definition. This mapping definition is then used to
automatically transform the source ontology message instances into target
message instances. Through a prototype implementation, we demonstrate how to
mediate between HL7 Version 2 and HL7 Version 3 messages. However, the
framework proposed is generic enough to mediate between any incompatible
healthcare standards that are currently in use. The semantic mediation
between HL7 Version 2 and HL7 Version 3 messages in AMEF Framework is realized
in two phases: ·
Message Ontology Mapping Process: In the first phase, the message ontologies
of two healthcare institutes are mapped one another. Assume that healthcare
institute A is HL7 Version 2 compliant and healthcare institute B is HL7
Version 3 compliant. The message ontologies of these
institutes are mapped one into other by using an ontology mapping tool. For
this purpose we have developed an OWL ontology mapping tool, namely, OWLmt. With the help of a GUI, OWLmt
allows defining semantic mappings between structurally different but
semantically overlapping OWL ontologies, and produces
a “Mapping Definition". Since message ontologies
for HL7 messages do not exist yet, we use the HL7 Version 2 and Version 3 XML
Schemas (XSDs) to generate OWL ontologies.
This process, called “Conceptual Normalization" [6] produces a
“Normalization map" describing how a specific message XSD is transformed
into the corresponding OWL schema. Note that Version 3 message schemas are
generated through HL7 Hierarchical Message Defnition
(HMD) process. The “Mapping Definitions" and the “Normalization map"
produced in the first phase are used during the second phase to automatically
transform the message instances one into another. ·
Message Instance Mapping: In the second phase, first the XML message instances of
healthcare institute A are transformed into OWL
instances by using the “Data Normalization" engine. Note that if the
message is in EDI format, it is first converted to XML. Then by using the “Mapping
definition"s, OWLsource
(healthcare institute A) messages instances are transformed into the OWL target
(healthcare institute B) message instances. Finally the OWL messages are
converted to XML again through the “Data Normalization" engine. o
The details of this
work is presented in the following publication: ·
Bicer, V., Laleci, G., Dogac, A., Kabak, Y., “Artemis
Message Exchange Framework: Semantic Interoperability of Exchanged Messages in
the Healthcare Domain” ACM Sigmod Record, Vol.
34, No. 2, June 2005 (Science Citation
Index Expanded, Impact Factor:
00.675) ·
The code is
available upon request. ·
One crucial aspect
in ARTEMIS is to find and retrieve clinical information about a particular
patient from different healthcare organizations where concrete sources are
unknown. To complicate matters, in most countries there are no unique person
identifiers that would be valid for the whole lifetime of an individual and
used by all parties in healthcare and for all episodes of care. On the
contrary, in many cases several identifiers for a patient do exist even within
a single organization. Consequently a protocol is needed that allows for the
identification of patients by means of non-unique patient-related attributes. Different solutions are conceivable
and one might follow the Integrating the Healthcare Enterprise (IHE)
Integration Profile named ‘Patient Identifier Cross-referencing’ (PIX). The PIX
profile is intended to be used at healthcare enterprises of a broad range of
sizes. The PIX profile proposes a global repository (“cross-reference manager”)
that holds plain-text information about patients provided from connected
systems in different patient ID domains. Systems can report and request patient
identifiers via Health Level Seven (HL7) messages. Whereas this model is
suitable for scenarios wherein all parties know and trust each other, it is not
applicable within the ARTEMIS context for data privacy and data security
reasons. The ‘Patient Identification
Process Protocol (PIP)’, being developed within the scope of Artemis project is
based on a method used in the Cancer Registry of Lower Saxony. PIP provides a solution for a common problem
in the healthcare sector that is likely to become very important with the
increasing mobility of the workforce in o
The details of this work
are presented in the following publications: §
Marco Eichelberg, Thomas Aden, Wilfried
Thoben, “A
Distributed Patient Identification Protocol based on Control Numbers with
Semantic Annotation”, submitted for Publication to IJSWIS. §
Thomas Aden, Marco Eichelberg, Wilfried Thoben, “A
fault-tolerant cryptographic protocol for patient record requests” to
appear in the Proceedings of EuroPACS-MIR 2004 in the
enlarged Europe, o
The details of this
work are presented in the following Artemis deliverables: §
Artemis Deliverable 5.1.1 “Relevant
EHR Standards and protocols for accessing Medical Information” §
Artemis Deliverable
5.2.1 "Implementing
access to EHR in terms of Web services"
which will be available at the end of project month 18. ·
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. There are many
such regulations at European level and additional legislation implemented
within member states. According to EU Directive 95/46/EC, if a healthcare
provider maintains personal data on its patients the healthcare provider is
identified as a data controller and is responsible for protecting that data against
unauthorised use. Typically, a healthcare provider
implements the legislation by authoring a security policy that mandates working
practices and security technology requirements (key sizes, algorithms). If a
healthcare provider wants to access personal data within another organisation they are identified as a data processor. For
the communication to occur between data controller and data processor consent
must be obtained from the patient and a contract between the two parties must
exist that defines conditions such as the type of data processing and how long
the data can be stored by the data processor. After the out-of-bound
legislative conditions for data processing have been 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 information systems. 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. Hence a core requirement in ARTEMIS is for very robust,
but highly flexible approach to security and privacy. In ARTEMIS architecture, an approach has been developed for
mediating between security and privacy policies using a combination of industry
supported web service standards and reasoning over semantics web service
descriptions. The approach supported by ARTEMIS allows healthcare providers
to codify their particular preferences and requirements for data security
(confidentiality, integrity) and privacy (authorisation
and anonymisation) in accordance with overarching organisational security policies. Based on these, Artemis
enables the communication of medical data across healthcare provider boundaries
through mediation between semantic security and privacy policies on the
condition that out-of-band contracts and patient consent has been agreed. The
initial authorisation infrastructure allows access
control based on mediation between clinical roles defined by different organisations. o
The details of
Artemis Security and Privacy architecture is available in the Artemis
publication §
Mike Boniface, Paul Wilken, “ARTEMIS:
Towards a Secure Interoperability Infrastructure for Healthcare Information
Systems”, accepted to Healthgrid2005 o
The details of this
work will be presented in: §
Artemis Deliverable 4.4.1
“Security and Privacy mechanisms for Web services”. §
The Integrating the
Healthcare Enterprise (IHE) initiative proposes the Retrieve Information for
Display (RID) integration profile that enables a user to retrieve and display
patient related documents on systems other than the document keeping systems.
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, it is not designed
for cross-boundary access on information stored in different hospitals
infrastructure that do not share a
unified or at least compatible IT. 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. 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. Within the ARTEMIS network, clinical
records can be located using the “Patient Identification Protocol” (PID
Protocol) which can also be combined with the IHE Cross-enterprise Document
Sharing (XDS) Integration Profile. o
The details of the
RID Artemis integration is presented in the following publication: §
Thomas Aden, Marco Eichelberg,
“Cross-enterprise
search and access to clinical information based on IHE Retrieve Information for
Display”, accepted to EuroPACS-MIR 2005. o
This work is
progressing within the scope of WP5 and the results will be publicly available
in: §
Artemis Deliverable
5.2.1 "Implementing
access to EHR in terms of Web services"
at the end of project month 18. ·
ARTEMIS first integrated
prototype is completed successfully. This prototype is demonstrated in the following
conferences and exhibitions:
Detailed
information on the demo can be found in the following document: ·
One of the main objectives
of the project is to develop the infrastructure necessary to make medical
information systems interoperable based on the Web services. For this purpose
the end users of the Artemis project developed Web services for exposing their
existing healthcare applications and patient data. These Web services are integrated
to the ARTEMIS first prototype. The services are as follows:
In the current version, the AdmitPatient Web Service and
PushLabResults Web Services are embedded to the Corttex application. In other
words, these Web Services access to the actual resources that Corttex
application uses, hence, invocation of these Web Services results in real life
activities. The rest of the Web Services are simulations.
The “Find Patient” and “Retrieve Diagnosis Information”
Web services are integrated to the ARTEMIS first prototype. Coordinator contact details: Prof. Dr. Asuman Dogac |
|||||||||||||||||||||||||||||||||||||||||||||||
