6. Steps Toward a
Universal Patient Record

6.1 Project Context: Vision--Anticipating the Future

Vision is "anticipating the future". Vision is required when an organization plans any project that takes a long time to complete. And vision is especially needed when management needs to evaluate and compare many different projects, selecting those that, together, would best benefit the organization in the future. See figure 6.1.

Because a large-scale complex project, such as the automated patient medical record system, takes a long time to complete, vision, anticipating the future, is required. Vision is required to identify at the beginning of the project business requirements that apply at the end of the project; otherwise, the products of the project could be obsolete by the time the project is complete.

But any single project cannot be viewed in isolation. Management must also look beyond a single project and look at all of its projects. It must pick the best mix of projects to meet the future needs of the organization. It must predict how all its projects will work together to change the organization—this may be especially difficult when projects are completed at different times and when projects depend upon each other for information or interact in other ways.

It is very difficult for any individual or organization to have vision—Predicting the future entails a significant risk that the predicator is wrong. There are, however, two ways for an organization to have some control over the future:

· Firstly, management can guide the organization to follow a particular direction.

· Secondly, management can see that members of the organization have an influence over standards created by standard organizations that benefit the organization. This is especially important when a project will extend beyond the organization and include other organizations in the same industry—in the case of an automated patient medical record system, the healthcare industry.

Even using these ways to “control the future”, there is significant risks of wrong decisions being made. Such risks can be ameliorated by risk management. See section 16.5.

One vision, a prediction of the author of this book, is that there will be a universal patient record. A large healthcare organization that develops an automated patient medical record system could have a significant influence over standards for such a universal patient record, insuring that the universal patient record is compatible with the needs of the healthcare organization and compatible with its automated patient medical record system.

6.2 Assumed Attributes of a Universal Patient Record

The following are assumed attributes of a universal patient record:

1. To allow communication between differing healthcare institutions, the universal patient record must have a commonality of information.

2. However, to support the different needs of healthcare organizations, the universal patient medical record must also allow for a diversity of formats for medical record documentation.

3. The universal patient record must use agreed-upon healthcare industry data standards.

4. The universal patient record may be stored anywhere and retrievable from anywhere and thus requires a common secure network shared by healthcare organizations.

5. The universal patient record must be able to employ security measures to control the visibility and availability of information. Authorized parties can request permission to copy source documents, and the owner or creator of a source document can grant permission to an authorized party to copy the document, perhaps with certain categories of permissions granted by policy.

6. The universal patient record must be able to accommodate information in any language that care is given in.

7. The universal patient record must be judiciously introduced so that it is used in situations where a caregiver can have confidence that, for a particular patient, the patient record is complete or largely complete; for example, until the universal patient record becomes widely used, its use is better suited for a large HMO that can enforce its use throughout the HMO and where there are few member visits outside the HMO.

Based upon these assumed attributes, this section surmises what a future universal patient record would look like and describes how it could be incorporated into an automated patient medical record system.

Paper patient medical records currently differ from one healthcare organization to another. To create a common automated record, healthcare organizations must first agree upon common standards for the patient medical record.

A “Computer-based Patient Record” (CPR) repository that can be used by many healthcare and other organizations should be developed to store patient chart information in a format using national or international data standards. An example of such a format is the ASTM (American Society for Testing and Materials) E 1384 standard for content and structure of automated patient health records [1]. Such a CPR repository would not contain all the information in a patient’s chart, but a significant summary of this information. The ASTM E 1384 standard, for example, includes patient identification information, a patient problem list, patient practitioners, patient encounters (i.e., inpatient stays, outpatient visits, Emergency Department visits, etc.), services (including medications, diagnostic tests, immunizations, procedures and therapies), assessments/exams, and care plans.

At each healthcare organization, there would be more detailed documents than in the CPR, which I will refer to as “source documents”. Such source documents are those discussed in section 4.4.3. These documents are likely to differ in format and structure, and even in kind, from one healthcare organization to another. At least one information organization, Pacific Bell in California, has attempted to set up a data base for storage of these source documents—in Pacific Bell’s case, this is storage of diagnostic images for all Northern California healthcare organizations [2].

