Sandy Boyer

Liora Alschuler

1. Introduction and background
2. Progress and current status
3. Issues in PRA design
4. Future development
5. Acknowledgements

Introduction and background

The most recent draft of the PRA states:

"The HL7 Patient Record Architecture (PRA) is a document representation standard designed to support the delivery and documentation of patient care. A PRA document is a defined and persistent information object. It is a multimedia object which can include text, images and sounds."

The PRA document specifications form an architecture that, in aggregate, defines the semantics and structural constraints necessary for the exchange of clinical documents. The semantics of the PRA are drawn from the HL7 RIM.

The architecture is vendor-neutral and platform-independent and is specified in Extensible Markup Language (XML). As an exchange artifact, the PRA is predicated on the assumption that providers will express their own clinical and business rules in their local DTDs, then transform them to a PRA-compliant instance for exchange of clinical data between applications and providers. PRA is being developed by the Kona Editorial Group and the HL7 XML TC.

The PRA is based on a set of design principles that include presenting a low barrier to adoption, while providing a migration path to sophisticated electronic medical records. The architecture is structured around three levels that provide increasing granularity of markup. PRA documents at all levels are human readable. The PRA defines "human readable" as viewable using widely available and commonly deployed XML-aware browsers and print drivers along with a generic PRA style sheet written in a standard style sheet language.

Each PRA document consists of a header and a body. The PRA Header provides metadata that identifies and classifies the document, and provides authentication details and information about the encounter, the patient, and the provider. The header is consistent across all levels of the architecture.

The PRA Header utilizes RIM semantics (classes and associations) to define it's semantics, but the development methodology allows some choice in the expression of the XML element names. For example, the header DTD declares the syntax for "service_location":

The fixed attributes indicate that this is derived from the "master patient service location" class of the RIM.

The body of the most basic level of the architecture (Level One) supports display and simple processing. Level One PRA documents use basic, non-semantic XML structures, (e.g., section, paragraph, list). A Level One PRA document can be as simple as a non-XML body with a PRA Header:

PRA documents have a standard framework for coded vocabulary terms. In this fragment, a piece of content is associated with a term from the Systematized Nomenclature for Medicine (SNOMED) vocabulary:

The PRA also provides a tag for locally relevant markup that can be ignored by receiving processors.

Previous

Table of Contents

Progress and current status

The HL7 SGML/XML Special Interest Group was granted technical committee status at the January 2000 HL7 meeting in San Diego. The TC is currently re-evaluating its name, mission, and charte and its relation to other HL7 technical committees. In this process, users have reiterated the need not only for a document architecture but, more importantly, a scalable architecture that permits participation by implementers at lower levels of complexity and adaptation to higher levels of complexity as they are able.

Also in January, HL7 passed a committee level ballot containing a conceptual framework for PRA as a whole, as well as the technical specification for the PRA Header and Level One body. The TC has submitted a second committee-level ballot for a vote in April, 2000. Submission of a full HL7 membership ballot is anticipated by September, with the goal of achieving an HL7 and ANSI-approved standard by the end of the year. As this portion of the framework moves through the HL7 balloting process, work on Levels Two and Three is proceeding.

One benefit of the multi-level architecture is that implementation and standards development can inform and assist each other in a cooperative, iterative process. Thus, experience implementing Level One will provide valuable input into the design of Level Two and allow us to issue a standard within a reasonable period of time.

The first committee-level PRA ballot passed by a wide margin and some very useful comments were received from both assenting and dissenting voters. As a result of those comments, the PRA framework document has been revised extensively and there was one significant addition to the PRA Header. The addition to the Header was an ISO globally unique object identifier to put it in conformance with requirements from DICOM. Additional changes to the Framework document produced a cleaner, more precise document. The document has been reorganized in an effort to accommodate the needs of implementers regardless of their level of knowledge or sophistication in HL7 semantics and processes (in the interest of the prime directive of keeping the barrier to entry low).

Other committees within HL7 are developing the next generation of messages, designated Version 3, in parallel with the PRA. The Version 3 datatypes utilized by PRA are currently undergoing balloting under the sponsorship of another TC. However, Version 2.3 continues to be widely used and the new draft PRA specifies how PRA documents can be sent as payload within V2.3x messages.

Previous

Table of Contents

Issues in PRA design

The PRA Header uses RIM semantics and has been derived using the HL7 MDF with minor adaptations.Decisions regarding content and structure of the PRA have been complicated because both the RIM and the MDF are still in development. While the HL7 RIM and MDF were initially developed to meet the needs of HL7 version 3 messaging, the PRA represents their first real world test.

The differentiating factors between PRA and the next-generation HL7 messages include the requirement for persistence and immutability for PRA documents, characteristics which are not universal in message instances. Despite these different requirements, issues stemming from the reliance on the RIM reflect the different timetables of the two projects and the "ownership" of specific RIM classes rather than substantially different requirements.

The XML TC continues to be an active participant in the RIM harmonization process (which now includes the vocabulary domain definition process). The scenario of sending PRA documents within HL7 messages imposes unique and sometimes overlapping requirements that will be worked out among the HL7 technical committees and special interest groups. In the meantime, the PRA framework document will reference specific versions of the RIM and HL7 data types in effect at the time of balloting, as the HL7 messaging and information model standards evolve out of phase with the PRA. The needs of PRA are currently a driving force for development of domain tables for coded values in the RIM.

Previous

Table of Contents

Future development

It is anticipated that some features of the PRA will change in the near future as additional standards, including XML Schemas, become available and provide greater functionality.

A number of healthcare software vendors and providers in the U.S. are in the process of incorporating PRA into their developing systems. Many of these have representation on the XML TC and are active in development of PRA. Their input has been invaluable in refining and maximizing the structure and power of the architecture. In particular, they have been helpful in establishing the line between PRA Header requirements and local document management requirements within institutions. While there is widespread interest in XML and PRA as an important and viable solution to the problem of encoding, exchanging, and preserving patient record documents, the speed of implementation is dependent on the continued development of suitable tools.

The interoperability of HL7 XML messages and documents was tested in a prototype exchange network designed, built and demonstrated on the floor of the HIMSS trade show in February 1999 and again in April 2000.

The HIMSS 2000 demonstration featured healthcare applications and generic XML tools in a scenario that used the PRA, HL7 V3 XML messages, and the SNOMED controlled vocabulary. In this scenario, patients were registered on one system, lab orders and encounter records were created on separate applications, and transcribed documents conforming to the PRA generated on another application. All generated records, PRA and V3, were collected in an XML database with a simple user interface. Queries against the data leveraged the diagnostic and procedure codes included in the lab orders and PRA documents.

This demo was in development as this paper was written. We will display sample documents and illustrate the exchange scenario at the Paris conference.

For additional information, see the http://www.hl7.orgweb pages.

Previous

Table of Contents

Acknowledgements

Previous

Table of Contents