HS691.001.001-01

R. Lecker

D. Armijo

S. Chin

J. Christensen

J. Desper

A. Hong

L. Kneale

Review of Personal Health Record (PHR) Service Provider Market

Interoperability and Data Mobility

March 14, 2007

Preface

This report was developed for the Office of the National Coordinator for
Health Information Technology (ONC) by Altarum Institute, a nonprofit
research organization. Work was performed under the American Health
Information Community (AHIC) Program Support contract; Prime Contract
No. GS-10F-0034N, Order No. HHSP233200500217U.

Technical Questions should be directed to:

Mr. Robert Lecker

Director, Health Informatics

Altarum Institute

Tel: (703) 575-1691

E-Mail: robert.lecker@altarum.org

http://www.altarum.org

\"Systems Research for Better Health\"

Table of Contents

1.0 Statement of the Problem 1-[1](#statement-of-the-problem)

2.0 Background 2-[1](#background)

2.1 Interoperability Defined 2-[1](#interoperability-defined)

2.2 Why Interoperability is Important
2-[1](#why-interoperability-is-important)

2.3 Benefits of Interoperability 2-[2](#benefits-of-interoperability)

2.4 Interoperability Enablers and Challenges
2-[3](#interoperability-enablers-and-challenges)

2.4.1 A non-interoperable PHR can still be useful
2-[4](#a-non-interoperable-phr-can-still-be-useful)

2.4.2 A variety of forces will enable or discourage PHR-based data
exchange
2-[4](#a-variety-of-forces-will-enable-or-discourage-phr-based-data-exchange)

3.0 Methodology 3-[1](#methodology)

3.1 Vendor Interviews 3-[1](#vendor-interviews)

4.0 Summary of Findings 4-[1](#summary-of-findings)

5.0 Case Studies 5-[1](#case-studies)

5.1 ODEV1 5-[1](#odev1)

5.1.1 Description of the Organization
5-[1](#description-of-the-organization)

5.1.2 Description of the Architecture
5-[1](#description-of-the-architecture)

5.1.3 Approach to Interoperability 5-[1](#approach-to-interoperability)

5.2 ODEV2 5-[2](#odev2)

5.2.1 Description of the Organization
5-[2](#description-of-the-organization-1)

5.2.2 Description of the Architecture
5-[2](#description-of-the-architecture-1)

5.2.3 Approach to Interoperability
5-[3](#approach-to-interoperability-1)

5.3 ODEV3 5-[4](#odev3)

5.3.1 Description of the Organization
5-[4](#description-of-the-organization-2)

5.3.2 Description of the Architecture
5-[4](#description-of-the-architecture-2)

5.3.3 Approach to Interoperability
5-[4](#approach-to-interoperability-2)

5.4 COTS1 5-[5](#cots1)

5.4.1 Description of the Organization
5-[5](#description-of-the-organization-3)

5.4.2 Description of the Architecture
5-[5](#description-of-the-architecture-3)

5.4.3 Approach to Interoperability
5-[5](#approach-to-interoperability-3)

5.5 COTS2 5-[6](#cots2)

5.5.1 Description of the Organization
5-[6](#description-of-the-organization-4)

5.5.2 Description of the Architecture
5-[6](#description-of-the-architecture-4)

5.5.3 Approach to Interoperability
5-[6](#approach-to-interoperability-4)

5.6 COTS3 5-[7](#cots3)

5.6.1 Description of the Organization
5-[7](#description-of-the-organization-5)

5.6.2 Description of the Architecture
5-[7](#description-of-the-architecture-5)

5.6.3 Approach to Interoperability
5-[8](#approach-to-interoperability-5)

5.7 DATA1 5-[8](#data1)

5.7.1 Description of the Organization
5-[8](#description-of-the-organization-6)

5.7.2 Description of the Architecture
5-[9](#description-of-the-architecture-6)

5.7.3 Approach to Interoperability
5-[9](#approach-to-interoperability-6)

5.8 DATA2 5-[9](#data2)

5.8.1 Description of the Organization
5-[9](#description-of-the-organization-7)

5.8.2 Description of the Architecture
5-[9](#description-of-the-architecture-7)

5.8.3 Approach to Interoperability
5-[10](#approach-to-interoperability-7)

6.0 Conclusions 6-[1](#conclusions)

Appendix A: Levels of Interoperability
A-[1](#appendix-a-levels-of-interoperability)

Appendix B: HL7 Clinical Document Architecture (CDA) and ASTM Continuity
of Care Record (CCR)
B-[1](#appendix-b-hl7-clinical-document-architecture-cda-and-astm-continuity-of-care-record-ccr)

**Appendix C: List of Acronyms C-1**

List of Exhibits

Exhibit 1: Organization Categories 3-[2](#__RefHeading___Toc160960275)

Exhibit 2: Current Siloed PHR Market 4-[1](#__RefHeading___Toc160960276)

Exhibit 3: Use of Clinical Document to Enforce Content Standards Creates
Interoperable PHRs 4-[3](#__RefHeading___Toc160960277)

Exhibit 4: Types of Source Data and Levels of Interoperability
4-[4](#__RefHeading___Toc160960278)

# Statement of the Problem

Without broadly applied interoperability functionality, the Personal
Health Record (PHR) will exist in the very narrow context of the
consumers' relationship with a single provider or health plan, or as
isolated containers for self-entered data. The National Committee on
Vital and Health Statistics summarizes the issue as follows:

> *"The greatest opportunities for improving health and health care lie
> in enabling information exchange between the three dimensions
> (consumers, providers, and population / public health) of the national
> health information infrastructure. The full potential of PHR systems
> will not be realized until they are capable of widespread exchange of
> information with EHRs and other sources of personal and other health
> data."*

Therefore the Office of the National Coordinator for Health Information
Technology (ONC), in support of the American Health Information
Community (AHIC) Consumer Empowerment (CE) Workgroup, requested a review
of existing models of data exchange among PHR service providers, PHR
users, Electronic Health Records (EHR) systems, and other health care
entities to understand:

-   The current state of PHR interoperability;

-   What enablers and challenges exist, and;

-   What can be done to make data interoperability an achievable goal
    for all stakeholders.

This document addresses PHR interoperability using a qualitative,
case-study approach.

# Background

This section provides an introduction to interoperability, including its
importance, what benefits it holds, and what challenges are preventing
it.

## Interoperability Defined

Interoperability refers to the technical capability of two or more
***systems*** or components to ***exchange information*** and to ***use
the information*** that has been exchanged. Applied to health care,
interoperability includes the capability of health information systems
to work together within and across organizational boundaries to advance
the effective delivery of health care for individuals and
communities.[^1] The following definitions provide additional
understanding:

-   *Syntactic interoperability* means that the exchange of the
    structure of the data is successful, but that the meaning of the
    data may be interpreted differently by different parties;

-   *Human or semantic interoperability* guarantees that the meaning of
    a structure is unambiguously exchanged between humans. Documents
    such as progress notes, referrals or consults rely on terminology
    and practice that guarantee semantic interoperability between
    clinicians; and

-   *Computable semantic interoperability* requires that the meaning of
    data be unambiguously exchanged from machine to machine.[^2]

So, to achieve true interoperability among EHRs, PHRs, and all the other
components in the health care system, both structure (i.e., syntax) and
meaning (i.e., semantics) of the data being exchanged must be addressed.
Additional information on levels of interoperability can be found in
Appendix A.

## Why Interoperability is Important

Many of the well-documented and interrelated problems of quality,
efficiency, and effectiveness in the US heath care arena are very often
information problems: lack of information at the point of care or poor
recording or transmission of information. The often-used "silo" metaphor
to describe existing health care IT applications that are not integrated
applies particularly well to patients' clinical data. Payers and
providers routinely submit, process, and pay claims electronically, but
most clinical data continue to be handwritten on paper and it is
virtually impossible for it to follow a patient through the fragmented
health care maze[^3].

Without the capability to exchange information in a standardized way
with other sources of patient-specific clinical data, PHRs will only add
to the already crowded silo landscape, offering limited access and
transient value.

From the PHR perspective, interoperability and data exchange have three
components.

The first component is the ability of PHRs to import and make use of
data from source Health Information Technology (HIT) systems, such as
Electronic Health Records (EHRs) and Computerized Provider Order Entry
(CPOE) systems in physicians' offices and hospitals, pharmacy databases,
laboratory information systems, radiology information systems, and
standalone "health journals" or other self-entered data from a PHR
itself.

The second component is the ability of a PHR to export a record or
document to another PHR or EHR. A core finding of this case study is
that this latter form of interoperability among PHRs and EHRs is ready
today (see Appendix B), while the interoperability of source systems is
many years away.

A third component, touched on only briefly here, includes the cultural
norms and business rules enabling data exchange using the PHR. These
include the willingness of providers to accept PHR-sourced information,
the ability of patients to make decisions based on PHR information,
along with the environmental issues of reimbursement and privacy.

## Benefits of Interoperability

When full interoperability among source systems and PHRs exists,
information exchange has the potential to advance health care and health
care systems radically in several critical areas, including patient
safety, outcomes, and efficiency and access.[^4] The benefits of
interoperability among source systems are well known and include:

-   Reduced errors in orders

```{=html}
<!-- -->
```
-   Interoperable systems enable decision support to reduce drug allergy
    reactions and drug-drug interactions, and to alert providers and
    patients to potential side-effects of prescribed medications

```{=html}
<!-- -->
```
-   Reduced delay in receiving results from laboratory tests, radiology
    examinations, and outside consultations

```{=html}
<!-- -->
```
-   Interoperable laboratory information systems and EHRs enable
    immediate messaging and importing of results for follow up and
    patient tracking across the continuum of care

```{=html}
<!-- -->
```
-   Enhanced public health monitoring and surveillance

```{=html}
<!-- -->
```
-   Interoperable clinical systems enable constant surveillance for
    emergent public health threats, either natural (e.g., influenza) or
    bio-terrorist.

    These benefits will accrue whether or not PHRs exist or are
    interoperable.

Interoperability among PHRs also provides specific benefits to
consumers, beyond those commonly attributed to the healthcare system for
other forms of HIT interoperability. These include the following:

-   Direct Consumer Benefits

```{=html}
<!-- -->
```
-   Interoperability among PHRs enables patients to move among PHR
    vendors without fear of losing data

-   Interoperability from PHRs to source systems would enable a complete
    medical record to travel with consumer at all times

-   Consumers gain better understanding of their disease course,
    condition, and care by direct interaction with their clinical data
    and with decision support tools linked to those data

-   Patients gain from improved coordination of care and appropriate
    matching of caregivers to needs via disease management, on-line
    nurse call-center support, etc.

-   Patient intake and processing is made more efficient (i.e.,
    "eliminate the clipboard")

-   Consumer access to bill payment and explanations of coverage makes
    for easier management of insurance benefits and claims

-   Increased efficiency from online communications to schedule
    appointments, obtain medication refills, and ask questions

```{=html}
<!-- -->
```
-   Indirect Consumer Benefits

```{=html}
<!-- -->
```
-   Emergency medical personnel would have access to critical portions
    of the medical record (e.g., allergies, current medications,
    problems list) to speed care

-   Interoperable PHRs could act as the catalyst, or even as source
    systems, for global HIT information exchange via networked systems
    and applications.

Some of these benefits accrue even with partial interoperability among
systems, or with full interoperability only over some domains, such as
demographic information or insurance coverage. Others, for example the
ability of emergency personnel to access the PHR at any time, will
depend on broad use of PHR by individuals and incorporation of fully
interoperable PHRs into existing provider workflows.

## Interoperability Enablers and Challenges

This section briefly addresses primary enablers and challenges to the
use of interoperable PHRs and interoperable
consumer-focused-and-controlled clinical data. The benefits of
interoperability described in Section 2.3 are achieved not simply
through technical means, but rather through a complex process of
adoption and business process change, data exchange, and information
integration, which will lead eventually to improved knowledge, patient
care, and outcomes. That is, interoperability is a necessary---but not
sufficient---step to a process change and thus should not be mistaken
for an outcome in and of itself.

### A non-interoperable PHR can still be useful

First, it is important to understand that a PHR can be functional
without any interoperability. Such a PHR is a health journal for
individual patients and their families, documenting care, health status,
OTC medications, and other aspects of their health through their own
individual lens. It may enable future conversations with providers, or
be useful as a mechanism to store and print out medication lists, food
allergies, and so on.

We have also observed highly functional PHRs that cannot interoperate
with other PHR architectures, or with clinical systems other than the
ones to which they are "tethered." As long as patients remain within the
circle of feeder source systems, information can be exchanged among all
participants without the need for interoperating systems.

### A variety of forces will enable or discourage PHR-based data exchange 

Interoperability becomes valuable only to the extent that business needs
and consumer demand requires it. PHR-based data exchange will be enabled
by a variety of technical initiatives already underway. Areas of
concern, where challenges will loom in effective data exchange, are
primarily among privacy rules and business processes.

#### Interoperability Enablers

Enablers to interoperable PHRs include a variety of technology-based
initiatives already underway with significant stakeholder investment and
engagement. These are outlined below:

-   **Emerging PHR document-based exchange standards**. Our case study
    review (summarized in Section 4.0) shows emerging capacity among PHR
    vendors to use existing document architectures (Continuity of Care
    Record, Clinical Document Architecture, and variants of these) for
    exchange among PHR systems, and for moving data into and out of
    PHRs. This is a very promising avenue for clinical data interchange
    in general, using the PHR as a "container" for relevant care data
    among care providers;

-   **Growing numbers of interoperable source systems, both clinical and
    administrative**. Ongoing efforts by government and industry to
    develop and adopt standards among source systems---and growing
    adoption of clinical information systems---is providing a growing
    base of information support to the interoperable PHR; and

-   **Emerging identification, authentication and authorization
    standards**. A PHR is only useful to a clinician if the information
    it contains can be trusted or verified. For example, a "spoofed" PHR
    or source EHR could be used to generate and verify spurious
    diagnoses, test results, or prescriptions. Emerging work on
    federated identity management and other tools can provide individual
    control without individual rights to edit or alter information.
    Emerging identity and authentication capabilities also ensure the
    PHR does not become a source of clinical data vulnerability to
    consumers.

#### Interoperability Challenges 

Existing workflow and business rules evolved to support existing,
clinician-centered systems with little data interchange among
stakeholders, including consumers. As a result, policy and practice will
need to change and evolve in concert with technology innovation and
adoption to fully support and create value from interoperability.

-   **Lack of rules governing the privacy of PHR data**. The privacy of
    PHR information is not well established under Federal Privacy
    Rules.[^5] Adequate protection will require industry, government,
    and consumer joint participation to generate appropriate practice,
    policy, and legal frameworks.

-   **Lack of incentives among participants for exchanging
    information**. Information exchange has succeeded where incentives,
    including financial ones, are aligned. Networks to support
    electronic pharmacy prescription orders, for example, have emerged
    from private sector collaboration among pharmacies, physicians, and
    health plans with sustainable revenue sharing models.[^6] Other
    networks, for example Clinical Health Information Networks among
    hospitals, have failed due to a lack of sustainable financial
    incentives.

-   **Need to redesign provider workflow to accommodate patient-sourced
    or initiated information**. Current workflow and culture support a
    unidirectional flow of information from physicians and hospitals to
    patients. Patients comply with--- rather than collaborate on---their
    treatment plans. Patients' families and support networks are rarely
    integrated as sources of clinically relevant information. Patients
    generally lack direct access to tests, or to test results, and
    resources to interpret these results.[^7] For all these reasons,
    consumer empowerment implies a longer-term cultural transformation
    in care, perhaps enabled by small-scale pilots and other quality of
    care focused initiatives.

The growing adoption of Clinical Document Architecture and Continuity of
Care Record-based PHRs shows that PHR interoperability will proceed
whether or not all requisite business-process challenges are overcome.
However, it also seems clear that the usefulness, value, and speed of
adoption of interoperable PHRs will be aided greatly by progress in
overcoming some of these identified challenges.

# Methodology 

This section describes our methodology used in this study.

## Vendor Interviews

A qualitative, empirical case-study approach was taken to examine the
various meanings and interpretations of interoperability in the PHR
market. This method was rigorous in its approach to collecting large
amounts of interview data from primary sources who have direct knowledge
of the design and implementation of the PHR and its interconnectivity to
external data sources.

The strength of the case-study method lies in its ready applicability to
real life, as it draws upon specific solutions to specific problems.
However, the case-study approach does not rely on a random or
representative sample of the market, and therefore provides no
information as to whether these solutions are common or unique. Instead,
it is an in-depth discussion of specific examples, to illustrate
particular mechanisms that promote interoperability.

From December 12, 2006, to January 11, 2007, Altarum carried out eight
face-to-face or telephonic conversations with PHR vendors and data
providers, with supplemental materials provided by some interview
subjects. All of the organizations we interviewed have production
systems with active users.

In this section, we describe six cases of existing PHRs or portions of
PHRs and two data providers that could play an integral role in
populating PHRs. We evaluated a wide range of interoperability and
exchange capabilities, driven by different business architectures. We
found it useful to group the organizations playing key roles in
evolution of PHRs into the three categories: commercial off-the-shelf
(COTS), organizationally developed (ODEV), and data providers (DATA).
These categories are defined in Exhibit 1.

Each confidential interview was attended by at least two Altarum
employees and interview notes were generated and discussed. A loosely
structured interview format was followed to elicit basic background
information leading to a conversation about data interoperability.

We followed a qualitative, narrative approach to information discovery
as the variety of PHR business and technical architecture proved quite
broad and each case was unique. Therefore, we identified particular
areas of success and challenges to success in each approach.

[]{#__RefHeading___Toc160960275 .anchor}Exhibit 1: Organization
Categories

  -------- ------------ -------------------------------------------------
  Number   Category     Definition
           Type         

  3        COTS         These are vendors of commercial, off-the-shelf
                        PHR software products.

  3        ODEV         These installations represent organizationally
                        developed PHR software products. These products
                        were developed to meet the specific demands of
                        the organization but may also be adaptable to
                        other, similar health care organizations.

  2        DATA         These are commercial health care data providers
                        who typically work with provider and payer
                        organizations as opposed to consumers. Their role
                        in PHR proliferation is evolving.
  -------- ------------ -------------------------------------------------

# Summary of Findings 

The current state of the PHR market is focused heavily on
non-interoperable solutions: current PHRs are generally fed by---or
write to---proprietary systems with closed formats. For example, one
system we learned about is capable of generating direct-to-physician
secure messaging with clinically appropriate "message triage" and
response. This functionality is enabled by an internally developed
hospital-based messaging system. Such a solution gains current high
functionality at the expense of open standards and interoperability.
Other systems provide workarounds with "human in the middle" interfaces
between non-interoperable or non-reachable (due to business rules)
systems.

This aspect of information "silos" is depicted in Exhibit 2. Current
PHRs tend to be attached directly to particular proprietary systems,
whether health plan, hospital, or provider. Electronic interchange with
retail pharmacy, claims systems, and other source data are emerging for
integrated PHRs that literally stand alone with their own databases but
use open standards for communication.

[]{#__RefHeading___Toc160960276 .anchor}Exhibit 2: Current Siloed PHR
Market

![](media/image4.png){width="6.245138888888889in"
height="5.079166666666667in"}

Our examination of interoperability methods did find examples of best
practices, or workable solutions, that create more machine-to-machine
interoperability. These include:

-   Use a document-based interchange format, for example Continuity of
    Care Record (XML), Clinical Data Architecture (HL7), or Continuity
    of Care Document (CDA representation of CCR) as an intermediary for
    input and output of the PHR, rather than manage direct
    machine-to-machine interoperation at the data level (see Appendix B
    for further discussion of CDA and CCR);

-   Provide rich metadata via Web services and XML (Extensible Markup
    Language) to describe the source, formats, security, and business
    rules surrounding data elements;

-   Negotiate with multiple data partners to generate necessary business
    rules in support of clinical data exchange;

-   Contract with external vendors to provide in-depth, non-technical
    interpretation of medical terms and concepts, rather than develop
    this content in-house;

-   Use already existing, highly standardized claims-based data to
    supplement PHR information, although interpretation and clinical
    relevance may be in dispute; and

-   Use pharmacy data, including medication history, as derived from
    CPOE and PBM (Pharmacy Benefits Manager) data, as these are also
    highly interoperable and have high consumer demand and clinical
    relevance.

The CCR or CDA provides the necessary requirements for tightly
structured content standards. It also dramatically lessens the tasks of
interoperability by reducing the information set to a meaningful,
workable few elements, validated by physicians and in use today. The
ability to import and export data in CCR or CDA formats provides a
buffer or second-degree interface to source systems, which can then be
cross-walked or have appropriate interfaces written to this open
standard, as shown in Exhibit 3.

HL7 and ASTM are currently working together to harmonize the CDA and CCR
standards. It would be advantageous to all users, providers, and payers
if this effort were to result in a common standard that incorporates the
best of each. Of the vendors we interviewed, more had working
implementations of the CCR than CDA. The reasons for this include the
CCR ease of implementation and the view that the CDA was less
stable---more of a moving target---than the CCR. Most went on to say
that they are prepared to support whichever standard is "chosen" and
would prefer not to have to support more than one.

[]{#__RefHeading___Toc160960277 .anchor}Exhibit 3: Use of Clinical
Document to Enforce Content Standards Creates Interoperable PHRs

![](media/image5.png){width="6.247222222222222in"
height="3.5430555555555556in"}

The CCR or CDA therefore acts as a critical medium for transport of HIT
data across non-standardized pathways. Those PHRs using the CCR or CDA
standard will have become interoperable with each other years ahead of
the interoperability of source HIT systems.

As an additional work product to supplement this set of case studies, we
also established a basic typology for data sources and their current
levels of interoperability. As noted above, claims and retail pharmacy
data currently exhibit the highest level of standardization and
interoperability and as such can form the basis for a currently
workable, integrated PHR.

Other data sources, their current level of interoperability, and
comments regarding their usability, are shown in Exhibit 4. No current
data source offers a perfect solution and for many issues (particularly
in sourcing clinical data from near-universal EHRs), solutions seem many
years away.

[]{#__RefHeading___Toc160960278 .anchor}Exhibit 4: Types of Source Data
and Levels of Interoperability

  -------------- --------------------- ----------------------------------
  Source         Interoperability      Comments
                 Level                 

  Claims Data    High --- large        Very large existing datasets with
                 volumes of electronic records for most clinical
                 data exist;           encounters
                 interchange standards 
                 exist for EDI, claims 
                 attachments, and use  
                 in PHRs               

                                       ICD-9 code set lacks granularity
                                       in diagnoses and procedures

                                       Claims attachments may contain
                                       important ancillary results but
                                       may not be easily accessed

                                       Data quality of clinical
                                       information unknown until examined

                                       Never intended for clinical
                                       interpretation

  Prescription   High --- NCPDP SCRIPT Pharmacy clearinghouses currently
  data           standard for CPOE     have no consumer-facing strategy
                 identifies healthcare -- all transactions must pass
                 provider, pharmacist, through either a pharmacy or a
                 patient, drug; NDC    payer.
                 codes identify drugs; 
                 RxNorm standardizes   
                 drug names            

                                       Non-retail pharmacy transactions
                                       lack standards even if
                                       electronically captured

                                       Completeness of Rx history depends
                                       on usage of CPOE by physicians,
                                       data storage by pharmacies

  Laboratory     Poor --- Lack of      Patient cannot directly receive
  data           interlinked systems;  lab reports, must pass through
                 ELINCS just emerging  ordering physician for review
                 as standard for       
                 reporting results, no 
                 standards for lab     
                 orders                

                                       Lack of CPOE systems to external
                                       labs; hospital clinical systems
                                       may capture hospital labs and
                                       results

  Radiology      Medium --- systems    No consensus on appropriate
  reports        are largely digital   content for end consumer
                 with DICOM standard   
                 for imagery but lack  
                 of standards for      
                 orders and results    
                 reporting             

                                       Image files are very large

  Clinical notes Poor --- Needs source Business rules on release of
  (EHR SOAP      EHR; SNOMED exists    physician notes to patient are not
  notes,         for structured notes  well developed
  referral note,                       
  problem lists,                       
  etc.)                                

                                       Clinical documentation tends to be
                                       highly physician idiosyncratic

                                       Clinical information may not be
                                       usable to all consumers without
                                       some translation capability

  History and    Poor --- largely free Patient can enter own history via
  Physical       text                  kiosk or standalone PHR

                                       Many critical concepts are not
                                       clinical and do not have content
                                       standards (food allergies,
                                       exercise history, family history)

  Home Health    Poor --- no standards Emerging market, not in common use
  Monitoring     for device            
  Devices        communications, data  
                 formats or content    

                                       Obvious need for standards
                                       development
  -------------- --------------------- ----------------------------------

# Case Studies

As described in the Methodology Section, Altarum carried out eight
face-to-face or telephonic conversations with PHR vendors and data
providers, with supplemental materials provided by interview subjects.
This section presents the results of those interviews, with the identity
of the interview subjects and their organizations kept private and
represented by code names (e.g., ODEV1, COTS1, DATA1).

## ODEV1

### Description of the Organization

ODEV1 is a nationwide health plan with approximately 320,000 current PHR
users. Use of the PHR is voluntary but all plan beneficiaries are, or
will be, offered the opportunity at no cost. Two-thirds of these
consumers are patients of the affiliated healthcare system and one-third
of subscribers are consumers outside the system. Those accessing the PHR
outside the health care system do not have access to the full
functionality of the product. The PHR was launched over three years ago
and the main functionality includes:

-   Access to trusted health information;

-   Access to patient specific links on resources and benefits available
    through the affiliated healthcare system;

-   Ability to record health data into a personal journal; and

-   Ability to order prescription refills, make appointments, and access
    lab results.

The main goal of this application is to provide a gateway to better care
through the affiliated healthcare system.

### Description of the Architecture

ODEV1 employs Web services to manage its data and a Web-based display
architecture where all PHR data are stored centrally and viewed by the
user through a Web browser. In addition to user-entered data, some data
are pulled from the legacy EHR which is a rich source of longitudinal
patient data. The EHR is decentralized and built around the hospitals
and clinics where the consumer is seen for care. The PHR and EHR are
synchronized every 7 days.

### Approach to Interoperability

#### Current Implementation and Future Vision

ODEV1 currently extracts only a limited number of data elements from
their EHR, including medications, lab results, and appointments.
User-entered data in the PHR are not stored in the EHR but can be viewed
by a provider.

Data in the EHR and PHR are stored in different, proprietary formats.
Data exchange is accomplished via standard HL7 messages and XML, which
not only moves the data but translates between the two different
architectures. ODEV1's business model was the driver of the data storage
decisions.

Their developers have a long list of enhancements that are set to be
rolled out through a phased approach. This organization is working to
incorporate secure messaging from provider to patient along with the
capability to incorporate encounters with providers outside the ODEV1
system. In addition, they are working towards creating a more scalable
product. While they fully understand the value of interoperability, it
is privacy and security that have the highest priority at this time.

#### Challenges

ODEV1 has many subscribers and many of them have long and complicated
medical histories. The sheer volume of data that they must move to a
Web-based system is a significant challenge. They want to enhance the
current system to push full clinical notes into the PHR but are finding
the physical amount of data to be cumbersome.

Consistent with many of the other organizations with whom we spoke,
ODEV1 indicated that organizational challenges were more difficult to
overcome than the technical challenges. Differences in opinions
regarding privacy and security between management and consumers had to
be reconciled before launch. For example, the in-house EHR system
prompted for user-password changes every couple months but consumers did
not like the idea of changing their passwords. A compromise of many of
these policy changes had to be reached before the system could go live.
It was stated that the issues surrounding these services are not
technical, but are related to policy and regulations and are more
difficult to identify and resolve.

## ODEV2

### Description of the Organization

ODEV2 has been involved in optimizing electronic patient-doctor
communication for over 10 years. Their personal health record was
launched over four years ago and currently has an estimated 200 active
users and is expanding. Fully funded by an academic research group,
ODEV2 has close connections to both academic medical and hospital
environments. Currently, they are only providing services for consumers
who reside within the geographic area of the health system. The product
is offered at no cost to the consumer.

### Description of the Architecture

The ODEV2 PHR is fully distributed and the patient maintains total
control over who can access the record. It is not designed to replace
the EHR of the health care system but is designed to be comprehensive
and longitudinal. The user decides where the PHR is physically stored
including server farms or an ISP (Internet Service Provider). The PHR
does not contain user-entered or claims data, only clinical encounter
data. This Web service application source code and documentation are
available for free under the Gnu Lesser General Public License (Gnu
LGPL) and ODEV2 encourages others to implement their own applications
and contribute to the code base. Each PHR is automatically updated so
the PHR is always current. Finally, all consumers must authorize each
data exchange on an opt-in basis. Once the user specifies which entities
can deposit data into the PHR, the entities must approve which data
elements are appropriate to be shared. Finally, no entity can view the
PHR by default---each entity must be explicitly cleared by the user.

### Approach to Interoperability

#### Current Implementation and Future Vision

The current application is focused on "low-hanging fruit" such as lab
results, clinical notes, and patient allergy history. More complicated
functionality elements, such as insurance claims, are not currently
being implemented. The application can pull data from a variety of
specific partner organizations using an API (Application Program
Interface). ODEV2 could not find a data model that worked for them and
that was flexible enough to be compatible with future standards. So,
they chose to use XML documents that contain the clinical narratives
wrapped in metadata that describes format and meaning. Concern about
where the standards would go in the future led them to develop a model
that would be upward-compatible with any data model standard.

Shortly, this vendor will roll out their product to a number of other
market areas. They are hoping to vastly increase their number of users
within the upcoming year. Among a number of enhancements being
developed, the ability to import CCRs is one of the most important. In
addition, they would like to have a full list of functionality including
insurance and medication history data. Additional enhancements include
providing users with the option to update their records at any time
(instead of waiting for the automatic synch) and to provide access to
external health information about specific concerns or diseases.

#### Challenges

ODEV2 discussed the challenges of mediating the differences between
patient and provider viewpoints. Providers have many concerns about
allowing the lay person to view their health data and the translation of
health data into common language was listed as an important and
challenging concept. So far, developers have not begun to tackle this
problem though it is widely recognized across the organization.

An additional challenge is finding a balance between privacy and
security concerns and end-user capability. The current system may have a
longer wait time due to high security policies than the average consumer
is willing to accept.

Finally, ODEV2 recognizes the issues that interoperability may bring.
They currently have no way to synchronize with other data
providers---such as hospitals, labs, or pharmacies---but are hoping that
Web services-based architecture will provide a platform for
accomplishing future interoperability. They also recognize that the user
interface will become much more complicated when attempting to display
data in different formats.

## ODEV3

### Description of the Organization

ODEV3 offers its PHR through an academic health care system currently
seeing approximately 100,000 ambulatory patients per year within a
defined geographic area. They estimate that around 24,000 patients are
actively using the personal health record product. The organization is
interested in all aspects of promoting education and knowledge transfer,
working closely with regional and nation wide initiatives. The PHR is
free to all patients of the health system, recognizing that the
integration optimizes workflow for providers and reduces overall
healthcare costs.

### Description of the Architecture

ODEV3 built their own EHR and CPOE applications and had considerable
development experience to apply to the PHR. One of their main goals in
building the PHR was to provide a secure, triaged messaging capability
between patient and provider. Integrated within the current EHR was a
physician messaging system, where providers could communicate with other
providers in the healthcare system outside their clinic. It was not a
closed-loop system and messages did not always get to the correct person
or were delayed unacceptably. In addition, providers did not want
messages being routed to them unnecessarily when it would be more
appropriate being sent to a specific staff member for response.

### Approach to Interoperability

#### Current Implementation and Future Vision

To maximize the uptake of the PHR by the staff, ODEV3 built in a
critical mass of functionality, including:

-   Ability to message all providers with accurate responses within 24
    hours;

-   Ability to access almost 100% of lab and test results;

-   Ability to delegate access for any third parties of the users
    choice;

-   Ability to schedule appointments; and

-   Ability to access a list of allergies and medications.

Recognizing that uptake on any new technology can be very low,
management thought that this much initial functionality would convince
users and staff of the immediate and mutual benefits. The main goal was
to improve satisfaction of both parties by providing an interface for
all critical information sharing.

ODEV3 uses APIs for connecting to outside data sources. For internal
data, the PHR was fully integrated with their proprietary EHR and CPOE
systems.

A comprehensive list of possible enhancements has been made in order to
obtain fully benefit from its PHR. In the near future, developers are
working on projects that would allow patients to enter home recorded
information, delegate different levels of data access to different third
parties, and support alternative languages (e.g., Spanish).

#### Challenges

According to ODEV3, a major challenge to creating interoperable
applications is lack of financial incentives from payers. They are
looking to the Centers for Medicare & Medicaid Services (CMS) to take
the lead in helping health care organizations purchase or develop
interoperable systems. In addition, this Vendor is looking for
communication standards that would allow a more efficient data sharing
process. The current API model is costly, time consuming, and is not
scalable. Finally, this Vendor discussed the multi-faceted issues at
stake when designing a new PHR system. For their application, all
stakeholders from the organization including technical, clinical, and
legal were consulted even during the initial development phases.

## COTS1 

### Description of the Organization

COTS1 is a large and multi-faceted organization with Web-based
strategies focusing on consumers, providers, and payers. Their offerings
include comprehensive health information for consumers, continuing
medical education (CME) for physicians, and benefits management for
payers and employers. They offer a PHR via private portals on behalf of
commercial health plans and employers.

### Description of the Architecture

Vendor chose not to disclose.

### Approach to Interoperability

#### Current Implementation and Future Vision

In its partnerships with health plans, COTS1 is working to bring data
from a variety of sources (e.g., pharmacy, labs, data warehouses) into
the PHR. They use the HL7 messaging standards and are capable of using
both HL7 CDA and ASTM CCR. Using a proprietary system, they transform
complicated claims information, lab results, clinical codes, and health
data into language and format for the consumer.

#### Challenges

COTS1 believes that many of the standards needed for interoperability
already exist and that the ASTM CCR is a good starting point. In
addition, they believe that if every PHR was standard-compliant, there
would be a problem differentiating among products. The way in which a
PHR brings in data, transforms the data, and uses the data to provide
services for the consumer should be how PHR vendors differentiate
themselves.

Other challenges to interoperability for COTS1 are the problems
associated with working with a network of consumers that spans multiple
states. The differences and inconsistencies among state, local, and
federal law could seriously hinder the development of a true, nationwide
network.

COTS1 is very consumer-focused and is concerned that payer and provider
input will crowd out the consumer point of view. They feel that a PHR
that optimizes payer and provider workflow---and one that is optimized
for the end-user experience---are essential for a viable PHR.

## COTS2 

### Description of the Organization

COTS2 has been in the personal health record industry for a little over
10 years. They have created a USB (Universal Serial Bus) key, a desktop,
and an online version of their current PHR product. To date, more than
500,000 users have received one of these products from their providers,
insurance companies, or employers. COTS2 is very focused on this
technology and appears to have a very well-developed solution.

### Description of the Architecture

This vendor's application is a full-featured software program that helps
individuals better manage their health. In addition to the primary
software package, COTS2 provides additional modules including disease
management, drug interactions, and patient education to help meet the
specific needs of their client. All applications are compliant with
Health Insurance Portability and Accountability Act (HIPAA) guidelines
and the USB key comes complete with the software already integrated on
the device. To activate the key on any computer, end users simply need a
USB port. In addition, the patient's PHR can be shared with providers
through point-of-care kiosks, printed reports, and other applications to
meet the specific needs of the provider.

### Approach to Interoperability

#### Current Implementation and Future Vision

This solution is interoperable with both HL7 CDA and ASTM CCR with
robust import and export capability. Data exchange can be accomplished
at the data element level. An automatic synch between the server and the
USB or desktop occurs when the user accesses the online portion of their
product. Currently, the user is not given the choice to not update their
data.

Their developers are in the process of developing a working model for
providing claims data. In addition, they have recently partnered with a
pharmacy clearing house in order to obtain medication history for their
users. It was noted that medication history and other data that are
already aggregated is significantly easier to provide to users than
miscellaneous lab, or radiology reports, for example. This vendor has
also seen an enormous opportunity in providing data to providers from
home monitoring devices.

#### Challenges

One of the main concerns from this provider is the fluidity of standards
within the industry. They mentioned the cost and time constraints when
coding to numerous standards. Like the other organizations with whom we
spoke, they feel the challenges are not technical, but rather in the
policy and standards surrounding interoperability. As an example, they
mentioned the issues surrounding the privacy and security when clinical
data move around a network. In addition, working as an independent
organization, they have found it difficult to partner with laboratories
due to the complicated legal issues involved in releasing data directly
to patients. In their experience, they have observed larger vendors
using the HL7 CDA standard because they already have the resources and
infrastructure to handle the technology. The smaller and newer vendors
tended to use the ASTM CCR standard because of its relative simplicity
and fast implementation.

Home monitoring devices have the potential to improve consumer
healthcare, yet collecting data electronically from theses devices is
difficult. Almost every device uses a different protocol to exchange
data, meaning that if a PHR vendor wants to collect data from a device
or class of devices, they are forced to write a custom interface with
each one.

Finally, this vendor discussed the difficulty in providing a user
interface that was legible for all users. Differences in cultural jargon
(e.g., lockjaw vs. tetanus) and health literacy must be considered when
designing how the data will be displayed to the user.

## COTS3

### Description of the Organization

COTS3 develops a suite of online services that focus on improving
communication between consumers and their healthcare providers. This
vendor has been in the personal health record industry for around five
years and has seen significant progress in uptake of their product. It
has a strong focus on the individual providers' perspective on
communication issues and benefits. This suite of services can be fully
integrated into the providers' workflow as to maximize the benefits and
minimize the disadvantages. Small studies done by COTS3 and partnering
institutions have determined that their service provides specific and
measurable benefits to all stakeholders.

### Description of the Architecture

COTS3 markets their solution to group practices, health systems,
hospitals, and payers. They are an Application Service Provider (ASP)
and host the data at very low cost to the provider. They can exchange
data with EHRs and support both HL7 CDA and ASTM CCR. Automated patient
education is provided based on a patient's diagnosis. COTS3 is candid in
asserting that the first problem they wanted to solve was to "replace
the clipboard" that every consumer encounters with each provider.

### Approach to Interoperability

#### Current Implementation and Future Vision

Upon user registration, the service begins to immediately push out
relevant health information from credible external data warehouses, such
as the American Medical Association (AMA) and the Centers for Disease
Control and Prevention (CDC).

Key demographics or elements of a user's PHR profile can be used to
tailor users' experiences. The functionality available to the consumer
includes the ability to:

-   Locate provider contact information;

-   Manage and control access to Protected Health Information (PHI);

-   Streamline the registration process and procedures;

-   Send secure automated messages between provider and patient;

-   View external health information (e.g., Food and Drug Administration
    medication warnings and recalls, health assessments);

-   Process secure online bill payments;

-   Send prescription renewal requests; and

-   Facilitate online doctor patient consultation services.

They are currently developing capability to import lab, radiology, and
discharge summaries but have not seen significant market demand for
these services.

#### Challenges

From their view of the market, COTS3 has not seen much demand or uptake
of interoperability in PHRs. It is their view that the provider is the
critical component to the success of PHRs. In addition, they feel that
the current discussions around PHRs do not consider the fundamental
views and behaviors of the average consumer. Due to the low uptake
rates, they do not believe the technical complications are the most
critical issues regarding interoperability and PHRs.

COTS3 also mentioned the quality of user-entered data as an issue. It is
unclear if providers will want user-entered data to be imported into the
providers' EHRs.

## DATA1

### Description of the Organization

DATA1 functions as a very large router, connecting physicians, patients,
and payers to facilitate electronic prescribing. Through their network
they are able to electronically route patient medication history to
providers at the point of care. Providing current, electronic patient
information at the point of care improves safety and efficiency by
reducing errors and adverse drug events. DATA1 does not have a
consumer-facing strategy at this time and does not foresee such a
strategy in their future.

### Description of the Architecture

DATA1 does not store any user data. They maintain a master patient index
(MPI) that uniquely identifies a patient which they use to access
patient information held by payers. Security and authentication are
managed on the payer side. Once the patient data are located, it is
aggregated and sent to the source requesting the service. The data
provider has worked with the sources to identify proper integration with
the workflow processes to ensure maximum benefit and minimum
inconveniences.

### Approach to Interoperability

#### Current Implementation and Future Vision

The current application supports the National Committee on Vital and
Health Statistics (NCVHS) transport standards.

DATA1 is certain that medication data will have a place in any future
PHR initiative. They are actively investigating strategies to partner
with PHR vendors in pre-populating PHRs with medication data. In
addition, they are focused on being the conduit in any EHR/PHR scenario
using the payer's data and the provider's authentication model.

#### Challenges

In considering a role in the PHR market, DATA1 is concerned about
security and privacy as patient data move along the network. They are
also aware that they do not own any patient data and that the owners
(i.e., payers) will have to be a part of any PHR interoperability
effort. And, since DATA1 does not interact with consumers at this time,
they understand that participating in the PHR market would require the
development of end-user interfaces and perhaps software to translate
drug codes to names that end users understand.

## DATA2

### Description of the Organization

DATA2 provides an electronic prescribing network that enables the
electronic exchange of prescription information between physicians and
pharmacists. DATA2 was founded and is funded by pharmacy organizations.
DATA2 does store some patient data but the data are owned by the
pharmacy.

### Description of the Architecture

Working with such a variety of partners, this organization has a
technically flexible output; however, they indicated that their data
maps well into the ASTM CCR.

### Approach to Interoperability

#### Current Implementation and Future Vision

In addition to acting as a communication network between payers and
providers, DATA2 also has developed relationships with software
companies and PHR vendors to develop pilot initiatives related to
interoperability.

This organization does not plan to have a direct consumer strategy.
Currently it plans to maintain relationships with vendors and providers,
not consumers. They do envision, however, that all PHR requests for
prescription information that come from their partners will go directly
though the organization.

#### Challenges

As a data provider accustomed to well-defined standards for data
transport, DATA2 would like to see the same for all standards related to
PHR interoperability. In addition to a lack of clearly defined
standards, DATA2 mentioned the problem of having to code to different
versions of standards.

# Conclusions

The full potential of PHR systems will not be realized until they are
capable of widespread exchange of information with HIT sources. The
cases we examined offered multiple workarounds to the current problems
of interoperability, with different potential outcomes.

The development of high-functioning, proprietary portals attached to
specific EHR or hospital information systems is one such approach. It
may offer a strong interim solution as long as patients are willing to
overlook the problem of data mobility from providers outside the group
or hospital. For many patients this may well be a valid case.

A second, more robust, model of information exchange was also seen. In
this model, open document standards (i.e., CCR, CDA) are used as a
medium of exchange between source HIT systems and the PHR, and from the
PHR to any other system. While continuing to rely on the widespread
availability of those source systems, it offers a pathway to the future
that the single portal approach does not.

With all of these caveats, we do find many robust PHR implementations
under way in a variety of local settings or within constrained
populations. The use of Web services with rich metadata appears to be a
promising technical approach to resolving many interoperability issues,
for example by obviating the need for data storage standards, or, in
some cases, content standards as well.

Finally, none of these technical approaches can answer more fundamental
questions of business models for information exchange. Nor can they
address the environmental issues that span technology and policy and
include the legal status of PHRs, provider's acceptance and use of
patient-entered data, reimbursement, privacy, and business process
re-engineering. These emerging issues will play out in a much different
arena---that of politics, interest groups, and the law. It is at least
possible that control over information via PHR may create new avenues
for individuals to seek and receive care---outside the current
healthcare system---and that these avenues will create conflict as well
as potential for growth and new market channels for physicians and other
care providers.

[]{.mark}

# Appendix A: Levels of Interoperability {#appendix-a-levels-of-interoperability .unnumbered}

+--------+-------------------------------------------------------------+
| Inte   |                                                             |
| ropera |                                                             |
| bility |                                                             |
| Fra    |                                                             |
| mework |                                                             |
|        |                                                             |
| Health |                                                             |
| Care   |                                                             |
| Infor  |                                                             |
| mation |                                                             |
| Ex     |                                                             |
| change |                                                             |
| and    |                                                             |
| Inte   |                                                             |
| ropera |                                                             |
| bility |                                                             |
| (HIEI) |                                                             |
+--------+-------------------------------------------------------------+
| Level  | Scope                                                       |
+--------+-------------------------------------------------------------+
| 1      | **Non-electronic data exchange and no use of IT**. Examples |
|        | include mail and telephone                                  |
+--------+-------------------------------------------------------------+
| 2      | **Machine-transportable data**---non-standardized data      |
|        | transported via basic IT with no data manipulation.         |
|        | Examples include fax, computer-based exchange of pictures,  |
|        | scanned documents or PDF.                                   |
+--------+-------------------------------------------------------------+
| 3      | **Machine-organizable data**---structured messages          |
|        | containing non-standard data requiring interfaces to        |
|        | translate but can still be misinterpreted. Examples include |
|        | e-mail messages of free text or computer-based exchange of  |
|        | files in proprietary or incompatible formats.               |
+--------+-------------------------------------------------------------+
| 4      | **Machine-interpretable data**---structured messages        |
|        | containing standardized and coded data where all systems    |
|        | use the same formats and vocabularies. Examples include an  |
|        | automated exchange of coded results from an external lab    |
|        | into a provider's EHR then sent to the patient's PHR and    |
|        | translated for viewing depending on the patient's level of  |
|        | health literacy.                                            |
+--------+-------------------------------------------------------------+
| W      |                                                             |
| alker, |                                                             |
| J., E. |                                                             |
| Pan,   |                                                             |
| et al. |                                                             |
| *The   |                                                             |
| Value  |                                                             |
| of     |                                                             |
| Health |                                                             |
| Care   |                                                             |
| Infor  |                                                             |
| mation |                                                             |
| Ex     |                                                             |
| change |                                                             |
| and    |                                                             |
| Intero |                                                             |
| perabi |                                                             |
| lity*. |                                                             |
| Health |                                                             |
| A      |                                                             |
| ffairs |                                                             |
| Web,   |                                                             |
| W5-10  |                                                             |
| --     |                                                             |
| W5-18, |                                                             |
| J      |                                                             |
| anuary |                                                             |
| 19,    |                                                             |
| 2005.  |                                                             |
+--------+-------------------------------------------------------------+

Levels 1 and 2 are in common use today, particularly telephone and fax.
Basic e-mail (Level 3) between consumer and provider is being used but
is still considered new. Many providers are wary of e-mail due to
unresolved privacy, liability, and reimbursement issues. While certainly
an advance over telephone and fax, Level 3 interoperability is heavily
dependent on the development of custom interfaces. And, since Level 4 is
the ultimate goal, the money invested in custom interfaces with a
limited life span would be better spent on trying to achieve a Level 4.

# Appendix B: HL7 Clinical Document Architecture (CDA) and ASTM Continuity of Care Record (CCR) {#appendix-b-hl7-clinical-document-architecture-cda-and-astm-continuity-of-care-record-ccr .unnumbered}

The bulk of the clinical content of the paper-based record consists of
loosely structured handwritten notes. The format (paper) and the content
(handwritten) make these notes extremely difficult to share even among
clinicians. Sharing health care data among independent sites is a key
component to improving health care and paper-based medical records are a
significant impediment to the advancement of this goal. Replacing
paper-based medical records with an electronic document is a clear
solution, but putting a rigid structure around a clinical
narrative---particularly a structure that all stakeholders agree on---is
complex. Two standards that produce the interoperability to support the
exchange of data are the HL7 Clinical Document Architecture (CDA) and
the ASTM Continuity of Care Record (CCR).

**Clinical Document Architecture** (CDA) is a Health Level 7 (HL7)
standard derived from the HL7 Reference Information Model (RIM). It is a
document markup standard that defines the structure and meaning of a
clinical document for ***the purpose of exchange.***[^8] CDA documents
are marked-up (encoded) in Extensible Markup Language (XML). XML
documents are defined by schemas and CDA documents have very
well-defined schemas such that both senders and receivers can understand
both the ***structure*** and ***meaning*** of the document being
exchanged.

A CDA document consists of a *header* and a *body*. The header carries
identifying information including date, time, patient, and provider
while the body contains---at a minimum---the clinical narrative which is
the human readable content to be displayed through the recipients' Web
browser (***syntactic*** interoperability). The CDA is designed to
handle all types of clinical documents such as progress notes, discharge
summary, or consultation using medical vocabulary that guarantees
semantic or human interoperability at the clinician to clinician level.

The content in the narrative can be extracted and further encoded within
well-defined XML tags using accepted data standards (ICD-9/10, LOINC,
SNOMED CT, etc.). Documents coded this way have achieved ***computable
semantic*** interoperability---unambiguous exchange of data at the
machine level.[^9]

The **Continuity of Care Record** (CCR) is an ASTM International
Standard initially designed as a document container to collect a nucleus
of structured patient information that is human-readable for electronic
transmission among clinicians. It is intended to provide consulting
physicians enough information to participate in a patient's care. In
relation to an EHR, the CCR is a data extract that creates a patient
summary or snapshot. Like the CDA, CCR documents are XML encoded.
Structured to be human-readable and easily transferable, the CCR is
designed to contain relevant and timely health information relevant to a
patient's current medical condition.

The CDA is based on the formal HL7 Reference Information Model and
supports the broad range of clinical document types including radiology
reports, progress notes, discharge summaries or procedure reports. The
CCR, on the other hand, is intended for the exchange of health summaries
and does not explicitly support other document types.[^10]

PHRs must ultimately transmit and accept structured data in order to
become commonly accepted for information exchange between individuals
and clinicians. PHRs are unlikely to be embraced by either health
professionals or the public if they overload either party with
unstructured data.

As a model for the exchange of data among EHRs and PHRs, the CDA comes
much closer than the CCR since it defines multiple clinical document
types in its native state. Further, the CDA is extensible and additional
document types or elements can be defined locally and still be compliant
with the HL7 model. The CCR is based on a single data model and does not
provide or allow local extensions. If a local health care organization
needs additional capabilities from the CCR, they would have to deviate
from the CCR standard and create their own extensions in XML which would
only serve to re-introduce the current problem of proprietary solutions
that are not interoperable.

Appendix C: List of Acronyms

  ------------------ ----------------------------------------------------
  AHIC               American Health Information Community

  AMA                American Medical Association

  API                Application Program Interface

  ASP                Application Service Provider

  ASTM               American Society for Testing and Materials

  CCR                Continuity of Care Record

  CDA                Clinical Document Architecture

  CDC                Centers for Disease Control and Prevention

  CE                 Consumer Empowerment

  CME                Continuing Medical Education

  CMS                Centers for Medicare & Medicaid Services

  COTS               Commercial Off-The-Shelf

  CPOE               Computerized Provider Order Entry

  EHR                Electronic Health Record

  ELINCS             EHR-Lab Interoperability and Connectivity
                     Specification

  Gnu LGPL           Gnu Lesser General Public License

  HIPAA              Health Insurance Portability and Accountability Act

  HL7                Health Level 7

  ICD                International Classification of Diseases

  ISP                Internet Service Provider

  IT                 Information Technology

  MPI                Master Patient Index

  NCVHS              National Committee on Vital and Health Statistics

  ONC                Office of the National Coordinator for Health
                     Information Technology

  PHI                Protected Health Information

  PHR                Personal Health Record

  RIM                Reference Information Model

  US                 United States

  USB                Universal Serial Bus

  XML                Extensible Markup Language
  ------------------ ----------------------------------------------------

[^1]: HIMSS Electronic Records Vendors Association (EHRVA). *EHRVA
    Interoperability Roadmap*. Healthcare Information and Management
    Systems Society (HIMSS), Version 2, October 2006. www.himsserhva.org

[^2]: Mead*,* C. *Data Interchange Standards in Healthcare IT --
    Computable Semantic Interoperability: Now Possible but Still
    Difficult. Do We Really Need a Better Mousetrap?* Journal of Health
    Information Management 20.1 (2006): 71-78.

[^3]: Detmer D. *Building the National Health Information Infrastructure
    for Personal Health, Health Care Services, Public Health and
    Research*. BMC Medical Informatics Decision Making 3.1 (2003): 1-12.

[^4]: Tang, P., J. Ash, et al*. Personal Health Records: Definitions,
    Benefits, and Strategies for Overcoming Barriers to Adoption*.
    Journal of the American Medical Informatics Association 13.2 (2006):
    121-123.

[^5]: Altarum Institute (2007) "PHR Privacy Briefing," January 10, 2007.
    www.hhs.gov/healthit/ahic/materials/01_07/ce/Chin.ppt

[^6]: Briggs Bill (2006) "Payers Are Driving e-Prescribing" *Health Data
    Management* May 2006, accessed online at
    http://www.healthdatamanagement.com/html/current/CurrentIssueStory.cfm?articleId=13352

[^7]: See, for example, the American Society for Clinical Laboratory
    Science position paper "Consumer Access to Laboratory Testing and
    Information" dated July 2004, http://www.ascls.org/position/DAT.asp

[^8]: Dolin, R., L. Alschuler, et al. *HL7 Clinical Document
    Architecture, Release 2.* Journal of the American Medical
    Informatics Association 13.1 (2006): 30-39.

[^9]: Mead*,* C. *Data Interchange Standards in Healthcare IT --
    Computable Semantic Interoperability: Now Possible but Still
    Difficult. Do We Really Need a Better Mousetrap?* Journal of Health
    Information Management 20.1 (2006): 71-78.

[^10]: Ferranti, J., C. Musser, et al. *The Clinical Document
    Architecture and the Continuity of Care Record: A Critical
    Analysis*. Journal of the American Medical Informatics Association
    13.3 (2006): 245-252.