In addition to storing summary clinic information on patients in CPR repositories, I predict that many healthcare organizations will eventually choose to store their source documents externally from the healthcare organization, as they could save money on chart room space, chart room personnel and couriers and, more importantly, they could instantaneously transmit the source documents to wherever they are needed rather than have them physically transferred.

Such source documents would then either be electronically stored outside the healthcare organization in a “source document repository”, within the healthcare organization in a source document repository, or still be stored on paper and be in a chart room. In order to associate source documents with encounters, whether the source documents are electronically stored or on paper, I propose that each patient encounter identified in a CPR repository include the storage locations of all the source documents generated during the encounter. See figure 6.2. (The E 1384 standard currently provides for storage of one location.)

From this information in the CPR repository and source document information, each healthcare organization could display a summary of clinical information for the patient with drill down to more detailed CPR and source document information. This summary, which I refer to as a “Patient Clinical Summary”, would include patient description information, a list of encounters, significant health problems, medications, orders, etc. See figure 6.3. More detailed patient clinical information could be available by selecting and “drill down” to this information and to source documents.

A CPR repository or source document repository could exist within a healthcare organization, as part of a regional, national or international database, or within a private organization, such as Pacific Bell.

This book views a patient’s universal patient record as the total of clinical information for a patient available within CPR repositories, source document repositories and on paper in chart rooms. In order to produce the universal patient record information needed by the CPR and source document repositories, a healthcare organization needs to do the following during an encounter:

· as source documents are being created (e.g., H&P, vital signs documents, orders, Progress Notes), summary information would be generated for the CPR repository

· source documents that are electronically stored would be archived to a source document repository, or included in the patient chart

· after an encounter, the summary information would be sent to the CPR repository along with the location of the source documents.

6.3 Possible Evolution of a Universal Patient Record

Automation of the patient medical record is likely to occur first in the most organized and automated of healthcare organizations, large HMOs, like the one for our example project. If these ideas for a universal patient record, consisting of CPR repositories and source document repositories, are followed, the likely way the universal patient record would evolve is as follows:

Initially, an HMO and alliance healthcare organizations, or different regions of an HMO, will band together to set up a CPR repository, so they could share patient medical record information. The HMO might also start to store source documents electronically in a source document repository to save on costs of its chart rooms. See figure 6.2.

In such a setup, an HMO or HMO region would know about the encounters in its own organization or region, so what the HMO or region would want to be informed about are encounters outside the HMO or HMO region for HMO patients. See figure 6.4. The CPR repository might be set up to inform the HMO when any such outside encounter occurs, or when there is a change in CPR encounter information for such patients. The HMO could then pick up the new CPR information and may choose to also pick up any associated source document information in the source document repository or alternatively order source documents from chart rooms (e.g., paper chart documents stored physically in the outside organization). Also, whenever there is a new HMO member or whenever there is a non-member visiting the HMO, the HMO might query the CPR repository for any outside organization CPR information and pick up that CPR information and any associated source documents for that patient. (The alliance organizations or other HMO regions could follow the same procedures to get encounter information for its members and patients.)

Over time, further healthcare organizations might want their own CPR repositories and source document repositories, possibly shared with other healthcare organizations. A healthcare organization might then want to receive any encounters for a patient of interest from these other outside healthcare organizations.

A likely possibility at this stage would be that third party organizations would set up CPR repositories or source document repositories. Such a third party organization could charge a fee per transaction, operating as an Application Service Provider (ASP), where “an application service provider (ASP) is a company that offers individuals or enterprises access over the Internet to application and related services that would otherwise have to be located in their own personal or enterprise computers. Sometimes referred to as "apps-on-tap," ASP services are expected to become an important alternative, especially for smaller companies with low budgets for information technology . . . on a rental, pay-as-you-use basis” [3]. Other ASPs could provide healthcare organizations with automated patient medical record systems that could store information on a CPR repository and source document repository for healthcare organizations.

