Menu

XML and Standards Rescue Ship-to-Shore Telemedicine

December 19, 1998

Lisa Rein

Until recently, if you were on a boat in the middle of the ocean, and a medical problem arose, that was only the beginning of your problems. Most cruise ships have a general physician on board, but there aren't any specialists available, and often, merchant ships won't have a physician on board at all.

In some cases, remote doctors and patients have been assisted by telemedicine solutions, which traditionally have used video conferencing technology over high-bandwidth connections to transmit video, voice and data. But the video conferencing workstations for these systems usually require an ATM or ISDN connection, as well as dedicated data lines, modems, boards, and software. Such systems can run as high at $60,000 each, placing them well out of the reach of many potential users.

JABR Technology, a year-old Boston-based company, has developed Consult98, a telemedicine system which operates using standard data formats and protocols over the Internet. This solution dramatically lowers the cost of telemedicine by replacing costly workstations with a $500 digital camera and a PC. Additionally, and instead of requiring high-bandwidth connections, Consult98 works using a simple e-mail account.

Consult98 improves specialty medical care by allowing primary care physicians and providers to obtain Web-based consultations from specialists. Consult98 accepts consultations over the Internet using both the Web and e-mail. Privacy of patient information is ensured by high grade encryption through use of the IPsec protocol, authentication and access control.

Standards to the rescue!

"Initially, we realized that we couldn't get a web connection from the boat," explains Dr. Jonathan Borden, chief scientist for JABR Technologies. "The only thing available was an e-mail connection. So we created the ability to use ASP pages over an SMTP E-mail connection."

Borden created a customized SMTP server capable of conducting JavaScript transactions over the Web, using only open standards. Borden fully integrated the e-mail server with scripting languages such as JavaScript, Python and VBScript in the same way that ASP works with the HTTP protocol.

This ASP over e-mail system is called Mail Server Pages (MSP), and is fully transactional. Developers can convert their existing ASP pages within minutes, and reuse all of their ASP components in the e-mail setting.

"By doing this via 'ASP for e-mail' I can take advantage of the tons of third party ASP components that have already been written for ASP," Borden explains. "For example a paging component that can beep the doctor when a consult comes in, if this is more convenient than e-mail."

"The advantage of e-mail is that it is asynchronous," explains Borden. "We created transactional e-mail queues to provide reliability much the same as Microsoft's Message Queue and Exchange. The advantage is that this uses a fully standard messaging protocol, namely SMTP. This allows truly worldwide transactional messaging."

Mail Server Pages and XMTP

Mail Server Pages enable the various pieces of an e-mail message -- message header fields, message text, and attachments -- to be expressed textually, stored in a database, and then transformed with an XSL stylesheet to create an HTML page. Mail Server Pages (MSP) allow SMTP e-mail messages to be processed by "scripts" in exactly the same way that Microsoft Active Server Pages allow Web pages to be scripted.

The implications of this are multifold. MSP pages can be used in a content management system to collect spur of the moment content from different sources, and assemble an end product using a template, for example.

In order to store the MIME messages within a database, Borden, created XMTP (eXtensible Mail Transaction Protocol), as a means for representing MIME messages using XML documents. XMTP represents an integration of XML and SMTP, enabling MIME messages to be encoded into XML.

Borden's XMTP-enabled server converts the pieces of a MIME e-mail message into an HTML 3.2-compliant web page (via an XMTP document). Borden's XMTP transaction server uses simple SMTP and JavaScript to create a reliable, transactional messaging system. Although the proof-of-concept application is a telemedicine implementation, the core technology of the system is in no way medical-specific. It is a simple asynchronous RPC SMTP/MIME/XML system over HTTP, and the pattern matching rules styling engine is Grove/DSSSL based.

Representing the multipart MIME message in XMTP has many advantages. By default, encoding information in XML ensures that it can be indexed in the database, analyzed and routed accordingly. The XMTP server's base64 encoding of image data enables the binary information to be integrated with the textual content contained in a multipart/related MIME message so it may be expressed within a single document.

Proof of Concept:
JABR Technologies' Consult98 Implementation

OceanMed is a service founded by Dr. John Coller, a surgeon at the Lahey Clinic just outside of Boston, along with Mr. David Earley. OceanMed was able to use the Consult98 system to transport live images from across the world to an e-mail-integrated Web server where specialists from the Lahey Clinic and New England Medical Center retrieved the data, consulted it, held conferences and e-mailed their recommendations back to the ships.

"We went live on the ship in the middle of a hurricane in the Gulf of Mexico, and the system worked on the first try," Borden explains. "The first consult was transmitted within one hour of the digital camera arriving on board."

Consult98 allows images and other medical information to be packaged in standard Internet data formats including MIME, text, and JPEG. The information can also be in the DICOM 3.0 protocol, which is the ISO/ANSI standard network protocol for exchanging images between medical imaging devices of the American College of Radiology(ACR)/National Electrical Manufacturers Association(NEMA) Digital Image Communication for Medicine(DICOM). ACR/NEMA DICOM 3.0 is the standard format for transmitting images between, for example, an MRI machine, an image archive, and a medical imaging workstation.

Consult98 receives an incoming "consult" (represented as a multipart MIME message) which is then processed, indexed, converted into an XMTP formatted document, and stored in a database (ideally, the GroveBase, but this can be any kind of lightweight database).

Why e-mail?

One of the initial constraints of this project was that Borden was forced to work with the existing Lotus cc:Mail system already in place on the ships, so in this case plain text was used. This required some additional modifications to Consult98 to enable the plain/text MIME type to transmit the information rather than Consult98's native XML.

