WO2001006348A1

WO2001006348A1 - Processing medical data in different formats

Info

Publication number: WO2001006348A1
Application number: PCT/US2000/017549
Authority: WO
Inventors: Alfredo Morales; Ravi Venkatraman; Qiang Wang
Original assignee: Clinician Support Technology
Priority date: 1999-07-19
Filing date: 2000-06-26
Publication date: 2001-01-25
Also published as: AU5638900A

Abstract

A method that includes receiving data sets (40) that represent physical information associated with medical patients, forming mark-up language documents that include information corresponding to the data sets and additional information useful in processing the data sets (40), and storing the mark-up language documents.

Description

PROCESSING MEDICAL DATA IN DIFFERENT FORMATS

This application claims priority from United States Provisional Patent Application Serial Number 60/144,471, filed on July 19, 1999, incorporated by reference. This invention relates to processing medical device data.

The data generated by a medical device, such as an EKG machine, is typically stored in a proprietary format and used only within the proprietary system that generates the data. For example, the EKG data could be used by a printer that is able to process the proprietary format in which the EKG machine encoded it. In addition, the data typically cannot easily be integrated with proprietary-format data from medical devices of other manufacturers or with medical data from other sources.

Integrating medical data from a range of sources can improve the quality and consistency of information that is made available at points of care across integrated healthcare delivery systems. Virtual multimedia patient records (a variant on more conventional electronic medical records or EMRs) enable medical data from diverse sources to be presented as an integrated whole to healthcare providers.

The invention provides an efficient, cost-effective way to process medical device data so that it can be delivered, exchanged, archived and made available for use as part of healthcare information systems. An Internet-based, extensible open middleware architecture enables enterprise-level management and presentation of medical device outputs (MDOs).

The architecture uses distributed application servers. Each application server has one or more discrete software components that perform specific functions associated with transfer, storage, indexing, retrieval and presentation of MDOs across a distributed computing environment.

Within the computing environment, a MDO is expressed in a compressed Unicode format that is made part of an XML document. The XML document also contains descriptive information or attributes of the MDO.

The XML documents can be easily exchanged among disparate systems within an enterprise, enabling the integration of MDOs with EMRs, virtual multimedia patient records, and other clinical repositories. Each application server can be configured to perform one or more or all of the tasks. If the tasks are distributed among several application servers, communication and exchange among the servers relies on standardized transactions expressed as XML documents using a loosely coupled asynchronous messaging model. This approaches enables easy scaling and reconfiguration of the enterprise-wide solution.

Among other features and advantages of this architecture are:

1. MDOs can be transferred essentially in real time from medical devices to clinical repositories,

2. Application servers can upload medical device data in real time to clinical repositories,

3. Information can be exchanged as atomic transactions (in which, for example, all of an EKG is transferred at once, rather than piecemeal),

4. Content and format can be completely delineated in the XML documents that are communicated, 5. Strong security can be applied at the transactional level; audit trails record the status of each transaction,

6. Data can be recovered reliably,

7. Web-based access to persist MDOs can be easily implemented and integrated to preexisting web based systems.

In general, in one aspect, the invention features a method that includes receiving data sets that represent information associated with the physical condition of clinical patients, forming mark-up language documents that include information corresponding to the data sets and additional information useful in processing the data sets, and storing the mark-up language documents.

Implementations of the invention may include one or more of the following features. The data sets that represent the physical information may be encoded in accordance with a universal character encoding technique (e.g., Unicode) before forming the mark-up language documents. The result of the universal character encoding technique may be compressed before forming the mark-up language documents. The additional information useful in processing the data sets may include information characterizing devices that were used to acquire the physical information. Requests may be submitted for information included in the mark-up language documents, the requests being expressed in terms of the additional information useful in processing the data sets. The mark-up language documents may be expressed in XML. The data sets may be expressed in accordance with different data protocols associated with different sources of the physical information, and the method may also include determining the type of data protocol in which each of the data sets is expressed, before forming the corresponding mark-up language documents. The mark-up language documents may be stored in a repository that may be remote from the location where the physical information is acquired.