Eventually, with greater use of source document repositories by healthcare organizations, the source document repository organization could take over the responsibility to update the CPR repository information from source document information, sending the CPR repository only information to be stored in the CPR repository and no other. The healthcare organization would then no longer have to send information directly to the CPR repository.

In order to link up all the CPR repositories, a patient registry could be set up identifying all patients in the CPR repositories and identify the (subscribing) healthcare and other organizations, such as insurance companies, who were interested in each patient. See figure 6.5. Whenever a patient encounter was identified within a CPR repository, or CPR encounter information changed, then the patient registry would be informed by the CPR repository. The patient registry could then in turn inform any (subscribing) healthcare organization (or an insurance company) that had an interest in that patient of the encounter and send it the location of the CPR information for that encounter. An organization that was informed of the new encounter information could then optionally pick up the patient encounter information from its own CPR repository (for an alliance organization or HMO region) via a high bandwidth connection; or could pick up the patient encounter information from any other CPR repository (a non-aligned organization) perhaps via a lower bandwidth, say an Internet-like, TCP/IP, connection. Source documents could optionally be ordered or electronically requested from the outside healthcare organization or from a source document repository.

For each new HMO or healthcare organization member and for each visit by a non-HMO member, the healthcare organization could query the patient registry and find all the CPR repository locations where the patient had encounter information. The healthcare organization could then go to each of the CPR repositories to pick up this CPR information and pickup or order associated information from each of the source document locations.

By these procedures, healthcare organizations would have a complete universal patient record for every patient of interest to them (every HMO patient and patient visiting the HMO). The approach is scalable, in that more CPR repositories could be connected to a patient registry, and CPR and source document repositories could be combined or partitioned. Changes in CPR and source document repositories structures may be required due to changing healthcare organization alliances or management reorganizations or to take advantage of lower cost or higher speed networks.

This approach would minimize network communication in that a healthcare organization would only be informed (by the patient registry) of member visits that occurred outside the healthcare organization; the healthcare organization would already have all information on visits inside the healthcare organization. This approach would minimize network communication in that what would be kept in the CPR repository would be a detailed summary of patient encounters; a healthcare organization would only retrieve the source documents if they were needed.

Some periodic synchronization (auditing) of CPR repository information with clinical information may have to be done to verify that information was up-to-date and consistent in all databases.

6.4 Required Changes Within a Healthcare Organization

In order to (1) provide information for a universal patient record and (2) make use of this information to improve patient care, a healthcare organization must automate the patient medical record within its organization. Automation of the patient medical record within the healthcare organization along with creation of a complete, automated, universal patient record would enable caregivers to get a more complete picture of a patient’s health and of the patient’s present and past care.

The basic parts of an automated patient medical record system within a healthcare organization, as presented in the previous chapter in figure 5.9, are (1) a part to display the universal patient record, including Clinical Summaries and source documents, (2) a part to enable caregivers to document all aspects of patient care, e.g., producing source documents, and (3) a part to enable caregivers to order medications, clinical lab tests, paper charts, appointments, etc. and to receive results back from the clinical systems within the healthcare organization.

During the documentation step and order/results steps, information for the CPR repository would be created. After an encounter, this CPR information would be sent to the CPR repository. Documents (including orders and results of orders) would be sent out to a source document repository if there was one, with the locations of these source documents sent to the CPR repository. Clinical information would be organized by encounter in both the CPR repository and source document repository.

In order to organize clinical information by encounter, information on encounters and when they begin and end must be received by the automated patient medical record system from healthcare organization encounter systems, including ADT (for hospital admissions, discharges and transfers), the outpatient registration system, and the appointment system.

Order and result information must also be organized by encounter. The automated patient medical record system would send orders to other healthcare organization clinical systems that handle these orders—including the pharmacy system for medications, the clinical laboratory system for clinical laboratory orders, the radiology system for x-ray and other diagnostic imaging orders—and save each order, associating it with the encounter. Results of orders could be received back from the clinical systems and stored within the automated patient medical record system with the order, and thus also would be organized by encounter. This automation of the patient medical record, besides organizing patient clinical information by encounter for a universal patient record, would also result in the organization of all patient clinical information within the healthcare organization by encounter, whether the information was part of the universal patient record or not.

