Originally Published MEM Fall 2003

SOFTWARE

Using what was learned from the more cumbersome HTML, XML could be the best language for programming medical electronics used in a hospital environment.

Edward F. Steinfeld

Instrument designers seldom talk to information technology (IT) departments. But this will change with the increased use of XML coded data. Most IT departments have decided to use eXtensible Markup Language (XML) corporatewide. And that decision can extend down to the requests sent to instruments and the data generated by those instruments. With this trend, instrument and device manufacturers—even in the medical industry—may have to poll their potential customers and speak to IT database designers to determine whether they are using XML.

In many cases, the database designers have already defined a schema for their XML coded data. The instrument manufacturers cannot economically customize every instrument, but they can devise a common set of XML tags that can be easily mapped to the existing database schema. This collaboration will have to extend to competitors and to other manufacturers supplying the same industry. Some industry XML standards have been created in a few industries such as medical (the Health Level 7 [HL7] specification for the exchange of structured clinical documents) and process control.

The information coded using XML does not have to be just data. It can also be actions and related parameters—similar to remote procedure calls (RPCs). Using XML, hospital IT departments can monitor and manage devices in the lab and in the patient's room.

XML

XML provides a processor-independent way of encoding data for interchange between diverse systems. XML is derived from standard generalized markup language (SGML), as is hypertext markup language (HTML), but has been simplified for easier machine parsing. Unlike HTML, XML has no predefined meanings associated with its elements or tags. Instead, XML is a set of rules (a syntax) for construction of tag-delimited information. Individual XML documents can use different element definitions to encode information from different data environments. A set of element definitions to encode data from a particular data environment is called a schema.

Different schemas or element definitions that use XML syntax are being developed for different application environments. Some of these schemas include vocabularies for chemical engineering, vector graphics, electronic invoicing, weather information, and spreadsheet formulas. A specific XML schema (tag set definition) can be defined by one organization and published for others. For example, Microsoft has defined a set of XML tags for exchanging spreadsheet and word processing documents with the Office 2000 and Office XP product suites. Industry standards groups sometimes get together to define element sets. Vector graphics and chemical engineering groups are currently developing XML schema standards.

Two functions or programs are required to convert a schema-defined document into internal data and vice versa. A parser is a program that reads an XML document and provides access to the data inside the XML tags. A framer is a program that takes internal data and formats them into an XML document.

XML and Hospital Data Flow

From the time a doctor decides a patient needs a set of blood tests to the time the data are actually provided, the requests and results pass through a number of steps, including telling the instruments what tests to perform.

Figure 1. Hospital data flow using XML framed data from source to instruments and back. (click to enlarge)

After the doctor decides on a set of tests, the doctor or a nurse enters the requests into the office computer (see Figure 1). The requests are XML framed and sent to the hospital IT computer. From there, the requests are sent to the nurses' station on the floor where the patient is located. A pickup list is printed so nurses know which patients are to provide fluids for testing. A bar-coded label is also provided to attach to the fluid vial. The test requests are sent to the labs. The instruments recognize the tests they perform along with the patient identification data. The hospital IT computer also sends the requests to the appropriate laboratories; in this case, the pathology laboratory.

Figure 2. XML code sent to a number of medical lab instruments. Each instrument will recognize only the XML tags defined in its ObjectDefs.o and will ignore the others. (click to enlarge)

The data sent to the lab include the patient identification and the tests to be performed. The hospital IT computer does not specify which instruments will perform the tests; the same information is sent to all the instruments. Most embedded XML parsers will ignore all data framed by tags not identified for them but will accept all data within tags they do understand. This means the same set of data records can be sent to all the test instruments in the pathology lab (see Figure 2). The blood chemistry tester will accept all tests enclosed by the ChemTest tag (BUN or blood urea nitrogen test) but will ignore test requests enclosed by the CellTest tag. The blood cell analyzer will accept both the leukocyte count (total white blood cell count test) and diff test requests (the percentage difference of each type of white cell).

All instruments will accept the patient identification data. In the meantime, a nurse collects the fluids and carries them to the lab. Once the tests are completed, the results and patient identification are sent by the lab or instrument computers to the hospital IT computer. A copy of the results is sent to the nurses' station to be printed or displayed. Another copy of the results is sent to the requesting doctor's computer. And finally, a copy of the tests performed is sent to the billing and insurance department computer.

