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>

</xsd:complexType>

<xsd:complexType name="DiseaseType">

<xsd:sequence>

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

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

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

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="OtherDocumentListType" >

<xsd:sequence>

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

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

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="IdListType">

<xsd:sequence>

<xsd:element name="Id" type="IdType"

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

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="IdType">

<xsd:sequence>

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

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

</xsd:sequence>

<xsd:attribute name="type" type="conversionCategory" default="local" />

</xsd:complexType>

<xsd:complexType name="SexType" >

<xsd:simpleContent>

<xsd:extension base="xsd:string" >

<xsd:attribute name="Sex.HL70001" type="xsd:string"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

<xsd:simpleType name="conversionCategory">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="universal" />

<xsd:enumeration value="national" />

<xsd:enumeration value="local" />

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

In programs using XMLs, a generic XML parser can be used to break out the individual data elements and data values from the XML document into a tree structure (similar to that in figure 6.9) based upon the XML DTD or XML Schema. The data and data elements can then be used in the program, for example, to output to a database.

6.6.2 Structure Besides Content = Sharing of Medical Records

Patient medical records are a series of single documents. Some of these documents are similar throughout the United States and the world. Common documents include the following:

· History and Physical: The patient's initial medical examination and evaluation data.

· Patient Referral: A request from one physician to another for specialty care or advice.

· Patient Consultation: A request from one physician to another for specialty advice.

· Progress Note: Documentation for a follow-up visit.

· Physician’s Order: Prescription, laboratory test order, etc.

· Consultation Report: Response to a referral.

· Discharge Summary: Report on a patient on discharge from a hospital.

If a common structure can be agreed upon for such documents, then there could be increased sharing of patient medical records between healthcare institutions, with transfer of the medical records over the Internet from one medical institution to another.

6.6.3 Use of Standardized Data Within the CPR and Source Document Repositories

Source documents can potentially be used to produce the CPR repository database that is defined by the E-R diagram in figure 6.6. Using data in source documents, the CPR repository system can identify encounters for the patient, the practitioners involved in the encounter, and orders, procedures (services) and results (observations) for each encounter. Encounters could be organized by the problem.

For a source document to be displayed at the facility where it was created, it must preserve local data values. However, for the data in the CPR repository or for source documents to also be useful at other healthcare organizations, it must translate these local values into standardized ones whose formats are agreed upon by the healthcare industry. Two potential universal standards are HL7 and ASTM E 1384.

For many years, a standard for network communication of clinical information between healthcare computer systems has been “Health Level 7”, or HL7 in short. Seven refers to the seventh level (the applications level) of the OSI seven level network model.

HL7 enables communication of clinical information such as the following:

· patient identification (see figure 6.11)

· physician identification

· queries

· admissions, discharges and transfers (hospital care)

· outpatient visits

· physician orders

· financial transactions

· order results.

Since some of the same information can occur within patient medical records, the HL7 committee [10] is trying to promote use of HL7 cross-reference tables within XML for patient medical records. This could be done by use of XML attributes that identify HL7 tables. For example, the Sex.HL70001 attribute in the XML document in figure 6.7 identifies to use the HL70001 table to interpret values for the sex of a patient. The corresponding HL70001 table is displayed in figure 6.12.

The ASTM also has standards for the patient medical record—these standards are compatible with the HL7 standards: the ASTM E 1384 standard for the electronic health record [1], ASTM E 1633 standard for coded values in the electronic health record, [11], and ASTM E 1714 standard for properties of a universal healthcare identifier [12].

It is the author’s opinion that each source document must preserve the original values entered and should have the ability to also include national or universal standard values. The example in figure 6.7 shows the local data element for <SEX> as being “Female” and the HL7 standardized value as being “F” as an attribute. The HL7 sex value comes the domain of values in the HL70001 table. Note that using data elements with attributes is only one approach to including both the local and standard values in a source document.

Figure 6.11 – HL7 Patient Identification Network Message

PID|2||987654321^^^AZ||JONES^JOHN^RICHARD||19900607|M^MALE^HL70001<CR>

Figure 6.12 – HL70001 Sex Table

Value	Description
F	Female
M	Male
O	Other
U	Unknown

A second approach for storing both standardized and local data elements at the same time is to have an element occurring more than once. This approach is also shown in the XML document in figure 6.7 for the IdList with contains multiple Id elements. The element, in this case “Id”, occurs twice, once for the standard patient identifier (type=“universal” meaning a standard and universal value) and once for the corresponding local patient identifier (a missing type attribute implies a “local” value). The first “Id” indicates that the standard patient identifier was assigned by a national assigning authority, while the second “Id” identifies that the local patient identifier was assigned by the HMO.

