Clinical Chemistry 52: 1943-1951, 2006.
First published August 3, 2006; 10.1373/clinchem.2006.071449
(Clinical Chemistry. 2006;52:1943-1951.)
© 2006 American Association for Clinical Chemistry, Inc.
Definition of an XML Markup Language for Clinical Laboratory Procedures and Comparison with Generic XML Markup
Gilan M. Saadawi1,3 and
James H. Harrison, Jr2,4,a
Centers for1
Biomedical Informatics and 2
Pathology Informatics and Biomedical Informatics, University of Pittsburgh School of Medicine, Pittsburgh PA.
Current addresses:3
Division of Informatics and Department of Health and Community Systems, School of Nursing, University of Pittsburgh, Pittsburgh PA; and 4
Division of Clinical Informatics and Departments of Public Health Sciences and Pathology, University of Virginia School of Medicine, Charlottesville VA.
aAddress correspondence to this author at: Department of Public Health Sciences, P.O. Box 800717, Charlottesville VA 22908. Fax 434-924-8437; e-mail james.harrison{at}virginia.edu.
 |
Abstract
|
|---|
Background: Clinical laboratory procedure manuals are typically maintained as word processor files and are inefficient to store and search, require substantial effort for review and updating, and integrate poorly with other laboratory information. Electronic document management systems could improve procedure management and utility. As a first step toward building such systems, we have developed a prototype electronic format for laboratory procedures using Extensible Markup Language (XML).
Methods: Representative laboratory procedures were analyzed to identify document structure and data elements. This information was used to create a markup vocabulary, CLP-ML, expressed as an XML Document Type Definition (DTD). To determine whether this markup provided advantages over generic markup, we compared procedures structured with CLP-ML or with the vocabulary of the Health Level Seven, Inc. (HL7) Clinical Document Architecture (CDA) narrative block.
Results: CLP-ML includes 124 XML tags and supports a variety of procedure types across different laboratory sections. When compared with a general-purpose markup vocabulary (CDA narrative block), CLP-ML documents were easier to edit and read, less complex structurally, and simpler to traverse for searching and retrieval.
Conclusion: In combination with appropriate software, CLP-ML is designed to support electronic authoring, reviewing, distributing, and searching of clinical laboratory procedures from a central repository, decreasing procedure maintenance effort and increasing the utility of procedure information. A standard electronic procedure format could also allow laboratories and vendors to share procedures and procedure layouts, minimizing duplicative word processor editing. Our results suggest that laboratory-specific markup such as CLP-ML will provide greater benefit for such systems than generic markup.
|
Introduction
|
|---|
Clinical laboratory procedure manuals are standardized documents that formalize actions and policies required for testing, maintenance, and safety, and also serve as references and teaching resources. Procedures that are reviewed periodically are required for clinical laboratory accreditation, and management of procedure manuals is a recurring and time-consuming activity. Procedures are typically developed as word processor files and printed on paper for use. Paper manuals need sizeable storage space, are inefficient to use and search, and are often tied to a particular location or author. Optimizing content or format for different uses requires manual editing and reprinting. Clinical and patient test references may partially duplicate the procedure manual and often become outdated and "out of sync" with it.
Most laboratories format their procedures according to guidelines from the Clinical and Laboratory Standards Institute (CLSI) (1)1
. Because these guidelines do not provide detailed requirements for content or layout below the section level, manuals from different laboratories and vendor-supplied procedures differ in formatting style and organization. This means that much manual editing and reformatting are usually necessary when procedures are shared between laboratories or provided by vendors.
New document management and communication technologies from the Internet and World Wide Web may solve these problems. In particular, the Extensible Markup Language (XML) (2) can be used to specify a laboratory procedure document format allowing procedures to be maintained in a central electronic repository for distributed access. This strategy would allow text searching across document collections, unification of reference and procedure manuals with user-specific views, online review and signature of documents, and sharing of procedure content among laboratories and test vendors.
We present a prototype XML markup language (Clinical Laboratory Procedure Markup Language, CLP-ML) designed for laboratory procedures. The CLP-ML specification is available free for noncommercial use (see the Data Supplement that accompanies the online version of this article at http://www.clinchem.org/content/vol52/issue10) under the GNU General Public License (3). To evaluate CLP-ML complexity, we compared the size and structural features of CLP-ML documents with those of a generic healthcare document markup format, the Health Level Seven, Inc. (HL7) Clinical Document Architecture (CDA) Narrative Block.
|
extensible markup language (xml) documents
|
|---|
XML (2) is a specification for creating text markup languages. It is being adopted in biomedical science (4)(5) and other domains as a standard for data publishing and exchange. XML documents can be displayed by standard Web browsers or parsed to extract defined data elements. Formatting for display or printing is specified in separate stylesheets (Cascading Stylesheets, CSS (6), or Extensible Style Language, XSL (7)). Common stylesheets can be applied to multiple XML source documents for standardized display, or multiple stylesheets can provide usage-tailored displays from a single source document. XML also promises cross-platform applicability with long-term stability appropriate for data repositories (8)(9)(10).
An XML file contains document text and embedded character strings (markup elements, often called "tags") that provide structure and additional information (Fig. 1 in the online Data Supplement). An XML markup specification defines a set of markup tags and their syntax in a Document Type Definition [DTD (11)] or an XML schema [for example (12)]. The tags from a DTD or schema make up an "XML vocabulary"2
or markup language.
XML vocabularies may be domain specific or generic. Domain-specific markup supports a limited number of related document types and identifies document elements that have particular meaning within the domain. Generic markup, in contrast, is designed for use with many different document types. It provides structural information about document components (e.g., "paragraph", "list") but does not describe the meaning of the document contents. Generic XML document vocabularies include DocBookXML for software documentation (13) and XHTML for Web documents(14).
The CDA (15) is an XML vocabulary developed by the Health Level Seven standards organization (16). Release 2 of the CDA (17)(18) became an American National Standards Institute (ANSI) standard in 2005. It is primarily designed for exchanging clinical documents between data systems and includes an optional Narrative Block that provides generic markup (e.g., "sections", "paragraphs", "lists"). The CDA has recently been extended to nonclinical healthcare documents and might be an alternative for laboratory procedures. However, the maintenance, editing, and query requirements of laboratory procedures are demanding, and it is not clear whether they might be best met by a generic format or a specific laboratory procedure format such as CLP-ML.
|
Materials and Methods
|
|---|
Representative testing procedures or physician reference manual entries from clinical laboratories in the Presbyterian and Shadyside Hospitals (University of Pittsburgh Medical Center), University of Virginia Hospital, and the Mayo Clinic Laboratory were analyzed to identify their structural and data elements. The evaluation included manual and automated chemistry, hematology, immunology, microbiology, and maintenance procedures, and corresponding physician reference manual entries. We also included the data elements recommended for online clinical laboratory user manuals (19). This information was used to create a laboratory–procedure-specific XML markup vocabulary. Laboratory personnel evaluated additional procedure documents structured with this vocabulary, and their feedback was used to develop the final CLP-ML DTD (see the online Data Supplement). The major sections specified by CLP-ML (Fig. 1
) are compatible with CLSI guidelines (1). CLP-ML also provides detailed internal markup for the top-rank sections (Fig. 2
) and introduces several new sections designed for physicians and patients. An excerpt of a procedure showing the XML markup corresponding to the outline in Fig. 2A
is shown in Fig. 3
.
View larger version (47K):
[in this window]
[in a new window]
|
Figure 1. CLP-ML document main sections.
The root tag, labProcedure, contains the entire procedure document. Only the 27 top-level subtags are shown; a simplified listing of the contents of each subtag is displayed in italics. A more detailed view of representative sections is shown in Fig. 2
. Note that introduction contains clinicalSignificance, interpretation, and patientGuide. These sections are designed to incorporate the information from physician and patient test guides into the procedure manual.
|
|
View larger version (24K):
[in this window]
[in a new window]
|
Figure 2. Structure of the specimen requirements (A) and main procedures (B) sections.
(A), Each physical specimen is represented by a specimen element and its contents (A, lines 2–25). Detailed information on patient preparation, volume, stability, etc., optionally may be included on a per specimen basis (A, lines 5–25) or for the group of specimens as a whole (A, lines 26–31, tag contents omitted to save space). Most of the elements listed are optional and their inclusion may be tailored to fit laboratory and particular assay needs. Representative XML source code for a specimen requirements section is shown in Fig. 3
. (B), The mainProcedures element (B, line 1) includes an optional description and may contain multiple procedures (one representative procedure structure is shown, B, lines 3–15). Each procedure tag (B, line 3) contains an optional description and may contain multiple step tags that list the procedure actions. A step tag may be recursive (contain nested step tags representing subprocedures, B, lines 8–10) or conditional (define one or more conditions followed by actions that are carried out if all the conditions are true, B, lines 11–13). The procedure tag is also used in other settings in which stepwise sequences of actions are important (for example, A, line 6, in patientPrep, and line 25, in rejection).
|
|
View larger version (48K):
[in this window]
[in a new window]
|
Figure 3. Detail of specimen requirements XML markup.
This excerpt from an existing 5-fluorocytosine assay procedure shows the XML source code for a specimen requirements section. Note that many of the optional elements listed in Fig. 2
A are not used. Two specimens are shown, serum (line 2) and plasma (line 10). Attributes such as "type" for specimen and container (for example, lines 3–5) may use standard nomenclature or codes defined locally. Volume, storage, and rejection information (lines 16–37) is provided outside of the individual specimen tags and applies to both specimens. The precaution text on lines 8 and 14 use an XML entity (&UNIVPRC;) that is replaced at display time with standard universal precaution text defined in the DTD. The CLP-ML DTD includes several common warnings and precautions as entities.
|
|
For comparison purposes, we developed a CDA Narrative Block section–level template (17)(18) that is compatible with CLSI recommendations (1) and comparable in organization to CLP-ML. An outline of our CDA procedure document structure is available in Fig. 2 in the online Data Supplement and is further discussed in the Results section.
The comparison study included 4 procedures of varying length and complexity that were marked up with each vocabulary (Table 1
). These included an HPLC assay (5-fluorocytosine, 5-FC), an automated chemistry procedure (creatine kinase MB fraction on the Bayer® Centaur® analyzer), a manual procedure (prothrombin/partial thromboplastin time), and a microbiology procedure (ß-streptococcal screening). Markup was carried out on plain text versions of the word processor procedure files with XML Spy® (20) or <oXygen/>® (21) XML-editing software. Each marked-up document was validated against its DTD (CLP-ML, see the online Supplemental Data) or schema [CDA, with the CDA release 2 schema from the January 2005 HL7 membership ballot 1 (17)] with the <oXygen/> editor. The relative performance of the 2 vocabularies was evaluated by comparing the size and complexity of the marked-up documents and the complexity of pathways required for traversal of the documents to specific data elements. Document complexity was assessed as the total number of tags per document and the maximum degree of tag nesting (Table 1
). The complexity of traversal pathways was evaluated as the length of the XML Path Language (XPath) expression (22) and the number of text matching operations required for traversal from the document root to representative document sections or data elements (Table 2
). We also carried out a limited subjective evaluation of readability and ease of markup for laboratory technologists.
|
Results
|
|---|
procedure-specific markup
CLP-ML contains 124 XML tags (elements) and 27 top-rank sections (Fig. 1 and the CLP-ML DTD in the online Data Supplement). Eight tags provide method and document identification, history, and acceptance information; 19 tags represent the major technical sections of a procedure; and the remainder support detailed markup within major sections. Most sections and subsections are optional to allow the specification to accommodate various procedure types including patient testing, safety, monitoring and maintenance; the only required main subsections are title, usage, history, introduction, and mainProcedures. Authorship, review, acceptance, and versioning information is maintained in the history element. Electronic signatures are supported through the XML Signature standard ( (24), see Discussion). CLP-ML introduces new procedure subsections to contain descriptive material for physicians and patients (as subelements of introduction, Fig. 1
).
Section-specific markup derives element and attribute names from standard laboratory procedure nomenclature (see Figs. 2
and 3
). Similar data types were consolidated, where possible, into shared general-purpose elements with attributes defining specific usage. For example, identifier is a general element containing codes, catalog numbers, and other designators, and value can represent a wide variety of numerical or ordinal quantities (Fig. 3 in the online Data Supplement). There is only one purely structural element, p, for separating text into paragraphs. Special-purpose text (precautions, warnings, notes, etc.) is specified using an optional paragraph type attribute (see Fig. 3
, lines 8 and 23).
The primary list(s) of actions the procedure comprises is contained in the mainProcedures element (simplified in Fig. 2B
). The mainProcedures content includes an optional text description and 1 or more action lists named procedure. Each procedure may have its own description followed by a sequence of actions represented by step elements containing descriptive text (Fig. 2B
). Steps may be conditional, and conditions and associated actions may be identified using condition and action elements within a step element (Fig. 2B
, lines 12 and 13). Step elements may also be recursive (they may contain step elements), allowing subprocedures within procedures (Fig. 2B
, lines 9 and 10). Procedure, step, and action elements include an optional performer attribute associating these actions with specific roles or personnel. Cross references to other procedure tags or individual step, identifier, value, and figure tags may be specified using an xref tag that points to a unique id attribute in those elements. The combination of recursion, conditional actions, cross-references, and association of actions with performers allows the procedure element to represent complex workflows.
In addition to the main procedure, procedure documents typically contain numerous supporting procedures. Thus the procedure element also appears as a subelement of the referral, rejection, operatorMaintenance, vendorMaintenance, verification, report, prep, calculation, qualityControl, calibration, standards, and results elements and provides the features described above in those settings (see Fig. 2A
, lines 6 and 25).
Three elements link to external files. The element link is similar to a hyperlink in XHTML (14) and designates a related external document or document section. The include element can replace sections likely to be redundant in a group of similar procedures and can point to a central file or file subsection that contains shared information. This tag could allow, for example, aggregation of all laboratory vendor information into a single document to serve as a resource for many procedures. Image data may be referenced using a figure tag that links to an external graphics file, similar to current XHTML image tags, or that contains an internal XML representation of a figure as Scalable Vector Graphics (SVG (23)).
cda-based markup
CDA header tags were used to specify the identity of the document and method, and its authorship, version, acceptance, and implementation date. The procedure was contained in structuredBody, as a list of components corresponding to the major subsections of the procedure (see outline in Fig. 2 Data Supplement that accompanies the online version of this article at http://www.clinchem.org/content/vol52/issue9 ). Each component contained a section tag, which in turn contained a text tag representing the narrative block of the section. Subsections were specified using component/section/text tags within a section, and headings and text were written explicitly and structured generically as titles, captions, lists, tables, or paragraphs.
comparison of procedure-specific and cda markup
Representative laboratory procedures were marked up using CLP-ML and generic CDA markup (Table 1
). The procedures spanned a range of complexity and contained 
3000 to 23 000 characters before markup. CLP-ML markup was relatively finely granular, including all applicable data element tags. CDA markup included similar textual content with markup to the paragraph, table, and list item rank. In general, CLP-ML produced smaller documents than CDA markup (Table 1
) because specific markup allows section and subsection titles to be omitted from the source document and inserted for display by stylesheets.
Document complexity was assessed as the total number of XML tags per document, the maximum nesting rank of tags, and the number of XPath (22) nodes and operations required to specify representative document sections. The total number of XML tags per procedure was generally comparable (Table 1
). Markup nesting, however, was consistently lower with CLP-ML than CDA markup, reflecting the ability of procedure-specific markup to designate document sections and subsections using meaningfully named tags (for example, Figs. 2
and 3
) rather than the combination of component/section/text tags with section titles containing the names of the subsections (Fig. 2 in the online Data Supplement).
XPath (22) expressions targeting the document sections containing the clinical significance, reference range, control, or specimen requirements for a serum specimen were considerably more complex with CDA markup than CLP-ML (Table 2
and Fig. 4
). XPath expressions identify a section of an XML document by specifying a path from a reference point (in this case the top or root tag of the document) through the hierarchy of XML tags, or nodes, to the desired tag or content. The path may include text matching or tag sequence designations as necessary to select among tags of the same name. For these 4 representative document sections, XPath expressions for CDA documents were generally twice the length or more of those for CLP-ML documents, and they required more matching operations (Table 2
). Because CDA markup tags are generic (e.g., component, section, text, paragraph, list), specific identification of a section of a document required multiple text-matching operations that depended on consistent document section titles (Fig. 4
, bottom). In contrast, CLP-ML tag names and attributes allowed document sections to be identified purely by path or path plus limited text matching against defined tag attribute values rather than document text content (Fig. 4
, top). Because XPath complexity influences the complexity of query expressions (XQuery (25)) required to target document sections and data elements, these results suggest that searching XML document collections would be simpler and less prone to error with CLP-ML than CDA markup.
View larger version (21K):
[in this window]
[in a new window]
|
Figure 4. Representative XPath expressions for CLP-ML (upper) and CDA (lower) markup.
These expressions target clinicalSignificance and specimen where specimenType is serum in the 5-fluorocytosine HPLC procedure. Both CLP-ML expressions are 3 nodes long; the second expression also includes one match to a type attribute of a specimenType element. The CDA expressions are both 7 nodes long; because the CDA document contains many component, section, text, paragraph and item elements, the first expression requires 2 text matches and the second expression 3 text matches to target the correct data. XPath expressions represent document components as a path from the document root tag through the hierarchy of tags (nodes) to locate a particular tag or its contents. Nodes may have matching operations specified in square brackets, which are used to distinguish between multiple nodes with identical names but different content. Matching operations contain an XPath expression on the left of the equal sign that identifies an XML tag or attribute (relative to the tag named before the square brackets) and a match value for the tag or attribute contents on the right. Attribute names used in expressions are denoted by a preceding "@".
|
|
In a limited evaluation with laboratory technologists, we found that source XML documents and XPath expressions based on CLP-ML were more easily readable and understandable than those based on CDA markup (data not shown). CLP-ML documents processed to produce a standard hierarchical indentation pattern were more visually compact, and the meaningful element names aided orientation when reading the document (for example, Fig. 3
). CDA-based markup produced documents that were more deeply nested, and the large number of generically named tags appeared to hinder reader orientation and readability. Thus CLP-ML appeared to have an advantage in settings where reviewing or editing the XML source documents might be beneficial.
|
Discussion
|
|---|
Procedure manual management is a demanding exercise in collaborative authorship that requires substantial laboratory resources. The result is valuable: procedure manuals aggregate a variety of information that should be useful to the laboratory and to the constituencies that laboratories serve. Unfortunately, the usual procedure management process restricts the benefit of this effort. Recently, XML markup has enabled online collaborative authorship and flexible information distribution in a variety of settings, for example, newspapers (26), publishing(13), online software documentation (27), and online encyclopedias (28). If appropriately implemented, an analogous system for managing laboratory procedures could decrease the effort of maintaining procedure manuals while substantially improving their accessibility and usefulness.
As the first step toward electronic management of laboratory procedures, we have developed a prototype XML DTD (see the online Data Supplement) that consists of a data model and markup language, CLP-ML, for authoring, maintaining, and sharing procedures. We express this markup specification in a DTD rather than an XML Schema (12) because DTD files are more compact and easier to read and conceptualize. Conversion of DTDs to schemas is straightforward and can be automated (21). Our procedure-specific markup can express both analytic and nonanalytic procedures across different laboratory sections. CLP-ML can represent complex in-laboratory technical workflows and supports the process of procedure authoring, review, and acceptance. Its structure is compatible with CLSI guidelines (1) and recommendations for online clinical laboratory user manuals (19). CLP-ML supports markup of sufficient detail to identify items and values in procedures for complex formatting, searching, or automated processing but allows simpler markup as an option. CLP-ML also adds new sections for physician and patient information, allowing laboratory user manuals to be incorporated into procedures and, with appropriate stylesheets, displayed as a subset of procedure information.
CLP-ML produced more readable, shorter documents with comparable XML tag frequency and simpler structure than a generic XML markup standard, the HL7 CDA Narrative Block (Tables 1
and 2
). One advantage of domain-specific markup is that it can define XML tags that clearly identify specific data and document locations. For example, the tags marking procedure subsections have unique names in CLP-ML, and therefore, can be used to identify content simply and unambiguously using XPath expressions (Fig. 4
). The ability to clearly identify contents by tags enables correct extraction of data, accurate location of specific points within the document, and fine-grained control of user access and data display. Correct tag naming and document structure may be enforced automatically at authoring time by validation against the document’s DTD or schema.
In contrast, generic markup using the CDA requires external enforcement of document structure and text content conventions so that document sections or data elements can be identified by content matching (see Fig. 4
). Content matching is more complex and less precise than targeting uniquely named tags, and structure/content conventions are difficult to enforce. For example, some of our source procedures referred to "Clinical Significance" while others used "Clinical Background". This degree of variability in the content of generic markup would lead to problems in searching and display, and would also make automated processing difficult. We believe that these findings are generally true for domain-specific vs generic markup.
Several XML-related standards are available that can supplement CLP-ML to provide additional capabilities useful in managing laboratory procedures. For example, XML Signature (24)(29) is a standard for applying digital signatures to XML documents, document subsections, or collections of documents and associated files (such as figures). It supports verification of authenticity, confirmation of data integrity, and nonrepudiation. Signatures may be "detached" and maintained in separate signature files with links to the signed documents, allowing a very flexible approach to document revision, assembly, signing, and verification. The ability to incorporate predefined XML standards allows CLP-ML to benefit both from the extensive markup design work that supports these standards and from existing software libraries written to process them (30).
Although an XML format may identify and provide "containers" for necessary data, the actual features and performance of a laboratory procedure management system depend on the software implementation that uses the format. Comprehensive management systems for XML-based laboratory procedures do not yet exist, but current content management and XML database software could provide a foundation for them. Although they are expensive, commercial document management frameworks such as Documentum® (31) and Content@®(32) provide complete environments including built-in editors, version control, and document workflow management that could be customized for laboratory use. Open-source XML content management systems and native XML databases (33)(34)(35)(36) could provide alternative resources for building systems. Ultimately, procedure management systems would best be incorporated into clinical laboratory information systems, so that procedures can be integrated with laboratory workflow (for example, to provide targeted help during testing or maintenance).
The applicability of XML to routine procedure management is also limited by a lack of inexpensive XML editing software appropriate for nonexperts. Dedicated XML editors (20)(21) are designed for those familiar with markup languages. Conversion software (37) that processes Microsoft Word® documents into XML files could be a useful alternative. Ultimately, XML editors offering a stylesheet-based display during editing (38), native XML word processor formats (39), dedicated laboratory procedure editors (40), or browser-based XML editors(41) will expand the range of individuals who can easily edit XML documents. We hope that our prototype markup language may help stimulate community and vendor interest in developing these concepts and ultimately in providing modern procedure management functions as a standard part of laboratory information systems.
|
Acknowledgments
|
|---|
This work was supported by The Pittsburgh Biomedical Informatics Training Program; National Library of Medicine grant number NLM 5 T15 LM/DEO7059.
|
Footnotes
|
|---|
1 Nonstandard abbreviations: CLSI, Clinical and Laboratory Standards Institute; HL7, Health Level Seven, Inc.; CDA, HL7 Clinical Document Architecture; XSL, Extensible Style Language; DTD, XML Document Type Definition; XHTML, Extensible Hypertext Markup Language; XPath, XML Path Language; XML, Extensible Markup Language; CLP-ML, Clinical Laboratory Procedure Markup Language. 
2 References to specific XML elements are shown in Courier font.
|
References
|
|---|
- . Clinical and Laboratory Standards Institute. Clinical Laboratory Technical Procedure Manuals; Approved Guideline, 4th Ed. Document GP2-A4 2002 CLSI Wayne, PA. .
- World Wide Web Consortium. W3 recommendation February 2004: Extensible Markup Language (XML) 1.0.http://www.w3.org/TR/REC-xml (accessed March 2006)..
- Free Software Foundation, Inc. GNU General Public License. http://www.gnu.org/copyleft/gpl.html (accessed March 2006)..
- Achard F, Vaysseix G, Barillot E. XML, bioinformatics, and data integration. Bioinformatics 2001;17:115-125.[Abstract/Free Full Text]
- Barillot E, Achard F. XML: a lingua franca for science?. Trends Biotechnol 2000;18:331-333.[CrossRef][ISI][Medline]
[Order article via Infotrieve]
- World Wide Web Consortium. Cascading Style Sheets.http://www.w3.org/Style/CSS/ (accessed March 2006)..
- World Wide Web Consortium. The Extensible Style Sheet Language Family. http://www.w3.org/Style/XSL/ (accessed March 2006)..
- Wang C, Kahn CE, Jr. Potential use of extensible markup language for radiology reporting: a tutorial. Radiographics 2000;20:287-293.[Abstract/Free Full Text]
- Sikorski R, Peters R. Metalanguage: XML is hatching. Science 1998;281:1164a.[Free Full Text]
- Schweiger R, Hoelzer S, Altmann U, Rieger J, Dudeck J. Plug-and-play XML: a health care perspective. J Am Med Inform Assoc 2002;9:37-48.[Abstract/Free Full Text]
- Harold ER, Means WS. XML in a Nutshell, 2nd Ed 2002:613pp O’Reilly & Associates Sebastopol. .
- World Wide Web Consortium. W3C Recommendation 28 October 2004: XML Schema Part 0: Primer Second Edition.http://www.w3.org/TR/xmlschema-0/ (accessed March 2006)..
- Wikipedia. DocBook.http://en.wikipedia.org/wiki/DocBook (accessed March 2006)..
- World Wide Web Consortium. W3C Recommendation 26 January 2000, revised 1 August 2002: XHTMLTM 1.0 The Extensible HyperText Markup Language (2nd Edition).http://www.w3.org/TR/xhtml1/ (accessed March 2006)..
- Dolin RH, Alschuler L, Beebe C, Biron PV, Boyer S, Essin D, et al. The HL7 clinical document architecture. J Am Med Inform Assoc 2001;8:552-569.[Abstract/Free Full Text]
- Health Level Seven. http://www.hl7.org (accessed March 2006)..
- Health Level Seven Structured Documents Technical Committee. CDA Release Two Membership Ballot01, Jan 2005.http://www.hl7.org/library/Committees/structure/ CDA.ReleaseTwo.MembershipBallot01.Jan. 2005.zip (accessed March 2006)..
- Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, et al. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc 2006;13:30-39.[Abstract/Free Full Text]
- Beckwith B, Schwartz R, Pantanowitz L. Analysis of on-line clinical laboratory manuals and practical recommendations. Arch Pathol Lab Med 2004;128:476-479.[ISI][Medline]
[Order article via Infotrieve]
- Altova. XML Spy.http://www.altova.com/products_ide.html (accessed March 2006)..
- oXygen XML Editor & XSLT Debugger.http://www.oxygenxml.com/ (accessed March 2006)..
- World Wide Web Consortium. XML Path Language (XPath) 1.0. W3C Recommendation 16 November 1999.http://www.w3.org/TR/xpath (accessed March 2006)..
- World Wide Web Consortium. Scalable Vector Graphics (SVG) Full 1.2 Specification. W3C Working Draft 13 April 2005.http://www.w3.org/TR/SVG12/ (accessed March 2006)..
- World Wide Web Consortium. XML Signature Syntax and Processing. W3C Recommendation 12 February 2002.http://www.w3.org/TR/xmldsig-core/ (accessed March 2006)..
- Word Wide Web Consortium. XQuery 1.0: An XML Query Language. W3C Candidate Recommendation 3 November 2005.http://www.w3.org/TR/xquery/ (accessed March 2006)..
- The News Industry Text Format: Introduction.http://www.nitf.org/intro.php (accessed October 2005)..
- Apache HTTP Server Project: Module Format and Transformation.http://httpd.apache.org/docs-project/docsformat.html (accessed March 2006)..
- Wikipedia. http://www.wikipedia.org (accessed March 2006)..
- Salz R. Understanding XML Digital Signature. Microsoft Developers Network.http://msdn.microsoft.com/library/en-us/dnwebsrv/html/underxmldigsig.asp (accessed April 2006)..
- Java Community Process. JSR-000105 XML Digital Signature APIs, Reference Implementation and Technology Compatibility Kit.http://jcp.org/aboutJava/communityprocess/final/jsr105/index.html (accessed April 2006)..
- EMC Documentum. http://www.documentum.com/ (accessed March 2006)..
- Xyvision Enterprise Solutions. Content@.http://www.xyenterprise.com/packages.asp (accessed March 2006)..
- Apache Lenya. http://lenya.apache.org/ (accessed March 2006)..
- eXist Open Source Native XML Database.http://exist.sourceforge.net (accessed March 2006)..
- Sleepycat Software. Berkely DB XML.http://www.sleepycat.com/products/bdbxml.html (accessed March 2006)..
- Infrae. The Silva Content Management System.http://www.infrae.com/products/silva (accessed March 2006)..
- Infinity Loop: Document Conversion Software. Upcast.http://www.infinity-loop.de/products/upcast/ (accessed March 2006)..
- Serna.http://www.syntext.com/products/serna/index.htm (accessed March 2006)..
- Oasis. Open Document Format for Office Applications (OpenDocument) v1.0.http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf (accessed March 2006)..
- Saadawi G, Harrison JH. A lightweight XML editor for clinical laboratory procedure manuals. Arch Pathol Lab Med 2004;128:1104.
- Xopus, The Friendly XML Editor.http://xopus.com/ (accessed March 2006)..
Top
Abstract
Introduction