Generalized XML parser-framers are used in the computers for each user: doctor, nurses' station, billing department, and hospital IT. Special embedded XML parser-framers are used in the testing instruments. Figure 2 shows the XML code sent to a number of medical lab instruments. Each instrument recognizes only the XML tags defined in its ObjectDefs.o and ignores the others. (Note: For clarity, these examples do not conform to the HL7 specification for the exchange of structured clinical documents, ANSI/HL7 CDA R1.0-2000, Clinical Document Architecture [CDA]).

HTML-XML Comparison

Both HTML and XML were derived from the tag description language SGML. Both SGML and HTML describe the format of the data, whereas XML describes the content of the data. All SGML and HTML tags are predefined, unlike XML tags whose definition is up to the programmer (and sometimes the industry). Some key features of XML include:

• All elements must be balanced with a start tag and an end tag or use a special self-terminating format.
• Nesting is strictly enforced.
• Attributes within tags always use quotes.
• XML is case sensitive, so <TAG>, <tag>, and <Tag> are different and could have different meanings (see Table I).

XML syntax provides a free-format interchange of data. The definitions of the schema can be documented in a number of ways so that communities of users other than the original definer can understand what the designer of the schema intended. Schemas can be documented using SGML document type definition (DTD) language, World Wide Web Consortium (W3C) XML Schema Definition language, or other techniques using XML primitives. One inexpensive program to help with XML schemas is XML Spy suite. A 30-day evaluation copy may be downloaded. It is an XML editor, schema designer, and more.

With some schema definition techniques, a general-purpose parser can read a DTD or schema file that contains the definitions it needs to parse a particular XML document. A parser that checks an XML document for correct XML syntax is said to be checking for well-formed XML documents. A parser that checks XML documents against an external DTD definition is said to be a validating parser. Because embedded systems (devices, instruments, etc.) are predefined and their XML tags are predefined, the schema definitions can be handled outside the embedded system, thus reducing the system requirements in the device.

XML documents are both human- and machine-readable. The same schema can be defined using multiple techniques. The Allegro Software Development (San Jose) RomXML parser and framer (described later) use a special schema definition language (RxSchema) similar to the W3C XML Schema Definition that uses XML elements to define the XML schema. RxSchema provides control over the internal storage definition, which is useful in limited-resource, embedded environments.

Embedded XML Parser and Framer

It is useful for an embedded device to exchange XML-based data with other embedded devices, general-purpose desktop workstations, or mainframe computers. However, the processing and memory footprint for a general-purpose XML parser are prohibitive. An embedded device does not need a dynamic tag set or vocabulary, because each embedded device is typically a single-purpose device. Allegro provides a toolkit for such devices.

An embedded XML parser efficiently translates data between XML syntax and an internal format (such as a C structure). The Allegro RomXML parser-framer provides a lightweight translation between predefined C language structures and XML-based representations. By defining the rules for data translation external to the embedded device, a small-footprint special-purpose XML translator can be built that uses dedicated vocabulary definitions to reduce code size and data storage size. This enables the embedded device to move data to other machines in an XML-based standard format without carrying the overhead of general-purpose XML tools. The RomXML parser-framer fits in about 10 Kbytes of memory in the device.

Figure 3. TagBuilder creates XML object definitions outside the device. (click to enlarge)

The RomXML toolkit uses a special set of XML tags to define an XML object. The XML object is defined both with the C language internal storage structures and the XML tag set that will be used for the XML-based data interchange. The RomXML TagBuilder utility program analyzes the RomXML object definitions and produces an object definition file in C language source (see Figure 3) that is compiled with the RomXML parser-framer code (see Figure 4). The object definition file contains the transformation tables that the runtime RomXML code uses to perform specific translations for each XML object between the defined C structures and XML tag set.

Figure 4. XML object definitions are compiled and linked with the application, RomXML runtime library, and real-time operating system (RTOS). (click to enlarge)

The RomXML TagBuilder program uses standard C library calls for reading and writing the XML object definition files. The TagBuilder program is delivered in executable form as a Microsoft Windows program or in source format for developers who wish to host it in a particular UNIX environment.

Figure 5. Incoming XML framed records are scanned by the RomXML Parser program and predefined object definitions and the data inserted in the appropriate C data structures. (click to enlarge)

The RomXML runtime code is a series of calls that the developer uses to handle the XML objects. A developer can pass an incoming XML data stream and the XML object definition to the RomXML program and it will parse the XML data stream into a C structure (see Figure 5).

Figure 6. Data in the device are XML framed by RomXML framer and the predefined XML object definitions. The data are framed with the appropriate XML tags. (click to enlarge)