A way of identifying XML elements and attributes as belonging to a certain markup vocabulary, perhaps such as being standard parts of a standard patient referral document or as HL7 elements, is using namespaces [13]. This involves preceding the elements or attributes with a prefix with a colon, and then associating the prefix with a URL location of documentation associated with the markup vocabulary. For example, figure 6.10 shows use of an arbitrary prefix “xsd:” and associating it with the URL location of XML Schema documentation, thus identifying the elements and attributes using the prefix as part of the XML Schema markup vocabulary.

6.6.4 Clinical Document Architecture

The group who created HL7 is working on standards for different kinds of source documents using XML using an architecture referred to as the “Clinical Document Architecture” (formerly known the “Patient Record Architecture”) [6]. Example documents could include those listed in section 6.6.2 and all others. Each XML document would have an architecture consisting of three parts: (1) a header, (2) a DTD structure for the document, and (3) XML content.

The header would contain the document type, authentication details, event, patient, and practitioner. There would be a separate DTD structure for each specialty/domain/document. Perhaps, the DTDs would be replaced by XML schemas in the future.

6.6.5 An Outline for Use of XML with the Automated Patient Medical Record System, Source Document Repository, and CPR Repository.

XML documents store data in structured form, also giving a name to each data element; XML DTDs or Schemas contain metadata describing the structure and format of each data element within the XML; and XSL enables rendering of the XML using the XML DTD or Schema, displaying the information on a PC or PDA screen, outputting the XML information via voice to a wireless phone, or outputting it in other forms.

The following is my proposal for use of XML with the automated patient medical record system, source document repositories and CPR repositories (see figure 6.13):

The various patient medical record source documents of a healthcare organization would be stored locally within the organization or alternatively in source document repositories. All source documents would contain the information as it was entered at the local facility and alternatively also contain the industry standard equivalents of the data.

Thus, all source documents could contain data only used locally, could contain standardized data agreed-upon by the healthcare industry, or could contain both. I propose that each such source document in a healthcare organization be described by local versions of the XML, XML DTD or Schema, and rendition XSL containing the local information and, where possible, equivalent standard values for the data. Storage of standard values in the XML could be done through attributes values supplementing the local element values, or by multiple occurrences of the same element (occurrences for both standard and local values); further, standardized values could also be differentiated by use of namespaces.

The assumption will be made that some key types of source documents—perhaps those in section 6.6.2—would also have healthcare industry agreed-upon XML DTDs or Schemas. These XML DTDs or Schemas would only have standard data elements for the document type (e.g., for a patient referral). Together, such key medical record documents could be used to supply the total information required for the CPR repository and its patient medical summary.

I propose that the rule for these key source documents is that the local equivalent source documents must at least contain all the same information, collecting the equivalent local data and converting it to the standard form of the data, storing the standard form of the data in the local XML document. The agreed-upon XML DTD or Schema should then be derivable from the local XML DTD or Schema, by removal of local data specifications, as the local version of the XML DTD or Schema could be created by adding local data definitions to the agreed-upon XML DTD or Schema. (Note that the certain standardized information could be optional, while other standardized information could be required.)

Correspondingly, the local XML would be transformable to produce the XML with the standard values that conforms to the industry agreed-upon XML DTD or Schema. Such an ability to transform one XML document to another XML document already exists via a major subset of XSL that has been standardized by the W3C [14]: XSLT, Extensible Stylesheet Language Transformations.

The standard XML and XML DTD or Schema for these key documents should be sent to the CPR repository after an encounter, either from the automated patient medical record system within the local healthcare organization or alternatively from the source document repository after the local XML and XML DTD is received. If it is sent from the source document depository, then the source document repository should also store the XSLT so the source document repository can convert that document type from its local healthcare organization form in XML to its standard form in XML before sending it to the CPR repository.

The CPR repository software could use an XML parser to split out database values from the standard XML using the agreed-upon XML DTD or Schema, populating the CPR repository database. For a CPR repository database in E 1384 format, such a database’s structure is described by the ER diagram in figure 6.6.

When another healthcare organization asks the source document repository for a document generated by another healthcare organization, the local XML, XML DTD or Schema and XSL for the healthcare organization that created the document should be sent to that healthcare organization. When the document is rendered, it could then be rendered as entered by the originating healthcare organization; when the user places the mouse over a local value, the standardized value could be displayed, similar to what occurs when you place the mouse over an image in many Web documents.

6.7 Other Considerations: Security and Privacy, Language, and Correctness and Accuracy

Three other considerations for a universal patient record are

· security and privacy

· granting/requesting permission to receive copies of source documents

· language for recording information, and

· correctness and accuracy of information.