"Initially, we realized that we couldn't get a Web connection from the boat," explains Borden. "The only thing available was an e-mail connection. So what we created was the ability to use our system over an SMTP e-mail connection."

"The advantage of e-mail is that it is asynchronous. We created transactional e-mail queues to provide reliability much the same as Microsoft's Message Queue and Exchange. The advantage is that this uses a fully standard messaging protocol, namely SMTP. This allows truly worldwide transactional messaging."

"Without a doubt e-mail is the single biggest application in the medical community," explains Borden. "What we have done is integrate standard SMTP e-mail with XML so that we can index this information." Through the XMTP protocol, e-mail information can be integrated into databases and transformed using standards such as DSSSL and/or XSL.

"We use a hybrid approach," explains Borden. "The message can be either completely XML based or contain an XML header. Parameters are specified by XML tags. If binary data is needed, this fits into a multipart message. Since we are using a combination of MIME and XML we have incredible flexibility and the power to do complex datatype representation."

The intention is to eventually encode the MIME message body in XML rather than text/plain in order to tag diagnostic information. For example:


<consult>

	<patient>

		<lastname>Yeltsin</lastname>

		<firstname>Boris</firstname>

	</patient>

	<symptoms>

		<chest>cough</chest>

		<abdomen>tender</abdomen>

	</symptoms>

	<allergies>penicillin</allergies>

	<history>chronic pneumonia</history>

</consult>

How it works

Mail Server Pages
eXtensible Mail Transaction Protocol (XMTP)

Diagram of how MSP works.

The process begins on the ship, where a digital camera is plugged into a PC and a digital image is taken of the patient's injury.

The digital image is then optimized as a JPEG file, and sent along with an HTML-based form as an ordinary e-mail attachment (multipart/related MIME message).

The e-mail is received by the XMTP server, a modified mail server that uses JavaScript to transform the pieces of the multipart/related MIME message into an XMTP document. Base64 encoding is used to "flatten" the binary JPEG file so it may be expressed textually in the XMTP document. The XMTP document is then stored in the GroveBase, where a Microsoft IIS server can access it and use it with an XSL stylesheet to transform the data it contains into an HTML page. Finally, a link to the Web page is e-mailed to a doctor to examine.

Representing the multipart MIME message in XMTP has many advantages. By default, encoding patient information in XML ensures that the consults can be indexed in the database, analyzed and routed to the correct specialist according to Consult98's pattern matching rules engine. In this way, binary images can be integrated with textual data.

The demo

Borden has created an online demonstration of XMTP so that developers can test it in an interactive fashion. The XMTP demo is available by sending e-mail to test-xmtp@jabr.ne.mediaone.net.

When someone sends an e-mail message to the address, this script is invoked.

The script will return an XMTP encoding of the MIME e-mail message when it sends you a reply. Be sure to attach a binary image file so you can see the image base64 encoded and expressed in the XMTP document that is e-mailed back to you.

The doctor will see you now

When a doctor is ready to view the consult, he visits the specified URL. The ASP gets the consult (MIME/XML) from the database and formats it on the fly into HTML. This separation of content from presentation offers flexibility, Borden says. "Different specialists may wish to have the same consult displayed differently. Each can have their own style sheet."

The doctors never need to know that they are using XML any more than they know they are using ASP or HTML. They are paged when a consult has been made available on the web site, and then they can respond using e-mail. This is all very natural for doctors that are used to being paged with questions and consults.

The patient information is entered into the system using either an HTML-based form or a simple text-based e-mail message. Once the message is received by the server, JavaScript components are used to transform the contents into an XMTP document and store them in the Consult98 repository. Currently, any ordinary relational database is used as a backing store for the indexed XML tags, but the next version of the system will be able to store the patient records in their native, Grove-based format. Under this architecture, the XML DOM will become the native API for accessing information from the Consult99 repository."

A "Grove" format is just the same thing as DOM format. When the data is stored in native DOM or Grove format, the data is accessed via the DOM or Grove API (these are essentially the same). Normal databases have their own access mechanisms. For relational data (i.e. in tables) the ODBC API provides access to the tabular data. In Consult98 the ODBC API conformant database is used as a "backing store".

This means that the XML and objects are converted into relational table format and stored in the database and then retrieved and reconstructed.

A big advantage of relational databases is that you can do complex searches across the indexed data. Now imagine another type of database, a GroveBase: in a GroveBase, objects are stored in native DOM format and are accessed through the DOM or Grove interfaces.

This looks like a massive in-memory DOM representation of the patient record as a richly linked document.

XTRIME is the eXtensible Transacted Internet Messaging Engine; the "brains" behind the operation. XTRIME works with either Mail Server Pages or Active Server Pages.

Although standards-based, Borden's ASP-like scripting components are COM components nonetheless (Jade is another example of a standards-based COM component.) The builtin Ctx variable is the script context. This is a transaction controller as well as object factory:

The call

var SMTP = Ctx.CreateObject("XTRIME.SMTPMessage");

creates a SMTP object or component which can be scripted. The interface by which an object is scripted is essentially the " DOM" for that object. The name XTRIME.SMTPMessage is directly analogous to the SMTPMessage class in the XTRIME package (for Java) except that this uses a arbitrary language.

Conclusion

JABR Technologies' Consult98 telemedicine system provides yet another example of how XML can be utilized now, using today's existing formats and protocols.

"Individual consults are about communication, and the Internet is the perfect communications medium. Improving the quality of medical care is about information, and XML is the best means of transmitting medical information. It is open for inspection and examination and there are lots of outstanding free parsers and tools. XML solves the problem of proprietary information," explains Borden. "As a patient, you want the doctor of your choice to be able to access your records. Every doctor can read, and any computer can read XML so its a perfect fit."