Automation of the patient medical record in the healthcare organization, would have the additional benefit that it would tie together all healthcare organization clinical systems, including encounter systems and systems through which orders could be made and results received. As a result, patient clinical information would no longer need to be redundantly entered in these systems. Orders could be accomplished electronically instead of on paper; and results would be received back electronically and thus more quickly. A list of patient encounters could be created electronically for each caregiver, inpatient unit, and the emergency department to guide caregiver work flow.

To maximize the benefits of tying together all these healthcare organization clinical systems, it is recommended that each organization clinical system, where feasible, communicate with the automated patient medical record system using the standard healthcare applications level network protocol, HL7 [4]. This (theoretically) would enable a healthcare organization clinical system (e.g., a clinical laboratory system) to be replaced with an improved equivalent clinical system that used the same communications protocol without changing the existing interface between the existing clinical system and automated patient medical record system; this would also enable a large healthcare organization with different clinical systems at different geographic locations to standardize on the “best-of-breed” of each type of clinical system by substituting one clinical system for another of the same type.

The existence of a universal patient record through the CPR repository, source document repositories and patient registry would enable the healthcare organization to get a complete view of care of the patient in all the healthcare organizations where the patient was seen. As a result of the CPR repositories, a patient Clinical Summary could be available that would show all patient encounters, medications, clinical laboratory tests, etc. Detailed information on each encounter would be available by drill down. An example of such a Clinical Summary appears in figure 6.3.

The location of any source document could be identified through the CPR repository, whether on paper or electronically stored; the source document could then be retrieved from source document repositories or electronically ordered, whether the source document was located within or outside the healthcare organization.

6.5 A Universal Patient Record in Context

How would a universal patient record affect patient care? Let’s consider the universal patient record from several points of view:

a) the patient

b) society as a whole

c) an HMO, where automation of the patient medical record is likely to occur first.

6.5.1 Effect On Patients

What are the benefits of a universal patient record from a patient’s point of view?

Wherever the patient goes for health care he will have a complete, rather than partial, history of his health problems and past medical care. For example, if the patient shows up in an Emergency Department, then the patient will have a complete chart and medical history immediately available. Any delays in treatment due to the need to record previous patient medical problems, allergies, patient family history, advance directives, can be avoided. As seen by figure 4.8, a complete chart may not otherwise be available even if the patient’s medical care was in a single healthcare organization.

Another way a universal patient record would improve care for a patient is that communications between the caregiver and patient would be improved. During any phone call with a patient, a caregiver would now always have the patient’s medical record. The caregiver would not have to wait until the patient’s medical record is ordered.

An always-available automated patient medical record would also improve caregiver collaborations in the care of a patient. During a primary care physician’s consultations with a specialist or with a person from an ancillary care department, both would have the patient’s medical record, no matter where they were physically located. At the time a physician receives a consultation request from an advice nurse after a patient phone call, the physician would no longer have to order, and wait for, the patient medical record. A nurse practitioner, or a physician assistant, often consults with supervising physicians in the care of her patients; during their conversations, both could now be viewing the patient medical record whether they were in the same room or not.

Insurance and Medicare payments can be accomplished quicker so the patient would have a shorter time to worry about a medical bill being paid or not. Evaluation of injuries and illnesses for worker’s compensation payments by the federal government and states could be done quicker.

6.5.2 Effect On Society as a Whole

A universal patient record would also benefit society as a whole.

Because of the patient medical record, there would be a greater knowledge base of clinical information. As a result, care given to patients could be evaluated more easily, including better determination of best treatment guidelines and of which treatments work best. There would be better selection of patients as subjects for research, for example, patients with only the subject disease, and no other diseases, could be identified.

Epidemiological studies could be accomplished more quickly. Outbreaks of particular diseases could be recognized more quickly and more quickly controlled, within a hospital, the country, or the world.

Actual costs of medical care could be evaluated. Studies on how medicine could be made more cost-effective could more easily be done. Medical fraud could be more easily detected.

6.5.3 Effect On a Healthcare Organization

