An American National Standard
Designation: E 2183 – 02
Standard Guide for
XML DTD Design, Architecture and Implementation1
This standard is issued under the fixed designation E 2183; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (e) indicates an editorial change since the last revision or reapproval.
1. Scope
1.1 Recently, there has been widespread use of the Internet
by the health care industry to represent information. Much of
the success of the Internet can be attributed to the World Wide
Web (WWW) and its browsing system, which make it possible
to navigate the Internet by pointing and clicking. Web pages,
electronic documents located on the Internet, are published to
a computer screen by a browser. These pages are developed
using HyperText Markup Language (HTML).
1.1.1 The next generation of the WWW and web pages has
arrived with the specification of eXtensible Markup Language
(XML). Just like HTML, XML can define how pages appear in
web browser. Additionally XML provides a context for infor-
mation. While HTML tells the browser what a page should
look like, XML defines what the piece of information actually
means. Both HTML and XML are markup languages; that is,
they insert markup, or additional information, into text. The
markup is known as a tag. For example, HTML marks up text
on a page by inserting a <B> tag when the text should be
bolded and by inserting a <H1> tag around the first heading of
a web page. In HTML, there is no way to distinguish between
a medical record number or an telephone number because they
are both tagged <B> for bold. XML, on the other hand, marks
each item with special tags so that computers can tell the
difference. With XML, humans and computers can tell the
difference between a <DIAGNOSIS> tag and <SYMPTOM>
or a <Medical.Record.Number> from a <Phone.Number>.
1.1.2 The names of the tags and the rules for using them are
contained in the DTD or Document Type Definition (DTD).
The DTD describes the structure of the document and defines
the names of tags it contains. Additionally, the DTD declares
the order in which the tags occur and how often the tags can
appear; that is, the DTD defines the hierarchy of the tags. A
DTD for a prescription might contain structural elements for
the medication prescribed, the dosage, the form, the quantity,
and so forth.
1
This guide is under the jurisdiction of ASTM Committee E31 on Healthcare
Informatics and is the direct responsibility of Subcommittee E31.28 on Electronic
Healthcare Records.
Current edition approved Jan 10, 2002. Published March 2002.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.
1
1.2 This guide provides a compendium of information for
the use of E 2183 XML DTDs within health care. This guide
describes design considerations, the architecture of the DTDs,
and implementing systems using the E 2183 DTDs.
1.3 This guide refers to and makes use of recommendations
from the World Wide Web consortium, the W3C (http://
www.w3.org).
1.4 This standard does not purport to address all of the
safety concerns, if any, associated with its use. It is the
responsibility of the user of this standard to establish appro-
priate safety and health practices and determine the applica-
bility of regulatory requirements prior to use.
2. Referenced Documents
2.1 ASTM Standards:
E 1239 Guide for Description of Reservation/Registration-
Admission, Discharge, Transfer (R-ADT) Systems for
Electronic Health Record (EHR) Systems2
E 1384 Guide for Content and Structure of the Electronic
Health Record (EHR)2
E 1633 Specification for Coded Values Used in the Elec-
tronic Health Record2
E 2182 Specification for Clinical XML DTDs in Health-
care2
2.2 W3C World Wide Web Consortium Recommendations,
(http://www.w3.org)
XML 1.0 Recommendation, http://www.w3.org/TR/REC-
xml
XHTML Basic Recommendation, http://www.w3.org/TR/
xhtml-basic
XML Linking (Xlink) 1.0 Recommendation, http://
www.w3.org/TR/xlink
XML Namespaces Recommendation, http://www.w3.org/
TR/REC-xml-names
XPointer, http://www.w3.org/TR/xptr
XSLT, http://www.w3.org/TR/xslt
2.3 HL7 Standards, (http://www.HL7.org)
Informative Document: Using XML as an Alternative Mes-
sage Syntax for HL7 Version 2.3.x
2
Annual Book of ASTM Standards, Vol 14.01.
 E 2183 – 02
Clinical Document Architecture: Level 1
2.4 IETF Specifications, (http://www.ietf.org)
RFC 2396: Uniform Resource Indentifiers (URI), http://
ietf.org/rfc/rfc2396
3. Terminology
3.1 Definitions:
3.1.1 clinical document, n—defined in terms of the native
XML and hypertext architecture. The Document Type Defini-
tion (DTD) is the base method of defining the structure of a
clinical document. XML schema languages such as the W3C
XML Schema Language and the OASIS RELAXNG Schema
language provide alternative methods of defining clinical
document structures.
3.1.2 clinical document architecture (CDA), n—the HL7
CDA is a document markup standard for the structure and
semantics of exchanged clinical documents. A clinical docu-
ment is a documentation of observations and other services
with the following characteristics: Persistence, Stewardship,
Potential for Authentication, Wholeness, and Human Readabil-
ity. A clinical document is a defined and complete information
object that can exist outside of a message, and can include text,
sounds, and other multimedia content.
3.1.3 document type definition (DTD), n—formal definition
of the elements, structures, and rules for enabling platform
independent data access via XML or for marking up a given
type of SGML document.
3.1.4 extensible markup language (XML), n—a standard
from the World Wide Web Consortium (W3C) that provides for
tagging of information content within documents, offering a
means for representation of content in a format which is both
human and machine readable. Through the use of customizable
style sheets and schemas, information can be represented in a
uniform way, allowing for interchange of both content (data)
and format (metadata).
3.1.5 Health Level 7 (HL7), n—a standards organization
traditionally focused on message-oriented standards for health-
care. HL7 messages are the dominant standard for peer-to-peer
exchange of clinical, text-based information. HL7 has recently
introduced a document-oriented standard, the Clinical Docu-
ment Architecture.
3.1.6 hypertext markup language (HTML), n—the language
used in creating a web page. Its origin is an implementation of
SGML DTD, but whose most recent update is defined in XML
(XHTML). It provides tags regarding the way a document
should be displayed in the text of an HTML document, which
act as commands that a browser interprets when downloading
an HTML file.
3.1.7 namespaces, n—provide a simple method for qualify-
ing element and attribute names used in XML documents. This
is accomplished by associating a particular tag set by associ-
ating a prefix with a URI reference. XML Namespaces provide
a mechanism for authoring compound documents (documents
consisting of elements and attributes from multiple DTDs or
schemas) in such a way that will provide global identification
without collisions of names that are the same but are used
differently.
3.1.8 parser, n—a specialized software program that recog-
nizes markup in a document and differentiates the content from
2
the markup. A parser that reads a DTD and checks and reports
on markup errors is a validating XML parser. A parser can be
built into an XML editor to prevent incorrect tagging and to
check whether a document contains all the required elements.
3.1.9 schema, n—defines the elements that can appear
within the document and the attributes that can be associated
with an element. It also defines the structure of the document:
which elements are child elements of others, the sequence in
which the child elements can appear, and the number of child
elements. It defines whether an element is empty or can include
text. The schema can also define default values for attributes.
Schema is a W3C term for the next generation of DTDs.
3.1.10 stylesheet, n—the XSL Transformations (XSLT) de-
scribes a vocabulary recognized by an XSLT processor to
transform information from an organization in the source file
into a different organization suitable for continued downstream
processing. The Extensible Stylesheet Language (XSL) de-
scribes a vocabulary recognized by a rendering agent to reify
abstract expressions of format into a particular medium of
presentation.
3.1.11 URI, n—identifies a Web resource according to IETF
RFC 2396. Used in practice to form links between, to name,
and to locate web documents. Also used to name XML
namespaces.
3.1.12 valid XML document, n—well-formed with internal
or DOCTYPE reference to element definition of tags within the
document.
3.1.13 W3C (World Wide Web Consortium), n—develops
interoperable technologies (specifications, guidelines, soft-
ware, and tools) to lead the Web to its full potential as a forum
for information, commerce, communication, and collective
understanding.
3.1.14 well-formed XML document, n—an XML document
that conforms to the syntax as specified by the W3C XML 1.0
recommendation.
3.1.15 XHTML, n—HTML documents that are well formed
and can be processed by an XML parser.
3.1.16 XLINK, n—the W3C XML Linking Language de-
fines a method for specifying links between documents and
parts of documents using URIs. Links may be simple, repre-
senting a 1:1 mapping or extended, representing anN:N map-
ping.
3.1.17 XPointer, n—the XML Pointer Language, defines
how individual parts of a document are addressed. XLinks
point to a URI (in practice, a URL) that specifies a particular
resource. The URL may include an XPointer part that more
specifically identifies the desired part or section of the targeted
resource or document. XPointer, the XML Pointer Language,
defines an addressing scheme for individual parts of an XML
document. XLinks point to a URI (in practice, a URL) that
specifies a particular resource. The URI may include an
XPointer part that more specifically identifies the desired part
or element of the targeted resource or document. XPointers use
the same XPath syntax familiar to XSL transformations to
identify the parts of the document they point to, along with a
few additional pieces.
 E 2183 – 02
4. Summary of Guide
4.1 Philosophy of E31 XML DTDs—The philosophy of
ASTM Subcommittee E31.28 was initially based on the
premise that a set of document types for healthcare does not
exist. It is not known if health care documents have common
and identifiable structures. It is generally accepted that some
regularity exists and that this regularity could be used to create
standard high level structures. These standard structures could
then be easily manifested in XML DTDs. Regularity in
document structure is identified by document analysis, review
of health care informatics standards and research and comple-
mentary technology standards.
4.2 Two workshops were held to design and develop the
DTDs. The results of the workshops identified the following:
4.2.1 The sections or categories that exist in clinical docu-
ments,
4.2.2 The order of the sections, if the sequence is important,
and
4.2.3 The number of times the different sections appear in
clinical document types.
4.3 The supporting materials and knowledge of clinical
documentation was used to determine the sections, the order of
the sections and the number of times the sections appeared in
document. This included a review of transcribed reports for
common areas, sections and sub-sections, government forms
for categories for data entry, and demographic information
contained within the header of the Clinical Document Archi-
FIG. 1 DTD Architecture
3
tecture. Using the results of the workshop, this guide, Standard
Practice for XML DTDs for Health Care: GEM: A Document
Model for Clinical Practice Guidelines, Specification E 2182 ,
and other DTDs would be developed.
4.4 The philosophy in DTD design includes the following:
4.4.1 Simplicity of XML document structure,
4.4.2 Agreement on high level structures in clinical docu-
ments,
4.4.3 Ability for International Representations in the XML,
4.4.4 Make use of existing standards where possible, and
4.4.5 Maintain readability.
4.5 Architecture and Design of DTDs—The ASTM DTDs
have been designed to have a common architecture. This
architecture defines a document to consist of a document
header and a document body. The header may be specific to a
particular document type. For instance, the Standard Practice
for XML DTDs for Health Care: GEM: A Document Model
includes a header that is specific to guidelines in Health Care.
4.6 Format and Common Features—Formatting informa-
tion and common features frequently found in these documents
include:
4.6.1 Basic text (including headings, paragraphs, and lists),
4.6.2 Hyperlinks and links to related documents,
4.6.3 Forms,
4.6.4 Tables,
4.6.5 Images, and
4.6.6 Meta information.
 E 2183 – 02
4.7 The design provides for tags that represent common multiple software modules. For instance, the following XML
items such as paragraphs, images and tables. This is provided tags listed below are both valid <Citation> elements. The
by inclusion of the XHTML Basic DTD and the tags, which it Citation elements are defined differently in the DTDs. One
contains. XHTML Basic is designed as a common base that representation makes use of elements and the other makes use
may be extended. The motivation for using XHTML Basic is to of attributes.
incorporate an XHTML document type that can be shared <Citation
across communities, is rich enough to be used for simple Author=9Tunstall-Pedoe, H.9
content authoring, and has the ability to be extended as future Title=9What’s in a name?9
Source=9W3C, 1999 Nov; 317:1-49/>
versions of this guide are developed.
4.8 By allowing the inclusion of XHTML tags, format <Citation>
information may be included within the documents in a <Author>
Tunstall-Pedoe, H.
standard way. The author of the DTD determines which parts </Author>
of the XHTML standard are to be used. A subset of XHTML <Title>
has been developed for use in E 2183 DTDs and is included in What’s in a name?
</Title>
this guide. Some modules of XHTML were not included in the <Source>
ASTM XHTML. These modules include forms and web W3C, 1999 Nov;
specific tags (such as the <HTML> tag itself). Additionally, 317:1-4
</Source>
some attributes of XHTML, which specify the language of the </Citation>
document, are used to indicate sections that are in different
languages (such French or German). Below is an example 4.10 Both versions are defined in a DTD and are defined
operative report, which makes use of the E31.25 architecture differently. The January 1999 W3C recommendation on
and XHTML within the sections. namespaces solves the problem of different content models.
4.9 XML Namespaces—XML Namespaces is a W3C rec- Namespaces allow for a prefix to be added to the element. This
ommendation that allows for a single XML document to prefix allows for tag names to be unique. Conflicts are avoided
contain elements and attributes that are defined for and used by for elements and attributes with the same name.

FIG. 2 Architecture and Inclusion of XHTML Basic

4
 E 2183 – 02
FIG. 3 Use of XHTML in XML Clinical Documents
<Citation.List xmlns:Pub1=9http://WimeTarner.com/cit.dtd9
xmlns:Pub2=9http://Smiley.com/C.dtd9>
<Pub1:Citation Pub1:Author=9Tunstall-Pedoe, H.9
Pub1:Title=9What’s in a name?9
Pub1:Source= 9W3C, 1999 Nov; 317:1-49/>
<Pub2:Citation>
<Pub2:Author>Tunstall-Pedoe, H.< /Pub2:Author>
<Pub2:Title>What’s in a name?< /Pub2:Title>
<Pub2:Source>W3C,1999 Nov;317:1-4< /Pub2:Source>
</Pub2:Citation>
</Citation.List>
4.11 The E 2183 DTDs may make use of namespaces to
resolve conflicts with other XML standards and XHTML tags.
4.12 XLink—XLink defines the XML Linking Language
(XLink), which allows elements to be inserted into XML
documents in order to create and describe links between
resources. It uses XML syntax to create structures that can
describe the simple unidirectional hyperlinks of today’s
HTML, as well as more sophisticated links. The XLink
specification defines the XML Pointer Language (XPointer),
the language to be used as a fragment identifier for any
URI-reference that locates an XML resource. XPointer sup-
ports addressing into the internal structures of XML docu-
ments. It allows for traversals of a document tree and choice of
its internal parts based on various properties, such as element
types, attribute values, character content, and relative position.
4.13 The base E 2183 DTD includes the XLink Namespace.
5
5. Significance and Use
5.1 Naming Conventions—E 2183 DTDs will use the fol-
lowing Naming Conventions:
5.1.1 Tag names are in English,
5.1.2 Tag names are not shortened; readability is of utmost
importance,
5.1.3 Tag names are lowercase except for appropriate ab-
breviations and acronyms (US, ASTM), and
5.1.4 Tag names with multiple words are separated with a
period “.”; for example, patient.name.
5.2 Architecture—The following architecture is to be used
by ASTM DTDs:
5.2.1 Root Level—The root level tag will contain the name
of the document type. For instance, the root level element for
an operative report will be <operative.report> and for a
guideline document <guideline>.
5.2.2 Header and Body—The root level element will con-
tain two children elements: a document header and a document
body. The document header will contain sections that are
relevant for the document. In a guideline document the header
may contain information about the guideline developer and
meta-information about the guideline such as its title, release
date, and whether or not there are companion documents.
5.2.3 Format—Format information may be expressed by
inclusion of any XHTML tag.
 E 2183 – 02
5.2.4 Body Sections—The DTDs will create section level
tags.
5.3 XHTML Basic—XHTML Basic consists of the follow-
ing XHTML modules:
5.3.1 Structure Module—body, head, html, title.
5.3.2 Text Module—abbr, acronym, address, blockquote, br,
cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q,
samp, span, strong, var.
5.3.3 Hypertext Module—a.
5.3.4 List Module—dl, dt, dd, ol, ul, li.
5.3.5 Basic Forms Module—form, input, label, select, op-
tion, textarea.
5.3.6 Basic Tables Module—caption, table, td, th, tr.
5.3.7 Image Module—img.
5.3.8 Object Module—object, param.
5.3.9 Metainformation Module—meta.
5.3.10 Link Module—link.
5.3.11 Base Module—base.
5.4 A modularized XHTML Basic DTD was developed for
use with the ASTM DTDs. This modularized DTD does not
contain the following modules:
5.4.1 Structure Module—body, head, html, title.
5.4.2 Basic Forms Module—form, input, label, select, op-
tion, textarea.
5.4.3 Metainformation Module—meta.
5.4.4 Base Module—base.
5.5 Namespaces—The namespaces recommendation was
specified after the XML Version 1.0 Recommendation and
there are some issues merging DTDs and namespaces. DTDs
and validity are concepts defined in XML 1.0. The XML
Namespace recommendation came after the XML 1.0 recom-
mendation and is layered on top of XML 1.0. The XML
Namespaces recommendation does not redefine validity. The
implication of this is that validity is the same for a document
that uses XML Namespaces and one that doesn’t. Because of
this, XML documents that are expect to be valid are not and
documents that are expected to be invalid are valid. The
guidelines for writing documents that are both valid and
conform to the XML Namespaces recommendation are:
5.5.1 Declare all xmlns attributes in the DTD,
5.5.2 Use the same qualified names in the DTD and the
body of the document,
5.5.3 Use one prefix per XML Namespace,
5.5.4 Do not use the same prefix for more than one XML
Namespace, and
5.5.5 Use at most one default XML Namespace.
5.6 Header Requirements—The ASTM Clinical Header
DTD was designed to be compatible with the HL7 CDA
Header in order to facilitate conversion of an ASTM Clinical
Header to the HL7 CDA Header using an XSLT transform. The
ASTM Subcommittee E31.25 develops headers specific to the
needs of the ASTM documents. Different document types will
require different document specific information. A common
clinical header is included in this guide but its use is not
required.
6. Scope
6.1 Valid XML Documents with DTDs—A document is
tested for conformance to this guide by referencing an ASTM
6
DTD defined by using this guide and using a validating XML
Parser according to the W3C XML 1.0 recommendation,
http://www.w3.org/TR/2000/REC-xml-20001006. A conform-
ant document must validate without errors according to XML
1.0. When developing software to create and edit clinical
documents, it is desirable to customize DTDs according to the
specific needs of the editing or other software. This is advis-
able. It is not required nor even encouraged that the standard
DTDs be used unmodified during the editing process. It is the
final document output or the editor, or other transformation
software, which must conform to the standard DTDs.
6.2 Conformant XML DTDs and Documents—A conform-
ant document must also conform to constraints expressed
within the prose of this guide; however, this guide does not
express a formal means of testing conformance to such
additional constraints such as adherence to the architecture.
The E 2183 DTDs must conform to the architecture, naming
conventions, inclusion of XHTML, and allow for namespace
usage as defined in this guide.
7. Significance and Use
7.1 The intended use of this guide is as an outline for the
development of E 2183 DTDs.
8. Procedure
8.1 This guide is to be used as the template for E 2183 DTD
design, architecture, and development. E 2183 architecture
DTDs have the following DTDs:
8.1.1 The top level DTD that is named appropriately and
according to its document type. For instance, an operative
report DTD will have a top-level DTD named “operative.re-
port.dtd.”
8.1.2 The E 2182/E 2183 base DTD includes the ASTM
modularization of XHTML. The inclusion of the ASTM
XHTML DTD allows the top level DTD to include XHTML
elements within the header and body elements. For instance, a
section element such as <guideline.title> may make use of the
XHTML heading elements such as <h1> and <h2> or other
format elements such as bold <b> and italic <i>.
8.1.3 When appropriate, the clinical header defined as a
non-mandatory part of this guide may be used.
8.1.4 The sections of the body of the E 2183 document are
then assigned as appropriate for the document type.
8.1.5 For example, the E 2182 Clinical XML DTDs for
Healthcare have been designed according to E 2183.
9. Precision and Bias
9.1 Precision to the DTD architecture is determined by
XML validating parsers and conformance to this guide.
9.2 The DTDs have been tested against several validators.
An online XML document validator produced by the Brown
University Scholarly Technology Group (STG) is available at
the URL: http://www.stg.brown.edu/service/xmlvalid/.
9.3 Other online validators include:
9.3.1 Language Technology Group at University of Edin-
burgh: http://www.ltg.ed.ac.uk/~richard/xml-check.html.
9.3.2 The W3C web validator: http://validator.w3.org.
9.4 In order to facilitate such online testing, the DTDs and
sample documents have been placed in the directory http://
 E 2183 – 02
www.openhealth.org/ASTM/; for example, operative.repor-
t.example.xml. This directory will contain links software
demonstrating use of the E 2183 DTDs and Schemata as they
are developed.
9.5 There is a good deal of inconsistency in parsing and
validating against the W3C XHTML Basic 1.0 recommenda-
tion. In particular XML Authority 2.0 reports many warnings
as errors (for example, undefined elements). Many warnings
are generated from the XHTML Basic DTDs, for example,
regarding DTD defaulted namespace declarations. These are
correctly warnings not errors and do not affect document
validity.
9.6 Furthermore, Microsoft’s IE5 frequently hangs when
attempting to parse XML files with external DTD subsets. The
solution is to remove the <!DOCTYPE> declaration when
browsing XML files using IE5 and use the MSXML as a
non-validating parser. For this reason compliant documents
must not depend on DTD attribute defaulting and must
explicitly include attribute values for #FIXED attributes.
10. Keywords
10.1 architecture; DTD; health care; healthcare;
namespaces; XHTML; XLink; XML; XPointer

ANNEX

(Mandatory Information)

A1. E 2183 ARCHITECTURE DTDS

A1.1 Modularization of XHTML BASIC

<!-- file: astm-xhtml.dtd -->

<!-- This is the driver file for version 1.0 of the ASTM XHTML 1.0
DTD as an extension of XHTML Basic 1.0.

This DTD is identified by the PUBLIC and SYSTEM identifiers:

PUBLIC: 9-//ASTM//DTD XHTML ASTM 1.0//EN9

SYSTEM: 9http://www.openhealth.org/ASTM/astm-xhtml.dtd9
-->

<!-- ASTM XHTML Basic 1.0 DTD

This DTD is derived from the W3C XHTML Basic Driver DTD:

This is XHTML Basic, a proper subset of XHTML.

The Extensible HyperText Markup Language (XHTML)

Copyright 1998-2000 World Wide Web Consortium
(Massachusetts Institute of Technology, Institut National de
Recherche en Informatique et en Automatique, Keio
University).
All Rights Reserved.

Permission to use, copy, modify and distribute the XHTML

Basic DTD and its accompanying documentation for any
purpose and without fee is hereby granted in perpetuity,
provided that the above copyright notice and this paragraph
appear in all copies. The copyright holders make no
representation about the suitability of the DTD for
any purpose.

It is provided 9as is9 without expressed or implied warranty.

Editors: Murray M. Altheim <mailto:altheim@eng.sun.com>

Peter Stark <mailto:Peter.Stark@ecs.ericsson.se>
Revision: $Id: xhtml-basic10.dtd,v 2.13 2000/12/18 12:56:23
mimasa
Exp $ SMI

-->

<!ENTITY % XHTML.version 9-//ASTM//DTD XHTML ASTM 1.0//EN9

>

<!-- Use this URI to identify the default namespace:

9http://www.w3.org/1999/xhtml9

7
 E 2183 – 02

See the Qualified Names module for information

on the use of namespace prefixes in the DTD.
-->
<!ENTITY % NS.prefixed 9IGNORE9 >
<!ENTITY % XHTML.prefix 9 9 >

<!ENTITY % XLINK.prefix 9xlink9>

<!ENTITY % XLINK.prefixed 9INCLUDE9>
<!-- Reserved for use with the XLink Namespace:
-->
<!ENTITY % XLINK.xmlns 9http://www.w3.org/1999/xlink9 >
<!--
don’t declare this because then it gets declared inCommon.attrib
rather put directly on the resource element (see below)
-->
<!ENTITY % XLINK.xmlns.attrib 9 9 >

<!-- For example, if you are using XHTML Basic 1.0 directly, use
the FPI in the DOCTYPE declaration, with the xmlns attribute
on the document element to identify the default namespace:

<?xml version=91.09?>
<!DOCTYPE html PUBLIC 9-//W3C//DTD XHTML Basic 1.0//
EN9
9http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd9 >
<html xmlns=9http://www.w3.org/1999/xhtml9
xml:lang=9en9>
...
</html>
-->

<!-- reserved for future use with document profiles -->

<!ENTITY % XHTML.profile 9 9 >

<!-- Bidirectional Text features

This feature-test entity is used to declare elements
and attributes used for bidirectional text support.
-->
<!ENTITY % XHTML.bidi 9IGNORE9 >

<?doc type=9doctype9 role=9title9 {ASTM XHTML Basic 1.0 } ?>

<!-- don’t include forms stuff -->
<!ENTITY % xhtml-form.module 9IGNORE9 >
<!ENTITY % xhtml-link.module 9IGNORE9 >
<!ENTITY % xhtml-meta.module 9IGNORE9 >
<!-- no need for html, head stuff-->
<!ENTITY % xhtml-struct.mod
PUBLIC 9-//W3C//ELEMENTS XHTML Document Structure
1.0// EN9
99>
%xhtml-struct.mod;-->
<!ENTITY % title.element 9IGNORE9>
<!ENTITY % title.attlist 9IGNORE9>
<!ENTITY % head.element 9IGNORE9>
<!ENTITY % head.attlist 9IGNORE9>
<!ENTITY % body.element 9IGNORE9>
<!ENTITY % body.attlist 9IGNORE9>
<!ENTITY % html.element 9IGNORE9>
<!ENTITY % html.attlist 9IGNORE9>
<!--
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
-->

<!ENTITY % xhtml-events.module 9IGNORE9 >

<!-- jb: XML names doesn’t like PIs with colons e.g.

<?IS10744:arch xhtml

so default this out

-->
<!ENTITY % xhtml-arch.module 9IGNORE9 >
<!ENTITY % xhtml-bdo.module 9%XHTML.bidi;9 >

<!ENTITY % xhtml-basic10-module.dtd
PUBLIC 9-//W3C//DTD XHTML Basic 1.0//EN9

9http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd9>

8
 E 2183 – 02
%xhtml-basic10-module.dtd;

<!-- end of ASTM XHTML Basic 1.0 DTD

........................................... -->

A1.2 ASTM Base DTD

<!--
PUBLIC 9-//ASTM//DTD E 2182 Base 1.0//EN9
SYSTEM 9http://www.openhealth.org/ASTM/ASTM.E 2182.dtd9
-->

<!-- default: don’t prefix elements -->

<!ENTITY % NS.prefixed 9IGNORE9>
<!-- prefix xlink attributes -->
<!ENTITY % XLINK.namespace.prefixed 9INCLUDE9>

<!-- include ASTM XHTML Basic Module -->

<!ENTITY % ASTM-XHTML-module.dtd PUBLIC 9-//ASTM//DTD
ASTM XHTML 1.0//EN9
9astm-xhtml.dtd9>
%ASTM-XHTML-module.dtd;
<!-- define %astm.content as text or XHTML -->
<!ENTITY % ASTM.Mix 9%Flow.mix;9>
<!ENTITY % astm.content 9(#PCDATA | %ASTM.Mix;)*9>

<!ENTITY % ASTM.xlink-module.mod PUBLIC 9-//ASTM//ENTITIES

XLink 1.0//EN9 9astm-xlink.mod9>
%ASTM.xlink-module.mod;
<!-- end xlink-module -->
<!-- clinical header attributes -->
<!ENTITY % ch.attrib 9
ID ID #IMPLIED
confidentiality IDREF #IMPLIED
note CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED
9>
<!-- include clinical header module -->
<!ENTITY % ASTM.clinical.header.dtd PUBLIC 9-//ASTM//DTD
Clinical Header 1.0//EN9 9clinical.header.dtd9>
%ASTM.clinical.header.dtd;

<!ENTITY % astm.content.attrib 9%ch.attrib; %xlink.attrib;9>

<!ENTITY % astm.document.attrib 9
xml:base CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED

%xlink.namespace.attrib;
9>

A1.3 ASTM XLink Module

<!--
The content of ASTM Healthcare documents may include XLinks
PUBLIC //ASTM//ENTITIES Xlink 1.0//EN9
SYSTEM 9http://www.openhealth.org/ASTM/astm-xlink.mod9
-->
<!ENTITY % xlink.namespace.uri 9’http://www.w3.org/1999/xlink’9>

<!ENTITY % no.namespace.support 9IGNORE9>

<!ENTITY % XLINK.namespace.prefixed 9INCLUDE9>

<![ %no.namespace.support; [
<!ENTITY % xlink.namespace.attrib 99>
]]>

<!ENTITY % xlink.namespace.attrib 9xmlns:xlink CDATA #FIXED

’http://www.w3.org/1999/xlink’9>

<![ %XLINK.namespace.prefixed; [
<!ENTITY % XLINK.pfx 9xlink:9>
<!ENTITY % XLINK.sfx 9:xlink9>
<!ENTITY % xlink.type.qname 9xlink:type9>

9
 E 2183 – 02
<!ENTITY % xlink.arcrole.qname 9xlink:arcrole9>
<!ENTITY % xlink.href.qname 9xlink:href9>

<!ENTITY % xlink.attrib 9
xlink:type (simple|extended|locator|arc|resource|title) #IMPLIED
xlink:arcrole CDATA #IMPLIED
xlink:href CDATA #IMPLIED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
9>
<!ENTITY % xlink.simple.attrib 9
xlink:type (simple|extended) 9simple9
xlink:arcrole CDATA #IMPLIED
xlink:href CDATA #IMPLIED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
’>
<!ENTITY % xlink.extended.attrib ’
xlink:from CDATA #IMPLIED
xlink:to CDATA #IMPLIED
xlink:label CDATA #IMPLIED
’>
]]>

<!ENTITY % XLINK.pfx 99>

<!ENTITY % XLINK.sfx 99>

<!ENTITY % xlink.type.qname 9type9>

<!ENTITY % xlink.arcrole.qname 9arcrole9>
<!ENTITY % xlink.href.qname 9href9>

<!ENTITY % xlink.attrib 9
type (simple|extended) #IMPLIED
arcrole CDATA #IMPLIED
href CDATA #IMPLIED
9>
<!ENTITY % xlink.simple.attrib ’
type (simple|extended) 9simple9
arcrole CDATA #IMPLIED
href CDATA #IMPLIED
’>

APPENDIX

(Nonmandatory Information)

X1. CLINICAL HEADER

X1.1 Clinical Header

<!--
PUBLIC 9-//ASTM//DTD Clinical Header 1.0//EN9
SYSTEM 9http://www.openhealth.org/ASTM/clinical.header.dtd

This DTD defines an ASTM E 2182 Clinical Document Header,

this DTD is included by the Base ASTM DTD.
-->

<!ENTITY % NS.prefixed 9IGNORE9>

<!ENTITY % CH.prefixed 9%NS.prefixed;9>

<!ENTITY % astm-xlink.mod
PUBLIC 9-//ASTM//ENTITIES XLink 1.0//EN9
9astm-xlink.mod9>
%astm-xlink.mod;
<!ENTITY % ch.namespace.uri 9’http://www.openhealth.org/ASTM/
clinical.header’9>
<!ENTITY % ch 9ch9>

<![ %CH.prefixed; [
<!ENTITY % ch.prefix 9%ch;:9>

10
 E 2183 – 02
<!ENTITY % ch.namespace.attrib 9
xmlns:%ch; CDATA #FIXED ’http://www.openhealth.org/ASTM/
clinical.header’
9>
]]>

<!ENTITY % ch.prefix 99>

<!ENTITY % ch.namespace.attrib 9
xmlns CDATA #FIXED
’http://www.openhealth.org/ASTM/clinical.header’
9>

<!ENTITY % ch.attrib 9
ID ID #IMPLIED
confidentiality IDREF #IMPLIED
note CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED
9>
<!--<!ENTITY % ch.xmlns.attrib.name 9xmlns:%ch;9>-->
<!ENTITY % ch-qname.mod
PUBLIC 9–//ASTM//ENTITIES Clinical Header QName
Module 1.0//EN9
9clinical.header-qname-1.mod9>
%ch-qname.mod;

<!ENTITY % ch.person.type
9%person.name.qname;,(%id.qname;)*,(%addr.qname;)*9>
<!ENTITY % ch.organization.type
9(%organization.name.qname;)?,(%id.qname;)*,(%addr.qname;)*9>
<!ENTITY % ch.actor.type
9%ch.person.type;,(%type.code.qname;)?,(%date.time.qname;)?9>
<!ENTITY % ch.authenticator.type
9%ch.actor.type;,(%signature.qname;)?9>

<!ENTITY % ch.datetime.model 9(#PCDATA)9>

<!ENTITY % coded.value.model 9(#PCDATA)9>
<!ENTITY % coded.value.attrib.list 9
code.system NMTOKEN #IMPLIED
code.system.name CDATA #IMPLIED
version NMTOKEN #IMPLIED
9>
<!ENTITY % clinical.header.model 9(
(%id.qname;)*,
(%version.number.qname;)?,
(%confidentiality.code.qname;)*,
(%patient.encounter.qname;)?,
(%authenticator.qname;)*,
(%legal.authenticator.qname;)*,
(%intended.recipient.qname;)*,
(%originator.qname;)?,
(%originating.organization.qname;)?,
(%transcriptionist.qname;)?,
(%provider.qname;)+,
(%service.actor.qname;)*,
%patient.qname;,
(%events.qname;)?,
(%codes.qname;)?,
(%related.document.qname;)*
)9>

<!ENTITY % text.model 9(#PCDATA)9>

<!ENTITY %
id.attrib 9%ch.attrib;
root CDATA #IMPLIED
authority CDATA #IMPLIED
type CDATA #IMPLIED
valid.time CDATA #IMPLIED
9>
<!ENTITY % patient.encounter.model 9(
(%id.qname;)?,
(%practice.setting.qname;)?,
(%date.time.qname;)?,
(%location.qname;)?
)9>
<!ENTITY % patient.encounter.attrib 9%ch.attrib;9>

11
 E 2183 – 02
<!ENTITY % service.actor.model 9(
(%person.name.qname;|%organization.name.qname;),
(%id.qname;)*,
(%addr.qname;)*,
(%type.code.qname;)?,
(%function.qname;)?,
(%date.time.qname;)?
)9>
<!ENTITY % provider.model
9(%ch.actor.type;,(%function.qname;)?)9>
<!ENTITY % service.target.model 9(
%ch.actor.type;,
(%birth.date.qname;)?,
(%gender.qname;)?
)9>
<!ENTITY % events.model 9(%event.qname;)*9>
<!ENTITY % event.model
9(%event.name.qname;,%date.time.qname;,(%staff.qname;)?,(%comments.qname;)?)9
>
<!ENTITY % person.name.model 9(
%family.qname;|
%given.qname;|
%middle.qname;|
%prefix.qname;|
%suffix.qname;|
%delimiter.qname;
)*
9>
<!ENTITY % addr.model 9(
%country.qname;|
%city.qname;|
%state.qname;|
%street.qname;|
%zip.qname;|
%house.number.qname;|
%direction.qname;|
%post.office.box.qname;|
%telephone.qname;|
%uri.qname;|
%delimiter.qname;
)*9
>

<!ELEMENT %clinical.header.qname; %clinical.header.model;>

<!ATTLIST %clinical.header.qname;
%ch.attrib;
%ch.namespace.attrib;
>
<!-- id -->
<!ELEMENT %id.qname; %text.model;>
<!ATTLIST %id.qname; %id.attribs; %xlink.attrib;>
<!ELEMENT %version.number.qname; %text.model;>
<!ATTLIST %version.number.qname; %ch.attrib;>

<!ELEMENT %confidentiality.code.qname; %coded.value.model;>

<!ATTLIST %confidentiality.code.qname; %ch.attrib;
%coded.value.attrib.list;>
<!ELEMENT %patient.encounter.qname;
%patient.encounter.model;>
<!ATTLIST %patient.encounter.qname; %patient.encounter.attrib;>
<!-- service actors -->
<!ELEMENT %authenticator.qname; (%ch.authenticator.type;)>
<!ATTLIST %authenticator.qname; %ch.attrib;>
<!ELEMENT %legal.authenticator.qname;
(%ch.authenticator.type;)>
<!ATTLIST %legal.authenticator.qname; %ch.attrib;>
<!ELEMENT %originator.qname; (%ch.actor.type;)>
<!ATTLIST %originator.qname; %ch.attrib;>
<!ELEMENT %intended.recipient.qname; (%ch.actor.type;)>
<!ATTLIST %intended.recipient.qname; %ch.attrib;>
<!ELEMENT %transcriptionist.qname; (%ch.actor.type;)>
<!ATTLIST %transcriptionist.qname; %ch.attrib;>
<!ELEMENT %provider.qname; %provider.model;>
<!ATTLIST %provider.qname; %ch.attrib;>
<!ELEMENT %service.actor.qname; %service.actor.model;>
<!ATTLIST %service.actor.qname; %ch.attrib; %xlink.attrib;>
<!-- service targets -->
<!ELEMENT %patient.qname; %service.target.model;>

12
 E 2183 – 02
<!ATTLIST %patient.qname; %ch.attrib; %xlink.attrib;>
<!ELEMENT %events.qname; %events.model;>
<!ATTLIST %events.qname; %ch.attrib;>
<!ELEMENT %codes.qname; (%coded.value.qname;)*>
<!ATTLIST %codes.qname; %ch.attrib;>
<!ELEMENT %related.document.qname; ANY>
<!ATTLIST %related.document.qname; %xlink.simple.attrib;>

<!ELEMENT %practice.setting.qname; %text.model;>

<!ATTLIST %practice.setting.qname; %ch.attrib;>
<!ELEMENT %date.time.qname; %ch.datetime.model;>
<!ATTLIST %date.time.qname; %ch.attrib;>
<!ELEMENT %location.qname; %text.model;>
<!ATTLIST %location.qname; %ch.attrib;>

<!ELEMENT %event.qname; %event.model;>

<!ATTLIST %event.qname; %ch.attrib;>
<!ELEMENT %event.name.qname; %text.model;>
<!ATTLIST %event.name.qname; %ch.attrib;>
<!ELEMENT %staff.qname; (%ch.person.type;)>
<!ATTLIST %staff.qname; %ch.attrib;>
<!ELEMENT %comments.qname; %text.model;>
<!ATTLIST %comments.qname; %ch.attrib;>
<!--
person.name
-->
<!ELEMENT %person.name.qname; %person.name.model;>
<!ATTLIST %person.name.qname;
%ch.attrib;
type CDATA #IMPLIED>
<!ELEMENT %family.qname; %text.model;>
<!ATTLIST %family.qname; %ch.attrib; type CDATA #IMPLIED>
<!ELEMENT %given.qname; %text.model;>
<!ATTLIST %given.qname; %ch.attrib; type CDATA #IMPLIED>
<!ELEMENT %middle.qname; %text.model;>
<!ATTLIST %middle.qname; %ch.attrib; type CDATA #IMPLIED>
<!ELEMENT %prefix.qname; %text.model;>
<!ATTLIST %prefix.qname;
%ch.attrib; type CDATA #IMPLIED>
<!ELEMENT %suffix.qname; %text.model;>
<!ATTLIST %suffix.qname;
%ch.attrib; type CDATA #IMPLIED>
<!ELEMENT %delimiter.qname; %text.model;>
<!ATTLIST %delimiter.qname;
%ch.attrib; type CDATA #IMPLIED>
<!-- organization -->
<!ELEMENT %organization.name.qname; %text.model;>
<!ATTLIST %organization.name.qname; %ch.attrib;>
<!--
addr
-->
<!ELEMENT %addr.qname; %addr.model;>
<!ATTLIST %addr.qname; %ch.attrib;
type CDATA #IMPLIED>
<!--
elements required for addr
-->
<!ELEMENT %country.qname; %text.model;>
<!ATTLIST %country.qname; %ch.attrib;
type CDATA #IMPLIED>
<!ELEMENT %city.qname; %text.model;>
<!ATTLIST %city.qname; %ch.attrib;
type CDATA #IMPLIED>
<!ELEMENT %state.qname; %text.model;>
<!ATTLIST %state.qname; %ch.attrib;
type CDATA #IMPLIED>
<!ELEMENT %zip.qname; %text.model;>
<!ATTLIST %zip.qname; %ch.attrib;
type CDATA #IMPLIED>
<!ELEMENT %street.qname; %text.model;>
<!ATTLIST %street.qname; %ch.attrib;
type CDATA #IMPLIED>
<!ELEMENT %house.number.qname; %text.model;>
<!ATTLIST %house.number.qname; %ch.attrib;
type CDATA #IMPLIED>
<!ELEMENT %direction.qname; %text.model;>
<!ATTLIST %direction.qname; %ch.attrib;
type CDATA #IMPLIED>

13
 E 2183 – 02
<!ELEMENT %address.locator.qname; %text.model;>
<!ATTLIST %address.locator.qname; %ch.attrib;
type CDATA #IMPLIED>
<!ELEMENT %post.office.box.qname; %text.model;>
<!ATTLIST %post.office.box.qname; %ch.attrib;
type CDATA #IMPLIED>
<!--
allows
<uri type=9email9>jonathan@openhealth.org</uri>
<uri type=9homepage9>http://www.openhealth.org</uri>

alternatively
<uri type=9home9>mailto:jonathan@openhealth.org</uri>
<uri type=9work9>mailto:jborden@lifespan.org</uri>
-->
<!ELEMENT %uri.qname; %text.model;>
<!ATTLIST %uri.qname; %ch.attrib;
type CDATA #IMPLIED>
<!ELEMENT %telephone.qname; %text.model;>
<!ATTLIST %telephone.qname; %ch.attrib;
type CDATA #IMPLIED>

<!ELEMENT %coded.value.qname; %coded.value.model;>

<!ATTLIST %coded.value.qname; %ch.attrib;
%coded.value.attrib.list; %xlink.attrib;>

<!ELEMENT %signature.qname; %coded.value.model;>

<!ATTLIST %signature.qname; %ch.attrib;
%coded.value.attrib.list;>

<!ELEMENT %type.code.qname; %coded.value.model;>

<!ATTLIST %type.code.qname; %ch.attrib;
%coded.value.attrib.list;
%xlink.attrib;>
<!ELEMENT %function.qname; %coded.value.model;>
<!ATTLIST %function.qname; %ch.attrib; %coded.value.attrib.list;
%xlink.attrib;>

<!ELEMENT %birth.date.qname; %ch.datetime.model;>

<!ATTLIST %birth.date.qname; %ch.attrib;>
<!ELEMENT %gender.qname; %text.model;>
<!ATTLIST %gender.qname; %ch.attrib;>

<!ELEMENT %originating.organization.qname;
(%ch.organization.type;)>
<!ATTLIST %originating.organization.qname; %ch.attrib;>

ASTM International takes no position respecting the validity of any patent rights asserted in connection with any item mentioned
in this standard. Users of this standard are expressly advised that determination of the validity of any such patent rights, and the risk
of infringement of such rights, are entirely their own responsibility.

This standard is subject to revision at any time by the responsible technical committee and must be reviewed every five years and
if not revised, either reapproved or withdrawn. Your comments are invited either for revision of this standard or for additional standards
and should be addressed to ASTM International Headquarters. Your comments will receive careful consideration at a meeting of the
responsible technical committee, which you may attend. If you feel that your comments have not received a fair hearing you should
make your views known to the ASTM Committee on Standards, at the address shown below.

This standard is copyrighted by ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959,
United States. Individual reprints (single or multiple copies) of this standard may be obtained by contacting ASTM at the above
address or at 610-832-9585 (phone), 610-832-9555 (fax), or service@astm.org (e-mail); or through the ASTM website
(www.astm.org).

14