phr document standard

printer friendly version of this page

Information Management in Indivo

There are several potential approaches to storing data in a personally controlled health record. The Indivo project has developed an approach that balances security, flexibility, and standards compliance. This approach is described in more detail below.

The Indivo Record and Indivo Documents

The data model for a personally controlled health record in Indivo is designed to be as generic as possible and yet still be capable of representing a collection of specific types of medical documents. To this end, we have adopted a philosophy of wrapping externally-defined documents in an XML structure that provides information about how to interpret the documents' contents. Therefore, a personally controlled record in Indivo is essentially a collection of documents, each with meta-data that describes how that document is classified within the record, the type of document, a brief description of the document's contents, and its creation and modification time.

The main "XML structure" which holds this collection of documents is the Indivo Record. Along with its document collection it also contains attributes defining creation time and last modification time. Each Indivo user is assigned his own Indivo Record. A single Indivo Document in the record's collection contains a list of versions, one for each update of the contained information. A version consists of a header element and a body element. The header contains meta-data that describes the content and processing instructions for the data contained in the body.

Our schema defines the version's body as a shapeless "any" element, which can hold any manner of XML data. In practice, the XML data stored in the body will conform to the description provided in the version header.

Our motivation for this meta-data scheme is primarily that we won't be reliant on the incomplete, emerging standards, but will be able to store documents produced by them and maintain useful information for processing them. We will also maintain copies of the current versions of these document descriptions so that, in the event that they change, we will be more easily able to migrate the older versions of documents to the new standard.

Indivo Personal Health Data Types

To date, there are no adequate standards that address the needs of the personal health record data types. To this end, the Indivo reference implementation defines several preferred document types that will be used in personally controlled health records.

While our storage model can accept XML in any format and from any source, defining distinct medical datatypes provides a consistent interface between those who provide data and those who interpret it. This consistency allows interoperability, enlightened processing, and sophisticated display. A full discussion of benefits appears in the next section.

Our development process began with a top-down approach to address high-level concepts such as "medications," "allergies," "physical examinations," "contact information," etc. To express these concepts, we approached each one by breaking it into subcomponents. As we progressed, we were able to identify common subcomponents among the high-level concepts. Once identified, we honed these common subcomponents into the basic building-blocks of other high-level concepts.

An example of this process can be seen in the creation of the Contact Information schema. We started with a list of fields like "First Name," "Last Name," "Pager Number," etc., used only to describe the record-holder. In time, we found that health care providers, organizations, etc., could also leverage this type, so we broke our schema down into reusable, shareable parts.

How the Indivo Standard Addresses Common Concerns

The Generic Storage Model

Much ink has been spilled complaining about the rigidity of data storage systems with regard to the types of data they can store. Typically, when the "concept" evolves the data storage specification requires modification. In the Indivo model, this is not the case, specifically because we have adopted a generic storage model -— we do not restrict the contents of an Indivo Document's body, as described above. Thus, while we encourage the use of our own personal health schemas for structuring body content, this is not required.

Extensibility of Document Types

The advantage of using XML Schemas for defining our document types is that component re-use and type-extension is built into the language. This means that a person or organization can easily define their own document type by piecing together pre-existing components from our schemas and/or extending those same components by adding optional and required attributes.

Because the Indivo storage model is generic and flexible, the server and storage code never need to be modified to handle newly defined data types. Also, carefully written Indivo applications that don't know about "new" types can apply generic display templates to present the data. In addition to handling unknown types generically, Indivo applications could take advantage of the document header meta-data to locate more information about these types and incorporate them statically or dynamically into their workflow.

Automatically generating all document displays based on meta-data, while theoretically possible, is simply not a tenable solution. Past attempts at this have lead to confusing, inelegant, and non-intuitive interfaces. Therefore, generic displays should be relegated only to the "unknown" case described above.

Validation and efficient storage/retrieval of Medical Types

When document types are well-defined and known upfront, several concerns can be ameliorated. Foremost amongst these concerns is the content validation. In other words, strongly-typed documents are the only way to ensure completeness and correctness of data. Another important concern is the ability to efficiently store and retrieve the data in a scalable manner. While our storage model allows for type-agnosticism, it can also leverage a priori knowledge of document types through the use of document processors. A document processor is a storage mechanism whereby the processor can break the document into smaller, more manageable chunks for highly specialized, secure, and distributed storage should the need arise. (A good example is the storage of genetic data, described and implemented by Ben Adida.)

Technology diffusion

Beyond overcoming the potential clash of cultures brought on by the introduction of a standard, another key hurdle is winning over those who actually implement PHR systems: the developers. XML and XML Schemas have a distinct advantage over other options for several reasons:

  • they are highly descriptive and easily understandable
  • they are commonly used in the technical community for a wide variety of tasks
  • they are already in the required skill sets of many job postings
  • there exists already a vast array of tools for creating, managing, viewing, and parsing of XML documents

Interoperability

Rather than proliferating the errors of existing electronic health systems by allowing for incompatible and proprietary data to be passed from institution to institution, we feel that it is appropriate to put forth a standard with the goal of addressing the needs of the patient-centered personal health record and no more. To this end, we have proposed a specific, yet fully extensible, set of well-defined datatypes. This will allow easy interoperability and end-to-end understanding of the exchanged information for all those who wish to adopt it. It is imperative to note that we are not limiting our standard to the initial set of data, but rather providing a starting point for the standard to evolve. We intend to use a similar process to that proposed by OpenEHR in its discussion of how to evolve its "archetypes" ; this process is discussed fully in the next section.

Extending the Indivo Data Model

Modifications to the Indivo data model can occur in two ways: addition of a new data type and modification of an existing data type.

Adding a new data type

When a new medical concept must be represented, an Indivo user will first confirm in the Indivo Official and Community Libraries that the concept is not already modeled in an existing Indivo schema. In that event, the user may consult with colleagues, international collaborators, and the open-souce community for guidance on defining a new schema. Indivo documentation on composing schemas will strongly encourage the user to leverage existing low-level types. When a first draft of the schema has been written, the user will submit it to the Indivo Community Library for public comment and peer review. After a sufficient period, further drafts may be written (and further review may occur), with the goal of ultimately submitting the schema proposal to the Indivo Consortium for promotion into the Indivo Official Library.

Modification of an existing type

Modifications will undergo a similar process, with increasingly greater scrutiny along this continuum of modification severity:

  • Adding optional fields
  • Adding required fields
  • Removing fields
  • Changing existing fields (datatype or name)

Previous versions will still be supported in a deprecated manner within the community, potentially with an end-of-life process announced.

Conclusion

Our model includes all of the advantages of the other comparable architectures and, through our particular use of XML, avoids many common pitfalls.