A developer can pass a C structure and the XML object definition to the RomXML program, and it will prepare an XML data stream by framing the data from the C language structure with the appropriate XML tags (see Figure 6).

RomXML software works directly with a stand-alone embedded application or with other Allegro products. XML data streams can be transmitted to and from other systems as an HTTP object using the RomPager embedded Web server or the RomWebClient embedded HTTP client. The XML data streams may also be sent and received as e-mail attachments using the RomMailer or RomPOP embedded e-mail programs.

XML Translation

Figure 7. A portion of an XML framed data transfer showing a few of the different types of information that could be included using XML. (click to enlarge)

An XML document contains XML syntax elements that describe the structure of the data and the underlying data. The XML document itself does not contain any information about how to store the data in a given device. An example XML document that contains some information about a hospital patient is shown in Figure 7.

Figure 8. A portion of a C program describing the data structure where the XML framed data in Figure 7 would be stored in an embedded device.

The XML schema or tag set used in this particular document provides a framing of the data that can be clearly understood by both human and machine readers. In order for an embedded device to use the data in this XML document, it might decide to store the underlying data in a series of C structures such as those shown in Figure 8.

The RomXML parser-framer provides an efficient mechanism for translating data between XML representations of the data and internal C-structure representations of the data. The RxSchema language is used to describe the relationships between the XML document and the C structures. Because XML is a string language that expresses structure but not data types, the RxSchema language is also used to define to the embedded device that the <field2> tag frames an unsigned 32-bit integer value and that the <switch> tag frames a value expressed in dotted decimal notation.

TagBuilder Utility

The RxSchema language is expressed in XML using a notation similar to the W3C XML schema definition language. The definitions of the XML document to be parsed and framed along with the definitions of the internal C structure are compiled with the TagBuilder utility to provide a compact internal representation of the translation definitions.

After linking the compiled definitions with the RomXML runtime library and the rest of the embedded-device software, the device can read an XML document and call the RomXML parser to translate the document into the internal format. When the device is ready to create an XML document, the device can call the RomXML framer to translate the internal format into the document.

RxSchema

Figure 9. RomXML embedded XML uses an XML-based schema to define the relationships of the XML data tags to the embedded C program data structure. The schema is used to predefine these relationships rather than use resources to do it during runtime. (click to enlarge)

The XML document that contains the set of RxSchema definitions for the sample C-language structures and sample XML document would look like the code in Figure 9. This example in Figures 7, 8, and 9 contains a modified subset of an example taken from the Allegro RomXML Programming Reference Manual.

Conclusion

Network-enabled devices become easier to deploy and interoperate with an IT department using embedded XML parsers and framers. Device designers can use the more general XML products, but additional resources are required, which could make producing the device cost-prohibitive. And because embedded or stand-alone products are usually single-purpose devices, there is no need for dynamic tag resolution.

When searching the Internet for embedded XML, results will vary. Hits for embedded XML databases, embedded XML documentation, XML embedded in HTML, embedded XML parser-only, and so on will appear. Few companies provide an embedded XML parser-framer product. Allegro's RomXML may be the most popular. Intel and others have promoted the Xerces, which are XML parsers written in Java and C++ for embedded systems. Xerces provides XML parsing and generation intended for workstations and servers. It is part of the open-source Apache Web server offering.

Many real-time operating system (RTOS) vendors, such as Green Hills Software and OSE, provide embedded XML from third parties. Others, like Wind River Systems, provide pointers to compatible offerings. Go to your favorite RTOS provider and search for XML.

The embedded XML toolkit products from Allegro are provided as ANSI C sources. This toolkit sells for about $15,000, but it is royalty-free for runtime code sold on a single platform or product. This is typical for many network toolkits for embedded products.

Using XML framed data everywhere means the hospital IT staff can use the same tags to identify data in many different computing systems. The entry made by a doctor will use the same tags as the mainframe, bar-code printer, and finance computer. These same tags will be used by the nurse's station, the laboratory computers, and the medical devices. An IT analyst can read the data code going into and out of thse various computing centers and fully understand what is being processed. Using the XML CDA tags allows all these systems to speak the same language. It is now up to the instrument manufacturers to take the extra step and include an XML parser-framer in their products.

Edward F. Steinfeld is an embedded-computing market consultant for Automata International Marketing (Westford, MA). He can be reached at 978-376-3146 or via e-mail at edward@go-embedded.com. For more information, go to http://www.go-embedded.com.

Copyright ©2003 Medical Electronics Manufacturing