When we are looking at a universal patient record from the point of view of the patient or society, we are viewing the universal patient record mainly with respect to its humanitarian aspects. Although an HMO, or other healthcare organization, in certain aspects, is a humanitarian organization, the HMO has also been set up to survive and prosper by being better than its competition and by making money. In this sense, it is no longer just a humanitarian organization. As competitors with other healthcare organizations, why should an HMO then want to have a universal patient record that not only benefits itself but also all other healthcare organizations?

Clearly, an HMO would benefit from the universal patient record. At the very least, this would combine together the entire healthcare organization’s charts—see figure 4.8. But this could also be done by a proprietary approach decided upon solely by the HMO, potentially locking out other competitors. At first glance, agreement with other health care organizations on standards for a universal patient record seems contradictory to an HMO trying to get a competitive advantage—but let us consider further whether there would be such a competitive advantage.

Consider three typical categories of HMO patients that we used earlier in section 4.7 and the effects of a universal patient record on each: (1) patients who almost always see a single primary care physician, or alternatively a team of caregivers within the same facility, for any health problem, (2) patients who go to multiple HMO facilities but do not go outside the HMO, and (3) patients who may be seen either within the HMO or outside the HMO.

For a patient in category (1), who primarily see a single caregiver, a single patient chart in the facility of the primary care physician would probably suffice to provide adequate care. A universal patient record system may not enhance care all that much, although it would create greater organization of information in the chart and make the information easier to find, as this could be done by computerized searching or other techniques.

For a patient in category (2), who go only to HMO facilities, a universal patient record would essentially combine all the charts in figure 4.8 and make them available to all caregivers in the HMO, but also would an HMO-only automated patient medical record system, whether proprietary or not.

For patients in category (3), who go both inside and outside the HMO for care, a universal patient record would combine patient medical records of both the HMO and outside healthcare organizations. Category (3), through “point of service” plans in HMOs, is fast becoming the majority case in many HMOs. Other healthcare organizations seeing HMO patients will most certainly not be using a proprietary HMO automated patient medical record system. The best, and cheapest, hope for category (3) patients then is for the whole healthcare industry to agree upon a standard universal patient record, in particular a standard for the CPR repository, the part that would contain an agreed-upon standard summary of patient clinical information. Such CPR repository information would be accessible by all healthcare organizations. Each healthcare organization would pay for its own interfaces to CPR repositories, but each would benefit from the combined information for the patient contained in it.

Through such a universal patient record, the HMO could also track care and treatments over a number of encounters both inside and outside the HMO. Best practice models could be enforced across healthcare organizations, ensuring a continuum of care even though the patient is seen both inside and outside the HMO.

An HMO developing an automated patient medical record system is thus best off if it works with other healthcare organizations in developing standards for a universal patient record prior to automating the patient medical record, even though this approach may appear to cause the healthcare organization to lose its competitive advantage in the short run.

Further, a large HMO that first develops an automated patient medical record system using an industry agreed-upon universal patient record can have a large influence on the direction of standards for such a universal patient record, and thus can insure that the standards for it entirely fit the needs of the healthcare organization. This could provide a significant competitive advantage to the HMO.

As stated earlier, a universal patient record is not possible without automation of the patient medical record within the healthcare organizations that provide the information for the universal patient record. This book proposes that in anticipation of a universal patient record that an HMO when developing an automated patient medical record system plan for the design of a CPR repository structure to store patient clinical summary information using healthcare industry standards, for example the ASTM E 1384 standard for electronic health records. This would make the future transition to a healthcare industry-wide system easier. The next section and the next chapter propose how this could be done.

6.6 XML as a Basic Standard for Source Document Repositories and For Transfer of Information to the CPR

XML is quickly becoming a standard for electronic storage of source documents, serving as a base for other standards. For example, the E31 committee of the ASTM is studying using XML together with the E 1384 standard for electronic health care records [5]. The HL7 committee in charge of the HL7 healthcare standard for network communications between healthcare computers is studying an XML implementation of a “Clinical Document Architecture”, merging HL7 in with the XML description of medical record documents [6]. The Clinical Document Architecture, which was previously known as the Patient Record Architecture, will provide models for various types of clinical documents (e.g., discharge summaries and progress notes) so they can be transmitted between organizations.