The method may also include responding to requests for the physical information by retrieving the corresponding mark-up language documents and reconstructing the data sets. In general, in another aspect, the invention features a server that is configured to receive data sets that represent information associated with physical condition of medical patients, to form mark-up language documents that include information corresponding to the data sets and additional information useful in processing the data sets, and to forward the mark-up language documents for storage. Implementations of the invention may include one or more of the following features. The server may include an identification mechanism that is configured to identify source devices based on the data sets that are received. The server may also include an interpretation mechanism that is configured to generate the mark-up language documents based on the physical information represented in the data sets and on pre- stored conversion components. The server may include interface engines that are configured to communicate with devices that generate the data sets using pre-defined standard protocols.

Other advantages and features of the invention will become apparent from the following description and from the claims. Figures 1 through 8 illustrate features of implementations of the invention that are discussed below.

Distributed Application Server Architectural Components

As shown in Figure 1, three key components of the distributed application server architecture 10 are the signal processing service 12, the signal persistence service 14, and the retrieval agent 16, all of which can communicate through an intranet or an extranet 18 using encrypted XML documents 20. Signal Processing Service

As shown in Figure 2, the signal processing service 12 receives incoming MDOs 40 from medical devices 42 and transforms them into XML documents 44. For this purpose, each MDO is encoded as compressed Unicode that becomes part of an XML document. The XML document also contains descriptive information or attributes of the MDO.

The signal processing service receives MDOs through one or more interface engines 46. Each interface engine works independently and is able to negotiate with a device or family of devices that are configured to communicate using a specific standard protocol, such as serial communication protocol (SCP) 48, HL7 messages over TCP/IP 50, or the Medical Information Bus (MIB) protocol 52, or a proprietary protocol.

Alternatively, a single interface engine could be configured to communicate using any of several protocols. The capture of each complete MBO by one of the interface engines represents a transaction.

The medical devices could include any kind of device that captures information that is associated with a person and is useful in connection with the deliver of medical care to the person. The information being captured could relate, for example, to chemical parameters, images, temperatures, and electrical signals, to name a few.

Interface Engine The interface engines place the captured MDOs into a first-in, first-out queue 60 for further processing. The interface engines also store transaction information 61, such as the time of the transaction, the identity of the medical device, the identity of the receiving interface engine, and the size of the MBO, in a transaction log 62 for later use in disaster recovery or auditing.

Each interface engine can be implemented as a combination of hardware and software, for example a computer with a serial port, modem, or network interface card to provide a communication link with one or more of the medical devices.

The software part of an interface engine manages the interface engine's hardware components during communication sessions with medical devices. Among other things, the software receives incoming communications initiated by a medical device, identifies the communication protocol being used, initializes hardware components of the interface engine to converse with the medical device using the identified protocol, manages the integrity of the transmission, and terminates the session after the MDO has been received.

For example, if a device uses IPX as the communication protocol to send an MDO to the interface engine, the software identifies the protocol during hand-shaking, sets the network interface card to use IPX, monitors the process of transmission of the MDO from the medical device to the interface engine, and guaranties that each segment of the communication is competed correctly.

Identification Agent Each of the MDOs stored in the queue 60 is drawn from the queue and processed in turn by an identification agent 64. The identification agent determines the type of medical device that produced the current MDO (e.g., a Model Q Glucose Monitor manufactured by Company R) or the protocol used to transfer the MDO. To do this, the identification agent uses a device reference knowledge base 66, which contains a description or signature of the format of the data of each type of MDO that is expected to be received by the signal processing server. The identification agent tries to detect and identify a newly installed device by using the device knowledge base and matching algorithms (not shown).

MDO Device Information

Each MDO signature in the device reference knowledge base identifies at least the following information about the type of device that produces MDOs having that signature: 1. Manufacturer of the device, (e.g., HP, SpaceLabs)

