|
HL7 Patient Record Architecture update | Table of contents | Indexes | XML data warehousing for browser-based Electronic Health Records | |
|||
SynExML as a vehicle for Electronic Patient Records |
| A status report from the SynEx project |
 Jung, Benjamin  |
| Benjamin Jung |
| Research Assistant |
| Dublin Ireland Trinity College Dublin | Trinity College Dublin,
Centre for Health Informatics Dept. of Computer Science Dublin 2 Ireland Phone: +353 (1) 608 1335 Fax: +353 (1) 677 2204 email: benjamin.jung@cs.tcd.ie web site: www.cs.tcd.ie/CHI/ |
| Biography |
| Andersen, Egil P. |
| Egil P. Andersen |
| Senior Research Scientist |
| Norway Norwegian Computing Center Oslo | Norwegian Computing Center,
P.O.Box 114 Blindern Oslo 0314 Norway Phone: +47 (22) 85 25 94 Fax: +47 (22) 69 76 60 email: Egil.Andersen@nr.no web site: www.nr.no/ |
| Biography |
| Grimson, Jane |
| Jane Grimson |
| Associate Professor |
| Dublin Ireland Trinity College Dublin | Trinity College Dublin,
Centre for Health Informatics Dept. of Computer Science Dublin 2 Ireland Phone: +353 (1) 608 1780 Fax: +353 (1) 677 2204 email: jane.grimson@cs.tcd.ie web site: www.cs.tcd.ie/CHI/ |
| Biography |
| Abstract |
| EU, European Union Handheld Device Patient Record SynEx SynOD SynOM Synapses | The advent of shared care coupled with the proliferation of heterogeneous distributed systems containing patient data have resulted in an urgent need to provide seamless integration of distributed electronic patient records. This paper presents the approach to this problem, which is being developed as part of a majorEU Health Telematics project, SynEx. The approach is based on a coreXML DTD corresponding to a flexible common model of the shared - or federated - Electronic Healthcare Record. Using this DTD, SynEx has successfully demonstrated the exchange of records between two heterogeneous and geographically separated sites. |
| DTD, Document Type Definition XML | Introduction and motivation |
| CEN/TC251, Comité Européen de Normalisation Technical Committee 251 | The management of electronic patient data was relatively easy as long as the data was collected, stored and viewed in a closed environment like a single hospital/department or doctor's practice. A single vendor provided compatible systems and a centralised system administrator was responsible for the smooth running of all installed components. No 'digital' connection to the 'outside world' was provided which avoided many of the problems associated with "open" systems, in particular safeguarding the security and confidentiality of patient data. With the use of hospital-specific information system, that are well known by the staff, maintenance and use became very easy and people felt familiar with it. On the other side, complexity increased with each new version and/or change to a different product. Data exchange with external organisations was only possible by paper, mail, fax or telephone, which is clearly both time-consuming and error-prone. Any feedback and results had to be manually entered and often even cross-checked. This approach is no longer sufficient. Increased computerisation throughout the health sector has given rise to a proliferation of independent systems storing and maintaining patient data. However, the growing trend towards shared care requires that these systems are able to share their data. This has led to the development of projects such as Synapses and its successor, SynEx that aim to provide healthcare professionals with integrated access to patient records and related data. One of the goals of SynEx is to bring together the work on Federated Healthcare Records from the Good European Health Record project , emerging standards fromCEN/TC251 and the Synapses project with the Information Systems perspective of middleware based pre-standardHISA . The Synapses project exploited ideas from federated database technology that provide client applications with an integrated view of data stored in heterogeneous, distributed database systems. At the heart of Synapses is theFHCR server that accepts requests for data (in the form of clinical objects) from clients, decomposes them into queries against the connected "feeder" systems, where the data is actually stored, and integrates the responses dynamically. Synapses was concerned with the specification of an open standard for the server and its interfaces and for pragmatic reasons used an ad hoc mechanism for exchanging clinical data between feeders, server and client. Obviously, a candidate for such an exchange format would be based onXML and this is being actively pursued in the SynEx project. This paper assesses howXML could be usefully incorporated into both Synapses and SynEx. |
| DTD, Document Type Definition FHCR, Federated Health Care Record HISA, Health Information Systems Architecture SynExML XML | XML has the power to become the independent data exchange format of the future. The use ofXML to exchange data between heterogeneous hard- as well as software-systems provides support for hierarchical structured patient data, user defined tags and machine-understandable assertions for searching, reasoning and analysingFHCR objects. This paper presents the Synapses approach toFHCR s and explains how the common model of theFHCR developed in Synapses has been used as the basis for the coreXML DTD in SynEx (SynExML ). A demonstration of the integration of records and exchange of information between two sites is described and the paper concludes with a brief review of the future direction of this research. It furthermore outlines some ideas on how the use ofXML as the basic data-structure can help integrating hardware-devices, such as handheld-devices and mobile phones, into the internal and external patient care environment. |
| XML | The Synapses approach |
| HL7, Health Level 7 | In contrast to the very detailed and highly specific record architectures of for exampleHL7 , the SynOM is a generic and flexible common object model. It extends the model of theEPR described in ENV12265 from CEN/TC251, . Experiences from ongoing work and implementations were fed back into the development of ENV12265's successors ENV13606/1-4 . |
| EPR, Electronic Patient Record RIC | The Synapses Record Architecture consists of a single class hierarchy, and every Synapses patient record consists of a set of objects where each object is instantiated from a class in this hierarchy. Each class in the hierarchy belongs to one of two main groups of classes. The structure of a record is made up of objects instantiated from thestructural classes , calledRIC , while the data (information) within a record consists of objects instantiated fromdata value classes , calledRI . |
| RI RIC URI | The structure of a Synapses record corresponds to a tree structure ofRIC objects, and each record can have unidirectional links to other such tree structures, i.e. to other Synapses records. The tree structure of each record is rooted in a singleRecordFolder object, instantiated from the classRecordFolder , which represents the overall record. Below this object there will be a structure of folders (FolderRIC objects) and documents (ComRIC objects). Each document will itself consist of a tree structure of objects, which can beDataRIC objects and/orViewRIC1 objects. The former contains information that is explicitly stored in the record, while the latter is used to represent computed or derived information. In addition there are objects that represent links to other Synapses records, calledViewRIC2 objects. These are the keys to the integration of Synapses records. They contain the unique identification of anotherRIC object, and they are used as follows. The root object of a record, or a folder within a record, may contain a singleViewRIC2 object that references another record or folder object respectively. In addition, a document may contain one or moreViewRIC2 objects that each reference some subset of other documents. TheRIC object referenced by aViewRIC2 object is either local, intra- or inter-record, or remote. If remote then theViewRIC2 object contains anURI that identifies the server where the target RIC object resides. |
| RI RIC | EachRIC object instantiated from one of the "structural classes" will have a small set of static, predefined attributes, e.g. as required for their unique identification, or the target address of aViewRIC2 object. However, most of the information content of a record, and all the medical information, exists inRI objects instantiated from the "data value classes". That is, a set ofRI objects can be attached to a structuralRIC object and thus function as its dynamic attributes with actual data values such as a blood pressure measurement. TheRI objects that belong to a particularRIC object can also be organized into a tree structure. This allows the information content of a record to be dynamically extended, including new information types that may not have been foreseen at the time the record itself was created. |
| RI RIC | The distinction betweenRIC classes andRI classes comprises of "vertical" grouping of the overall Synapses class hierarchy. In addition the class hierarchy is split "horizontally" into a predefined set of base classes common to every Synapses server, called the SynOM, and an extendable set of classes that are derived from these SynOM classes, called the SynOD. The aboveRIC classesRecordFolder ,FolderRIC ,ComRIC , etc, all belong to the SynOM, and they define the core part of Synapses' generic record model. The SynOD classes on the other hand are site specific and thus may differ for each Synapses server, are the classes from which the actual patient record objects are instantiated. Thus while every record object has the above SynOM characteristics and properties, they can also be customised to the needs of each individual site. |
| RSB | Supporting software tools will guide and help the user in the process of creating SynODs and linking the Synapses Server with the different feeder systems. One candidate for such a tool is theRSB , that was developed by the Dublin group. It's functionality includes aGUI to the SynOD, context sensitive management ofRIC s and RIs, and localisation of Synapses concepts into site-specific clinical concepts for even easier maintenance. |
| GUI, Graphical User Interface RIC | SynExML - the story so far |
| DTD, Document Type Definition FHCR, Federated Health Care Record XML | There are several advantages over existing formats to the use ofXML to support the exchange of structured patient data between diverse sites.XML provides a hardware- and a software- independent specification. Furthermore, both the Synapses basedFHCR model andXML are hierarchical/oject-oriented data structures with the option to link their elements. It was assumed that a straightforward transformation from SynOM into anXML DTD would not cause any problems. This proved to be somewhat optimistic asXML is based on a very flexible specification and allows 'colourful' variations. |
| XML |
|
| DTD, Document Type Definition FHCR, Federated Health Care Record XML | The advent ofXML presented a new solution to achieving an agreed common model for the exchange of SynapsesFHCR s. Not only did it provide a structure to define the model (DTD ), but it also showed a first possible use and implementation (instantiation of anXML document). It was decided to investigate the use of theXML DTD as another modelling tool. Hopes in the new technology were high and local variations were accommodated by the optional introduction of site-specific extensions to theDTD . Unfortunately, this rapidly led to a situation in which these local extensions exceeded the commonly agreed core part of theDTD by a factor of four. It quickly became clear thatXML had not eased the problems associated with data exchange as had been hoped. Following a review, it was agreed to eliminate virtually all these locally proposed extensions and to concentrate on the common core, on which consensus was achieved. Unfortunately, there is no common methodology or standard that could be used as a guideline for this conversion. Due to the flexible nature ofXML , many different (legal and acceptable) conversions are possible. The project decided to use basicDTD modelling as the only method, as this is (at the moment) less limiting and a clean procedure. |
| CGI, Common Gateway Interface XML | The second main goal for the introduction ofXML as the exchange format was to facilitate extensions to existing systems. The integration of additional interfaces is relatively easy and quick to realise as the SynOM is already hierarchically organised and internally represented in object-oriented data structures. The transmission of structure and data within a single document, even a human readable one, is an advantage. Furthermore the Internet was the obvious choice for the basic transport mechanism as infrastructure and transport protocols are already in place. The connection to the Internet via web-server and scripting technologies (e.g.CGI ,ASP ,JSP ) can be quickly achieved. |
| ASP, Active Server Pages JSP XML XSL | Last but not least, the separation of content (XML ) and associated rules how to present the content on the client side (using e.g.XSL ) made the effort of developingSynExML in the SynEx project a success. Each of the SynEx data providers delivers a stylesheet, which describes how to present their data on the client side with the option of locally selecting another (preferred and/or personalised) view. Recent work has been undertaken not only to create stylesheets for localisation purposes but also to disseminate content more flexible to additional hardware, such asHHD ,PD and mobile phones ( ). A whole range of new the medical personnel supporting applications is envisaged. shows the three axis of theXML triangle and their relation to each other.XSL (with it's subsections ofXSLT ,FO and Xpath) is the perfect candidate to provide intra-axis mapping (e.g. betweenHL7 and SynExML) and inter-axis mapping (e.g. between proprietary/limited sets of HTML implementations). This can be achieved on the server as well as on the client side (see ). |
| FO, Formatting Objects HHD, Hand Held Devices HL7, Health Level 7 PD SynExML XML XSL XSLT |
|
| XML XSL | This diagram shows the three different ways in whichXML documents are processed with the correspondingXSL stylesheets. This can occur on the server as well as on the client side : |
| DTD, Document Type Definition SynExML | TheSynExML
DTD
(version 2.2) is publicly available and already implemented and used in prototype environments to exchange and link FHCRs between Synapses Servers in Dublin and Oslo. Demonstrations can be viewed at the following sites: |
Record integration and information exchange |
| DTD, Document Type Definition SynExML XML | Synapses servers do not rely on a central catalogue service for retrieving information on where the various parts of a particular patient record reside. Instead, as explained above, this information is distributed such that every record on a particular server has the information required to access other parts of it that reside in other servers. Thus after having agreed on theSynExML DTD as the commonXML format for the information exchange, the hyperlink capabilities of Synapses in combination with state-of-the-art web technology makes it fairly straightforward to achieve seamless integration of distributed patient records. |
| RH | For example, consider a user that connects to a SynEx compliant site such asRH in Oslo, the national hospital of Norway. The user's access rights are collected and stored from an initial login operation. After the successful login, the user chooses what he wants to browse from a set of available records and record fragments. Parts of a particular selected record may reside at other sites such asSJH in Dublin. When presenting the user with information from this record, the fact that the information content is distributed should be transparent to the user. If a document fromRH is requested it will be retrieved from the current server, while if a document fromSJH is requested then the client will forward the request toSJH transparently to the user and retrieve the requested document from there. The information to forward the request is entered at the first request of data fromSJH and will be stored atRH whereas the data itself resides atSJH . Of course, using this technique might lead to multiple levels of redirection, but it ensures a consistent storage of data at exactly one place. |
| RH SJH |
|
| CORBA, Common Object Request Broker Architecture MTS XML | An important characteristic of this integration scenario is it's client-side processing, where the requests were made. Naturally, this implies that the client application supports functionalities likeXML parsing and XSL processing. Without this support, server-side processing is required, which limits the flexibility on the client but broadens the support of components in relation to hard- and software. The server's only responsibility is to maintain valid links to where remote parts of its records reside. Furthermore, the implementation of a particular Synapses server, and its legacy feeder systems, is irrelevant to the integration. For example, the Dublin Synapses server is based on a C++/CORBA environment connecting to various data sources via a generic database interface (Generic Adapter), while the Oslo Synapses server usesMTS withCOM components as the application layer, andSQL Server for the data store. Thus a first attempt has been made to standardise the web server interfaces. This will be an important issue for the upcoming developing phase to complete the automatic data exchange.Request as well asException ELEMENTs will be added to the next version of the SynExML. The Dublin web server interface is based on C++CGI scripts, while the Oslo web server uses ASP; this is just a matter of implementation, both are equally suitable and could easily be exchanged or even replaced by a third one. Even the insertion of a native http-interface to the existing server to speed up the data retrieval process will be part of the future research activities.ASP s in Oslo implemented in a manner that corresponds technically with the new MicrosoftSOAP , where requests to the server are themselves formatted inXML ; i.e.XML sent to the server specifies a sequence of functions and their parameters. After parsing the receivedXML the server executes the specified functions and returns the resulting XML to the client. |
| ASP, Active Server Pages CGI, Common Gateway Interface COM, Component Object Model SOAP SQL XML |
|
| COM, Component Object Model CORBA, Common Object Request Broker Architecture XML | A great benefit of basing the information exchange onXML is that it makes the technology offering this information transparent to the task of achieving seamless integration. It would have been much more cumbersome and time-consuming to achieve record integration based on a common protocol, e.g. (D)COM orCORBA components. |
| DTD, Document Type Definition FHCR, Federated Health Care Record XML XSL | As a first step in the process of transparently exchangingFHCR s, all parties in the SynEx consortium agreed to provide the functionality to process and display patient records that are marked up according to the SynExMLDTD . As far as the local institution doesn't already use SynExML, it requires a single mapping to and from their local schema into SynExML . For further demonstration of the Synapses concept, the Dublin group developed a prototype of a Generic Client ( ), based on MS Internet Explorer 5 and support forXML /XSL , that displays the medical data in various (but predefined) structures, depending on their Synapses concept. This ensures the presentation of remote data in (at least) one way and provides methods to override the predefined stylesheet with local enhancements. |
Summary and conclusions |
| DTD, Document Type Definition FHCR, Federated Health Care Record HTTP, Hypertext Transfer Protocol SynExML XML XSL | In summary, the development of theSynExML DTD and its possible future use have brought the objective of seamless integration of patient information closer than it was originally envisaged. It even provoked and pushed the idea in the Dublin group to transmit Patient Records to a number of different Hardware platforms (e.g. Handheld/Palmtop-devices, mobile phones) using various transport mechanisms and standards. Agreement on a common syntax for theFHCR and exchange mechanisms and the foreseeable progress in the development of web-based APIs as well as the flexible conversion ofXML documents into various formats usingXSL made it work. However, the use ofXML documents following theSynExML specification, together withHTTP support and a hardware- and software-independent data format do not by themselves provide a flexible exchange of patient records. More research has to be undertaken in the following three major areas before real, automated integration of patient information can take place: |
| CEN DTD, Document Type Definition EPR, Electronic Patient Record FO, Formatting Objects HL7, Health Level 7 SVG SynExML VML XML XSLT | Acknowledgements |
| DTD, Document Type Definition | The authors would like to thank the members of the SynEx consortium, especially the SynExML working group within the Technical Committee. Without their help, patience and cooperation in achieving a commonDTD for expressing the Synapses concepts, this document would never have been published. We hope the SynExML will be one future format for inter-institutional exchange of medical data and contribute to promote the use of standards in Healthcare. |
| Bibliography |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HL7 Patient Record Architecture update | Table of contents | Indexes | XML data warehousing for browser-based Electronic Health Records | | |||