Although a proposed CPR repository might not use XML in the storage of information, it could use the XML source documents as the source of information to be added to the CPR, translating information in H&P’s, patient consultations and other source documents to the CPR structure. The E 1384 structure of the CPR is described in the E-R diagram in figure 6.6 taken from reference [1], where E-R diagrams are described in section 13.7; this E-R diagram of the E 1384 version of the CPR is described in more detail in section 6.6.3.

6.6.1 What is XML?

HTML, short for HyperText Markup Language, is a text-based tag language used to create pages on the Web. HTML defines the structure and layout of a Web document by using a variety of tags and attributes. An HTML document starts with <HTML><HEAD><TITLE>, followed by the title, followed by </TITLE></HEAD><BODY> and ends with </BODY></HTML>. Most of the information making up the Web document appears between the <BODY> and </BODY> tags. For example, within <H1> (Put Large Heading Here) </H1> would be headings, within <H2> (Put Smaller Heading or Text Here) </H2> would be smaller headings or text, and within <H3> would be even smaller headings or smaller text, etc. Within an <IMG . . . > or “image” tag would be a file identifying a picture to be displayed; such a tag could also identify another Web page that could be selected by the user clicking the picture. These are a very few of the many tags available in HTML. Reference [7] gives the URL of a Web site that presents an example of how HTML code translates to a Web page.

XML, eXtensible Markup Language, is a text-based tag language like HTML for defining documents. But, unlike HTML, which only describes how data is displayed, XML states what the data is. XML is defined and standardized by the World Wide Web Consortium (W3C) [8], the group who controls standards on the Web.

To display an XML document, another language, XSL (extensible Stylesheet Language), is used together with XML. XSL can generate HTML from the XML document.

Because XML treats a document as data and does not format it for display, the same XML document can be used to display the data on different types of devices, including on a PC screen, PDA screen, a telephone or other voice device. XML can also be used to present the data on the same device—all that is needed is a different XSL document to translate the XML document to the wanted format.

Additionally, to describe the structure and data elements making up an XML document in detail, an XML DTD (Document Type Definition) can be created, which can be included in the XML document or be separate from the XML document. For example, the DTD can describe a generic History and Physical document, Patient Consultation document, Patient Referral document, or Physician’s Medication Order document.

For example, figure 6.7 shows XML for a Patient Referral document identifying the data making up the particular patient referral.

Figure 6.7 – XML for a Patient Referral Document

<?xml version="1.0" encoding="UTF-8"?>

<TransmissionFrom>...TRANSMISSION-FROM Information ...</TransmissionFrom>

<TransmissionTo>...TRANSMISSION-TO Information ...</TransmissionTo>

</Header>

<AssigningAuthority>U.S. Assignment Authority</AssigningAuthority>

</Id>

<Id>

<AssigningAuthority>Lytton HMO</AssigningAuthority>

</Id>

</IdList>

<PersonName>Jane Louise Doe</PersonName>

<Sex Sex.HL70001="F" >Female</Sex>

</Patient>

<DiseaseString>Lump or mass in breast</DiseaseString>

</Disease>

</DiseaseList>

<ReferralPurpose>Evaluation of mammogram.</ReferralPurpose>

<OtherDocument>Mammogram</OtherDocument>

</OtherDocumentList>

</patientreferral>

Figure 6.8 shows an XML DTD for the Patient Referral document, in this case stored externally from the XML, describing the data elements used within the XML document. Such “data describing data” is called metadata.

Symbols within a DTD, and the structure chart, mean the following:

· ‘,’ between data elements means they must appear in the order shown within the document

· ‘|’ between data elements means that only one of the data elements may appear

· Nothing following a data element name means it must appear once and only once

· ‘+’ following a data element means it must appear once, and possibly many more times

· ‘*’ following a data element means it may appear any number of times (including zero)

· ‘?’ following a data element means it is optional, but it may only appear once.

XML DTDs provide the following methods to identify the format of data elements:

· #PCDATA is “parsable data”, text that is to be parsed by an XML parser.

· #CDATA is text that is not to be parsed by an XML parser.

Figure 6.8 – XML DTD for the Patient Referral Document

<?xml version = "1.0" encoding="UTF-8"?>

<!DOCTYPE patientreferral [

<!ELEMENT patientreferral (Header,Patient,DiseaseList,ReferralPurpose,

Comments?,OtherDocumentList?) >

<!ELEMENT Header (TransmissionFrom,TransmissionTo,DateIssued) >

<!ELEMENT TransmissionFrom (#PCDATA) >

<!ELEMENT TransmissionTo (#PCDATA) >

<!ELEMENT DateIssued (#PCDATA) >

<!ELEMENT Patient (IdList,PersonName,Sex,BirthDate) >

<!ELEMENT IdList (Id+) >

<!ELEMENT Id (IdMnemonic,AssigningAuthority) >

<!ATTLIST Id type (local|national|universal) "local" >

<!ELEMENT IdMnemonic (#PCDATA) >

<!ELEMENT AssigningAuthority (#PCDATA) >

<!ELEMENT PersonName (#PCDATA) >

<!ELEMENT Sex (#PCDATA) >

<!ATTLIST Sex Sex.HL70001 CDATA #IMPLIED >

<!ELEMENT BirthDate (#PCDATA) >

<!ELEMENT DiseaseList (Disease+) >

<!ELEMENT Disease (DiseaseString,DiseaseCode,DiseaseCodeSystem) >

<!ELEMENT DiseaseString (#PCDATA) >

<!ELEMENT DiseaseCode (#PCDATA) >

<!ELEMENT DiseaseCodeSystem (#PCDATA) >

<!ELEMENT ReferralPurpose (#PCDATA) >

<!ELEMENT Comments (#PCDATA) >

<!ELEMENT OtherDocumentList (OtherDocument+ ) >

<!ELEMENT OtherDocument (#PCDATA) >

A DTD is equivalent to a structure chart, such as in figure 6.9, describing the data in the document.

Figure 6.9 – Structure Chart Equivalent of DTD Document

Partly because this description of XML data elements with XML DTDs is too general, and, for example, does not match the element description capabilities in databases, a replacement for DTDs has been created. XML Schema is a W3C-sponsered effort to define an alternative to DTDs for defining the structure of XML documents. Within XML Schemas, data elements can be described at a lower level (byte, date, integer, user-defined, and others) and the exact number of occurrences of each data item can be identified; and unlike the DTD, an XML schema is itself an XML document [9].

Figure 6.10 shows an XML Schema for the Patient Referral document.

Figure 6.10 – XML Schema for the Patient Referral Document

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:annotation>

<xsd:documentation xml:lang="en">

Patient referral document

</xsd:documentation>

</xsd:annotation>

<xsd:element name="patientreferral" type="PatientReferralType" />

<xsd:complexType name="PatientReferralType">

<xsd:sequence>

<xsd:element name="Header" type="HeaderType" />

<xsd:element name="Patient" type="PatientType"/>

<xsd:element name="DiseaseList" type="DiseaseListType" />

<xsd:element name="ReferralPurpose" type="xsd:string" />

<xsd:element name="Comments" type="xsd:string"

minOccurs="0" maxOccurs="1" />

<xsd:element name="OtherDocumentList" type="OtherDocumentListType"

minOccurs="0" maxOccurs="1" />

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="HeaderType">

<xsd:sequence>

<xsd:element name="TransmissionFrom" type="xsd:string" />

<xsd:element name="TransmissionTo" type="xsd:string" />

<xsd:element name="DateIssued" type="xsd:date" />

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="PatientType">

<xsd:sequence>

<xsd:element name="IdList" type="IdListType" />

<xsd:element name="PersonName" type="xsd:string" />

<xsd:element name="Sex" type="SexType" />

<xsd:element name="BirthDate" type="xsd:date" />

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="DiseaseListType" >

<xsd:sequence>

<xsd:element name="Disease" type="DiseaseType"

minOccurs="1" maxOccurs="unbounded" />

</xsd:sequence>