# Presentation: 890463

## Review of the Personal Health Record (PHR) Service Provider MarketInteroperability and Data Mobility

*Stanley Chin*
*Altarum Institute*
*May 2, 2007*

## Overview

- Asked to examine current status of PHR interoperability and data mobility
- Case study approach taken
- Eight organizations interviewed in depth, December 2006-January 2007
- Three COTS vendors of products, three internally developed systems, two commercial data providers
- Cases have been anonymized to protect against release of potentially proprietary information
- Two dimensions of PHR interoperability
- Can PHRs import or export data to/from EHR, CPOE, pharmacy, labs, radiology, claims
- Can PHRs be imported or exported among each other
- Identified key barriers and enablers for interoperability

## Key Enablers

- Existing business models supporting standardized data and electronic data interchange e.g. claims, pharmacy
- Where data are already flowing, the PHR can be used to tap into these flows for rapid pre-population of important information
- Service oriented architecture
- Use of technologies that support shared services with rich metadata, to shield interfacing applications from details of underlying data model
- Use of existing document formats
- Clinical Document Architecture, Continuity of Care Record are both in use separately and in emerging joint Continuity of Care Document
- As a result of their architecture, may be easier to move data from one PHR to another than to import from an EHR!

## Key Issues and Challenges

- Can all participants share financial or other incentives for exchanging health information
- PHRs currently lack sufficient market pull to induce source systems to become more interoperable
- What about data originating from outside formal care settings?
- Can business rules regarding confidentiality of data also be made portable or otherwise attach to the data as it flows
- Can legal, ethical, policy, and business issues be resolved regarding the release of clinical data directly to a patient, e.g. lab values (with delay or approval of ordering physician?), consult notes
- Can workflow be rethought to accommodate patient-sourced or initiated information
- Technical interoperability of PHR to EHR useless if physician does not trust data

## Use of Clinical Document to Enforce Content Standards Creates Interoperable PHRs 

## Types of Source Data and Interoperability Issues 

| Source | Interoperability Level | Issues |
| --- | --- | --- |
| Claims Data | High -- large volumes of electronic data exist; interchange standards exist for EDI, claims attachments, and use in PHR (AHIP) | Very large existing datasets with records for most clinical encounters |
|  |  | ICD-9 codeset lacks granularity in diagnoses and procedures |
|  |  | Claims attachments may contain important ancillary results |
|  |  | Data quality of clinical information unknown until examined |
|  |  | Never intended for clinical interpretation |
| Prescription data | High -- NCPDP SCRIPT standard for CPOE identifies healthcare provider, pharmacist, patient, drug; NDC codes identify drugs; RxNorm standardizes drug names | Patient cannot directly electronically order refills, must pass through existing manual process or trigger a physican order |
|  |  | 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 data | Poor -- Lack of interlinked systems; ELINCS just emerging as standard for reporting results, no standards for lab orders | Patient cannot directly receive lab reports, must pass through ordering physician for review |
|  |  | Lack of CPOE systems to external labs; hospital clinical systems may capture hospital labs and results |
| Radiology reports | Medium -- systems are largely digital with DICOM standard for imagery but lack of standards for orders and results reporting | No consensus on appropriate content for end consumer |
|  |  | Image files are very large |
| Clinical notes (EHR SOAP notes, referral note, problem lists, etc.) | Poor -- Needs source EHR; SNOMED exists for structured notes | Business rules on release of physician notes to patient are not well developed |
|  |  | Clinical documentation tends to be highly physician idiosyncratic |
|  |  | Usability of clinical information unknown to consumer |
| History and Physical | Poor -- largely free text | Patient can enter own history via kiosk or standalone PHR |
|  |  | Many critical concepts are not clinical and do not have content standards (food allergies, exercise history, family history) |
| Home Health Monitoring Devices | Poor -- no standards for device communications, data formats or content | Emerging market, not in common use |
|  |  | Obvious need for standards development |

## Questions?

- Stanley Chin
**Director, Practice Development**
**Phone: (703) 575-1716**
**stanley.chin@altarum.org**
- Dan Armijo
**Deputy Director, Informatics**
**Phone: (734) 310-4636**
**Dan.Armijo@altarum.org**