A universal patient record must provide security measures that disallow unauthorized use of the information and protect the patient’s privacy. These security measures must conform to any applicable security rules and laws. Security laws and rules may vary by country or region of the world. For example, in the United States, security of patient medical records is governed by state and federal laws and by rules from the US Department of Health and Human Services referred to as HIPAA—see section 13.9.1 and the Appendix. What rules and laws apply when care is given across countries? And what happens if such rules and laws hinder medical care?

Authorized parties can request permission to copy source documents, and the caregiver who created a source document or his healthcare organization together with the patient can grant permission to an authorized party to copy the document. Perhaps, certain categories of permissions can be granted by policy and/or pre-approval of a patient. For example, an HMO might, by policy, be automatically granted the authority to copy source documents of patients who are HMO members, and insurance companies might automatically be granted authority to copy financial information from source documents for patients who they insure. Patients and caregivers could identify some information as requiring special security (e.g., genetic or mental health information). Standards for the relationship of these grants and requests with the CPR and source document repositories, and for the communication paths of these grants and requests probably need to be developed, together with the development of standards for these processes.

A universal patient record must be able to record care in any language in which care is given. View of records by a caregiver who speaks another language may require translation. Translation with the help of the recording caregiver may or may not be possible or practical.

The universal patient record should be correct and accurate. The mere fact that information is recorded for all to see is a risk to a caregiver recording the information, especially in nations such as the United States where misinformation may result in lawsuits. Translation from one language may also introduce errors.

Privacy and absolute accuracy of medical information is viewed to be of utmost importance in some developed nations, whereas just having some medical care is more important in many developing countries. If a specialty physician located somewhere else in the world could assist a family practice physician in the care of a patient in a developing nation, or if a physician could assist a non-physician healthcare worker, would security rules or laws, or fear of lawsuits, disallow or hinder this care?

Good medical care is a necessity for people to live well. Perfect care—perfect privacy and absolute correctness and accuracy of information—is a luxury, and probably will never be a reality nor a necessity. Could this quest for perfection hinder introduction of a universal patient record, a true method to improve medical care? Or could it even hinder caregivers from giving good medical care?

In any case, storage of the universal patient record in a CPR and source document repository must account for the various security and privacy laws of the world and protect view or transfer of information to unauthorized people. Storage of the universal patient record must be allowed in any language in which care can be given, with the capability to support translation to the languages of other caregivers.

In some medical institutions, psychiatry and genetics departments disallow dissemination of some patient information even to most caregivers within the institution (e.g., restricting access to emergency, psychiatric or genetic physicians). Should this information have equivalent security in the CPR and source document repository?

References

[1] ASTM, E 1384 - 99 Standard Guide for Content and Structure of the Computer-Based Patient Record, ASTM, 1999.

[2] Jagdish C. Kohli, Pacific Bell, Unpublished Talk on “Emerging Medical Technologies—in the 1990s and beyond”, for IEEE Oakland East Bay Communications Society, at Pacific Bell, San Ramon, CA, February 29, 1996.

[3] http://www.whatis.com defines the term “application service provider” or “ASP” for short.

[4] Documentation on HL7 can be found at the Duke University World Wide Web server site “http://www.mcis.duke.edu”.

[5] Robin Cover, ASTM XML Document Data Types (DTDs) for Healthcare, July 6, 2000, http://www.oasis-open.org/cover/astmHealthcare.html.

[6] Robin Cover, Health Level Seven XML Patient Record Architecture, April 21, 2000, http://www.oasis-open.org/cover/hl7PRA.html, with hyperlink to HL7 Patient Record Architecture Ballot Proposal Package.

[7] Davis Community Network, http://www.dcn.davis.ca.us/~csandvig/ip/example.html, which shows an example of HTML and a resulting screen.

[8] W3C, Extensible Markup Language (XML) 1.0, W3C Recommendation 10-February-1998, http://www.w3.org/TR/REC-xml.

[9] The Web site of the XML Schema Working Group of the W3C is http://www.w3.org/XML/Activity#schema-wg.

[10] Robin Cover, ASTM XML Document Data Types (DTDs) for Healthcare, July 6, 2000, http://www.oasis-open.org/cover/astmHealthcare.html, hyperlink to PRA presentation (PowerPoint).

[11] ASTM, E 1633 – 99, Standard Specification for Coded Values Used in the Electronic Health Record, ASTM, 1999.

[12] ASTM, E 1714 – 95, Standard Guide for Properties of a Universal Healthcare Identifier (UHID), ASTM, 1995.

[13] Namespaces in XML, World Wide Web Consortium 14-January-1999, http://www.w3.org/TR/REC-xml-names.

[14] W3C, XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999, found on the Internet at http://www.w3.org/TR/xslt.

NEXT

TABLE OF CONTENTS

Comments? mailto:Michael.McGuire@abac.com