	XML in healthcare		Table of contents		Indexes		SynExML as a vehicle for Electronic Patient Records

HL7 Patient Record Architecture update

Boyer, Sandy

Sandy Boyer

Co-editor

California

Laguna Beach
Patient Record Architecture

USA

Patient Record Architecture, Laguna Beach California USA email: slboyer@ibm.net

Biography

Sandy Boyer - Sandy Boyer is a pharmacist with many years of experience as a content expert involved in development of drug information. After participating in conversion of a large, highly structured drug information text into SGML, she became interested in the potential for SGML (and later XML) to facilitate utilization and integration of clinical healthcare data and resource information in systems designed to improve quality of healthcare. She has been involved with the HL7 XML Technical Committee and Kona Editoral Group since their inception, and is a co-editor of the HL7 Document Patient Record Architecture (PRA). She is currently working as a consultant in the U.S. and Australia. She has spoken on document markup (including document analysis) and XML at national and international conferences, including Health Level 7, the American Medical Informatics Association (AMIA) and XML Europe.

Alschuler, Liora

Liora Alschuler

Chair, Kona Editorial Group

Co-chair, HL7 XML TC

Co-chair, HL7 XML TC,

Biography

Liora Alschuler - Liora Alschuler is a consultant and writer specializing in the application of SGML and XML to healthcare information systems. She is the author ofABCD... SGML: A User's Guide to Structured Information , ITCP, 1995, and a Contributing Editor for the Seybold Report on Internet Publishing. Ms. Alschuler and Dr. John Spinosa are forming a partnership to be known as alschuler.spinosa which will specialize in the application of structured markup to healthcare information.

Abstract

XML TC

This presentation provides an update on progress and status of work of theXML TC , formerly the SGML Special Interest Group, withinHL7 including:

HL7, Health Level 7

Recent passage of a committee-level ballot of thePRA (including thePRA Header and Level One body DTDs); reconciliation of comments and submission of a second committee-level ballot.

PRA	Derivation of the PRA from the HL7RIM .

RIM	Sending PRA documents in HL7 messages.

The HIMSS 2000 demonstration, which involves interconnected messaging and document applications.

Introduction and background

The most recent draft of the PRA states:

Patient Record Architecture
"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.

PRA

ThePRA 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.

RIM	The PRA Header utilizesRIM 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":

<!ELEMENT service_location (
id?,
addr?,
local.header*)>
<!ATTLIST service_location
%common-atts;
%HMD.element.attrib.list;
HL7-NAME CDATA #FIXED 'has_master_patient_service_location'
T CDATA #FIXED 'master_patient_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:

<!ELEMENT body (section+ | non-xml)

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:

<content>
<highlight>Asthma, with prior smoking history. Difficultly weaning
off steroids. Will try gradual taper.</highlight>
<coded_entry>
<coded_entry.value T="<highlight>CV</highlight>"
   V="<highlight>D2-51000</highlight>" S="<highlight>SNOMED</highlight>"/>
</coded.entry>
</content>

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

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.

DICOM, Digital Imaging and Communications in Medicine

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 fromDICOM . 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 inHL7 semantics and processes (in the interest of the prime directive of keeping the barrier to entry low).

HL7, Health Level 7

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.

Issues in PRA design

MDF

RIM

The PRA Header usesRIM semantics and has been derived using the HL7MDF 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 andMDF were initially developed to meet the needs of HL7 version 3 messaging, the PRA represents their first real world test.

MDF

RIM

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 theRIM 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.

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.

HIMSS, Health Information Management and Systems Society

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

HIMSS, Health Information Management and Systems Society

TheHIMSS 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.org web pages.

Acknowledgements

KEG	This paper describes work of theKEG , which is a working group of the HL7 XML Technical Committee that is charged with development of and reconciliation of comments on the PRA specification.


	XML in healthcare		Table of contents		Indexes		SynExML as a vehicle for Electronic Patient Records