2. Type of signal produced by the device (e.g., a 12-lead ECG or 2- or 4- channel processed EEG

3. Model or models of the device that could produce the signal associated with the morphological aspects of this type of signal (e.g., EKG cart HP

TraceMaster)

4. Interface mechanism a. Communication media through which the device communicates, for example, an RS232 port, modem, Ethernet-based card. b. Communication protocol used by the device i. TCP/IP ii. IPX iii. MIB iv. SCP v. Asynchronous or synchronous communication mode.

(Synchronous communication implies that the device that is sending information will lock all the resources of the receiver device during the process of communication, requiring confirmation messages from the receiver each time that a segment of information is delivered. The sender device is not able to perform any other communication activity using the same interface when it works in synchronous mode. In an asynchronous mode, the sender device does not lock all resources of the receiver and it is able to sustain other communication activities using the same interface.) c. Ability to transmit more than one MDO in a single communication session.

MDO Signature

Morphologically, an MDO signature has the following characteristics:

1. A minimum length in bits/bytes to be considered a complete signal, i.e., one that has not been chopped during the transmission process. 2. If a proprietary protocol was used, a definition of the protocol signal: a. Location of data elements and delimiters used to separate them. b. # of bits or bytes. c. where each data element should begin. 3. Length of each data element in bits or bytes. 4. Closing signature (sequence of bits or bytes that mark the end of the signal). The identification agent takes the MDO and uses one or more pattern-matching algorithms to match the signal to the morphological descriptions contained in the Device Reference Knowledge Base. Each of the pattern-matching algorithms identifies an incoming MDO by comparing its characteristics to those of generic classes in which it could be group or classified. For example, all EKG signals may start or terminate with a series of bits that distinguish them from signals coming from oximeters.

Interpretation Agent

Once the type of device that generated the MDO or the MDO has been identified, an ID of the device or signal is sent with the raw signal 70 to an interpretation agent 72. The interpretation agent, relying on a library of device/signal specific interpretation components 74, stored in a device/signal specific component library 76, generates a signal portable representation (in some implementations, an XML document) 44. The XML document contains appropriate tags that delineate the attributes of the MDO based on the signal.

The software interpretation components of the device/signal specific component library 76 are stored in a database that has been organized under an index based on the functional characteristics of the components. Each of the software interpretation components is able to interpret each type of MDO in its digital format, transform it into a character based system called Unicode, compressing the Unicode, and assemble an XML document (using the compressed Unicode) that serves as an envelope for its transport over the intranet extranet and eventual manipulation by other components of the architecture.

Conversely, each of the software components in the library 76 can reproduce an MDO by taking an XML document, stripping out the compressed Unicode representation, decompressing it, and applying a reverse conversion process to the one used to generate the Unicode.

Both the library of interpretation components 76 and the device reference knowledge base 66 can be upgraded and expanded through a management console (not shown), which assures the ability to maintain the capabilities of the signal processing server 12 over time.

Unicode and Compressed Unicode Versions ofMD

By a Unicode version we mean a sequence of text or script characters that are used to represent (encode) sequences of bits/bytes that are found in the digital MDO signal. Unicode is an international character-encoding standard used for character and string manipulation that enables universal data exchange capabilities for global marketing, using a single binary file for every possible character code. Unicode defines semantics for each character, standardizes script behavior, provides a standard algorithm for bi-directional text, and defines cross-mappings to other standards. Unicode is one implementation of a universal character encoding technique, but other encoding approaches could also be used

Compressed Unicode is generated by applying compression algorithms to reduce the size of the Unicoded version of the MDO, which reduces the cost of moving the MDO data over the intranet/extranet. Compression can be performed on just the data content of the MDO or on the entire transmission unit (including header data generated as part of the process of transmission). Content compression can be as simple as removing extra space characters, inserting a single repeat character to indicate a string of repeated characters, and substituting smaller bit strings for frequently occurring characters. Compression or decompression is performed by a program that uses an algorithm to determine how to compress or decompress data. The algorithms analyze the morphological characteristics of the data and create a version of it in which redundant information is represented in optimal ways. Such an algorithm could use (1) statistical models for data compression and decompression; (2) substitution of occurrence of a particular phrase or group of bytes with a reference to a previous occurrence of that phrase while keeping track of the last n bytes of data seen; (3) when a phrase is encountered that has already been seen, outputing a pair of values corresponding to the position of the phrase in the previously-seen buffer of data, and the length of the phrase. The XML Document

Following is an example of how a compressed Unicode version of an MDO may be embedded in an XML document, showing the tags: <?xml version="1.0"?> <ECGDOC><ECG_HEADER><Patient_Unit_No>3332K/Patient_Unit _No><Patient_Name>ROYERS,MARYANN</Patient_Name><Cart_ID

>032</Cart_IDxSite_No>34</Site_No><Sequence_No>0</Sequence_ No><Acq_Date>02/25/l 999</Acq_Date><Patient_Age> 11 </Patient_Ag e><Acq_Time>30900</Acq_Time><Patient_Sex>F</Patient_Sex><Pati ent_Room>835</Patient_RoomxOrdering_Doctor_Name>.</Ordering_ Doctor_NamexInternal_No></Intemal_No><P_Axis> 19</P_Axis><Q

RS_Axis>94</QRS_Axis><T_Axis>21 </T_Axis><AVG_Rate></AVG _Rate>< A V_Ratex/AV_RatexP_Onset> 158</P_Onset><P_Offset>20 2</P_OffsetxQ_Onset>234</Q_OnsetxQ_Offset>276</Q_OffsetxT _Offset>424</T_OffsetxQRS_Intx/QRS_IntxPR_Intx/PR_IntxQ T_Int></QT_IntxQTc_Intx/QTc_IntxiNTERPRETATION>Sinus_r hythm. Axis to the right. Compared to the previous tracing no significant change.

TRACING#2|</rNTERPRETATION><Preliminary_Report></Prelimina ry_ReportxReviewed_Approved_byx/Reviewed_Approved_byxRea d_by>THOMAS I. SULLIVAN.M.D.

/Read_by></ECG_HEADERxECG_BODYxECG_Wavefor?/format= "alphahex" type='Ol" size="2057">080901313037313838352020202020303232353936303833 35000000000000000000000000000000000000000000000000000000000 0000000000000000000000000002A65AC1ABB2058329500AF7BFC04

3F808FFFFFFFC047F80877F8757FOE1FE1DDF250015956010041D4 ED9CD9250004B594000000000000000004A4B2914CB594B05250014 8510562C115B55208B1596C2C1B3F8093E7F1FE1FEFE1F7CFBFC36 BF814FF029FE02DF9EFFOF9F76D4546C45115150015284A0288A45 425442DA5B220000215B20000000000000000002510B022D928A1295 05B2288ASB22A22D6970B21595596C17AF9FC043F31FC053F8FFO FCFE1D5FC30BF8117F03AFE043F9BFC3EFDADCA2364522A00450 280B0512895158D9164AAAA8226C0002500ACAOOOOOOOOOOOOB25B

25592A29058454545B140A4A00591489488D1A65560A82C05F7BF3F FFFO 16FFFFC0681907D241 C A58494305430D4394F576CF4E63 A58D 81A1A281973AEA1A1F4CFC0084A2A7C26864A5A5BOFA283B112 868E860A920A06865960E8729F286E1E86526F2966E06D828E82A29 4B43393B4361206961E51EOAA28606AE8AECFCOD008C250DOCC

A1A1AAA5B0943A1EFFOB6060696C81D14DOCA3COCA3DCOEC4 C350ECCC28606A61280532D4D4434A4D141COD82AE9207CBBF9 CABA185A284BD2435153C0DOD9F9F81FOF7F2F010FFA6A485A1 94B2068A160E58AB3F381FOFEB909460B510560E9EC94303432CD1 41D81ASA1D81EF2424A01183A2A00048000134E4A682A307435D4

50543439E021E1FDB9051307130949034507450B68A061E2ESOC010 687703A1FDB1F5C00590001DOE6268A1ADOE07C3F83E025434305 55530F4B45536877FB2AE12AA52D240D64DF4EFE7031D055307280 4616DOC9034025034305784A481A2B0B43034343981E8616922A8E1 28000000000000000000000000000000000000000000000000000000000

00000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000 0000</EcG_waveform></ECG_BODYx/ECGDOC>

The XML document 44 conforms to a common information model that generalizes characteristics of a device or device family. In addition to the MDO data, the XML document contains the following information elements:

1. type of MDO

2. device that produced the MDO

3. date and time at which the MDO was received and processed

4. date and time when the MDO was generated 5. identification of measurements embedded in the MDO

6. demographic information about the patient from whom the MDO was captured

7. interpretative information

Routing Agent

The XML document 44 is routed to the signal persistence service 14 by a routing agent 80 that is part of the signal processing service. The routing agent manages a routing table 82 that defines rules associated with locations and ways to route the XML document. The routing agent fetches an appropriate delivery route 84 from the routing table based on the type of MDO.

The rules in the routing table determine, for example, the number of attempts the signal processing service will try to communicate with a signal persistence service before aborting, the waiting time before dropping an attempted of communication, and possible alternative routing.

The routing agent encrypts (using public key~asymmetric~ cryptography) and securely transfers the encrypted XML document 81 to a location that hosts a signal persistence service 14 that is to handle the XML document, he transfer is logged and audited. Signal Persistence Service

As shown in Figure 3, the signal persistence service 14 processes the encrypted XML documents produced by the signal processing services 12 and stores them in one or more clinical XML information repositories 92 or legacy clinical information repositories 90. The signal persistence service also recreates on demand encrypted XML documents based on the information held in the repositories for delivery to other locations in the system. The process of making the MDO data persistent within the system takes place as follows:

Access Gateways

Encrypted XML documents 81 are received asynchronously at the signal persistence service from signal processing services located throughout the system. The documents are received through the Intranet/Extranet 18 by one or more access gateways 102, 104, 106, 108.

Each access gateway is configured to effect communication in accordance with a particular communication protocol, for example, TCP/IP. Each access gateway includes hardware that interacts with communication lines and software that manages the interaction so that complete encrypted XML documents 110 are ultimately provided to an incoming XML first-in, first-out queue 112. The receipt of each of the incoming documents is logged in a transaction log 114 for later verification and other purposes.

Each of the encrypted XML documents is withdrawn in turn from the queue 112, decrypted using the sender's public key, and analyzed by a persistence daemon 116. This daemon identifies the MDO embedded in the document by analyzing the XML elements and based on the result proceeds to store the information into the corresponding repository using the repository's native interface. The access can either be wrapper-based 101 (in the case of a legacy system) or API-based 103.

Persistence Daemon

The persistence daemon arranges for the persistent storage in and retrieval from repositories 90, 92 of the MDO information embedded in the XML documents, for the benefit of the signal processing servers located throughout the system. When an MDO is expressed in XML, all attributes of the MDO are part of the

XML formulation. The attributes are XML elements that can be identified by parsing. Examples of some MDO attributes could be date, time, make/year/model of device, type of encoding, resolution, units for plotting, and text associated with signal.

Because the tags associated with each element describe its content, the daemon knows what it is reading, (e.g., if the daemon finds the tag <model> it will use rules in the repository directory that allow it to understand what model means and what can be done with the content of such a tag, and based on the findings will attempt to classify the signal and placed it in the right repository for the kind of MDO being processed. Repository Directory

Each repository is characterized by a type of MDO that it is configured to store, for example EKGs, oximeter readings, or cardiac monitor readings. A repository directory 120 contains references to all repositories available to the daemon.

The repository directory contains rules expressed as XSL (Extensible Stylesheet Language) and XSLT (Extensible Stylesheet Language Transformation) that enable the daemon to extract and store data from an XML document in a format that is proper for a given repository. These rules are manipulation mechanisms that allow the daemon to discover what information is contained in an XML document that includes an MDO. The daemon uses the rules to make sense of the tags in the XML document and to extract the information in the right context.

For example, the tag <frequency> could be contained in two different rules in the repository directory, the two different rules having different meanings with respect to the MDOs that each of them is configured to handle.

Persistence Index

The persistence daemon also maintains a persistence index 122 that store attributes of original XML documents that enable retrieval and re-creation of the XML documents using MDO data stored in the repositories. The repositories store the MDO data while the XML document attributes are maintained by the persistence daemon to facilitate search and retrieval of the signals from within the repository.

The persistence index functions as a directory that stores pointers (direct references) to the stored XML documents representing MDOs. As in a search engine some key parameters common to all XML documents stored in the repository are kept by the persistence index and it associates a location for the XML document in the repository based on those parameters.

The persistence index entries for a given XML document are created from a subset of the tags in the XML document that relate to the type of MDO stored in the repository. For example, if a particular clinical information repository maintains EKGs, the persistence index entries for MDOs in that repository could be based on the patient ID and the date in which each EKG was captured. Updates to MDOs

The signal persistence service allows logical groupings of all incoming updates of MDOs using the same mechanism employed to store the MDO in the first place. The process of update is governed by the information in the Persistence Index. Changes to the repository entry that result from an update will be reflected in the persistence index. Each time that somebody modifies an attribute that is used to index the XML documents in the repository the index is updated. For example, assume that the name of the patient is an attribute of the XML document that is used by the persistence index to create the indexes that it manages. If the name of the patient has been misspelled in a particular XML document and is later corrected, the correction will trigger an update in the indexes so that the persistence index can locate the document when requested.

The signal persistence service is able to identify the XML version of an MDO that has been stored in a clinical information repository by using the persistence index, retrieve the XML version, and make additions or changes to the XML content, storing the modified XML document back in the repository. The signal persistence service has a set of rules that determine how XML documents get updated and under which circumstances. For example, the signal persistence service could contain a rule that requires all changes to an XML document to be appended as a separate attribute that describe the change and who committed it, or a rule that an attribute that contains the medical record number associated with the patient that originated the signal cannot be left blank as part of an update.

The repository wrapper serves as a broker between the persistence processing server and a legacy system, allowing them to communicate and exchange information. It interprets XML documents containing MDOs, extracting their attributes for storage in the legacy system in accordance with the data structures defined within the legacy system. Conversely, the wrapper is able to query the legacy system and retrieve all the attributes corresponding to a particular MDO previously stored by the wrapper and reassemble it as an XML document to be consumed by the persistence processing server. Retrieval

As shown in Figure 4, to retrieve information from the signal persistence service, a retrieval agent (described below) posts a request 130 composed of one or more key attributes. The key attributes are combinations of tags and values for the tags that can be used by the signal persistence service to query the persistence index to identify uniquely an MDO stored as XML in one of the clinical information repositories maintained by the persistent daemon. In response to the request, the signal persistence service returns an encrypted

XML document 132 in which the MBO and its attributes are embedded. To retrieve the MBO from the persistence store, the signal persistence service uses the persistence index based on the key attributes provided by the retrieval agent such as image id, patient id, and date. Based on a profile of the requester 133 contained in the routing table 134, the persistence daemon encrypts the document using the requester public key and sends the result using the same protocol that the requester employed to post its inquiry. Retrieval Agent

As shown in Figure 5, the retrieval agent 150 brokers on behalf of an application 152, the retrieval and presentation of MDOs that are stored (persisted) in repositories associated with signal persistence services 154, 156, 158 distributed throughout the system, based on information that uniquely identifies the MDOs that are being requested. For example, a web-based electronic patient record could request all the EEGs performed on a particular patient and produce a summary of all the major attributes contained in the XML documents retrieved on the web browser. The retrieval agent can be running on a server located remotely from both the application and the signal persistence services.

Each retrieval agent subscribes to one or more of the signal persistence services 154, 156, 158. In general, when an application 152 has made a request 163 for an MBO, the request is received through an intranet/extranet exposed API 165. A retrieval component 167 in the retrieval agent then broadcasts a corresponding request 168 for the MBO to all subscribed signal persistence services. The broadcast request is encrypted with the public key of the requesting application?

The signal persistence service that contains the MBO that is being requested provides the response through the Intranet Extranet as an encrypted XML document 170, which contains the MBO and related information available in the repository. The entire retrieval process is audited according to stated security policies. A security policy is, for example, a predefined rule defining what information can be accessed and at what level of detail.

In one implementation, an audit trail registers all transactions that have been executed against a particular signal persistence service by different entities of the system that have reason to retrieve an MDO. The audit trail is also useful for troubleshooting.

Exracting information

Upon receipt of an encrypted XML document, the retrieval agent employs the same component library 166 used by the signal persistence service to extract both the information describing the signal and to decompress the MBO to its native format. A graphical rendering engine 169 is also provided to translate the signal from its native format to a standard vector image format that can be integrated as part of an internet- based multimedia electronic medical record. A graphical rendering engine is a software component that is able to produce images in the form of bitmaps or streaming images based on a series of programming statements and data points. It takes the bits/bytes that compose the MBO and uses them to produce a series of coordinates in a x/y space that are used to reproduce the original signal. The resulting images can be delivered to any web-based application.

Other implementations are within the scope of the following claims. For example, the components of the system described above can be distributed in a wide range of configurations according to the needs of the information infrastructure defined for the healthcare system where the application servers are going to be deployed. Figures 5, 6, and 7 depict some of the possible configurations using independent application servers. What is claimed is:

Claims

1. A method comprising receiving data sets that represent information associated with physical conditions of medical patients, forming mark-up language documents that include information corresponding to the data sets and additional information useful in processing the data sets, and storing the mark-up language documents.

2. The method of claim 1 in which the data sets are encoded in accordance with a universal character encoding technique before forming the mark-up language documents.

3. The method of claim 2 in which the universal character encoding technique comprises Unicode.

4. The method of claim 2 also including compressing a result of the universal character encoding technique before forming the mark-up language documents.

5. The method of claim 1 in which the additional information useful in processing the data sets includes information characterizing devices that were used to acquire the physical information.

6. The method of claim 1 also including submitting requests for information included in the mark-up language documents, the requests being expressed in terms of the additional information useful in processing the data sets.

7. The method of claim 1 in which the mark-up language documents are expressed in XML.

8. The method of claim 1 in which the data sets are expressed in accordance with different data protocols associated with different sources of the physical information, and the method also includes determining the type of data protocol in which each of the data sets is expressed, before forming the corresponding mark-up language documents.

9. The method of claim 1 also including responding to requests for the physical information by retrieving the corresponding mark-up language documents and reconstructing the data sets.

10. The method of claim 1 in which the mark-up language documents are stored in a repository that is remote from the location where the physical information is acquired.

11. Apparatus comprising a server that is configured to receive data sets that represent information associated with physical conditions of medical patients, form mark-up language documents that include information corresponding to the data sets and additional information useful in processing the data sets, and forward the mark-up language documents for storage.

12. The apparatus of claim 11 in which the server comprises an identification mechanism that is configured to identify source devices based on the data sets that are received.

13. The apparatus of claim 11 in which the server comprise an interpretation mechanism that is configured to generate the mark-up language documents based on the physical information represented in the data sets and on pre- stored conversion components.

14. The apparatus of claim 11 in which the server comprises interface engines that are configured to communicate with devices that generate the data sets using pre-defined standard protocols.

15. Apparatus comprising a port that receives data sets from devices that acquire information from medical patients about their physical conditions, the data sets being expressed in different predefined standard protocols, a server that identifies the devices that acquired the physical information, and converts the data sets to standard mark up language documents based on pre-stored conversion information, and a port that sends the mark-up language documents to remote locations for further processing.

16. A method comprising receiving standard mark-up language documents that include information corresponding to data sets that represent physical information associated with medical patients, the mark-up language documents including additional information useful in processing the data sets, storing the data sets in repositories, receiving requests for physical information represented by the data sets, the requests being expressed in terms of the additional information, and retrieving data sets that are responsive to the requests from the repository, forming standard mark-up language documents that include information corresponding to the retrieved datasets, and forwarding the mark-up language documents to another location.

17. A method comprising receiving requests for physical information associated with medial patients, identifying remote repositories in which the requested physical information is stored, submitting queries to the repositories based on the requests, receiving standard mark-up language documents from the repositories, deriving the requested physical information from the mark-up language documents, and forwarding the requested physical information to another location.

18. A system comprising medical devices configured to generate physical information associated with medical patients, repositories that store the physical information, applications that use the physical information, and a server architecture that is configured to interact with the applications, the medical devices, and the repositories to store physical information from the medical devices in the repository and to respond to requests from the applications for physical information stored in the repositories.

19. The system of claim 18 in which the server architecture includes a signal processing service that interacts with the medical devices, a persistence processing service that interacts with the repositories, and a retrieval agent that interacts with the applications, the physical information being embedded in standard mark-up language documents for at least some of the communication among the signal processing service, the persistence processing service, and the retrieval agent.

20. The system of claim 19 in which the signal processing service, the persistence processing service, and the retrieval agent share a common location.

21. The system of claim 19 in which at least two of the signal processing service, the persistence processing service, and the retrieval agent are at different locations.

22. The system of claim 19 in which at least two of the signal processing service, the persistence processing service, and the retrieval agent communicate through an intranet/extranet.