# Presentation: 887599

## Preliminary Results of the PHR Market Scan

*Presentation to the American Health Information Community, November 6, 2006*

## Purpose

- Under contract to ONC HIT to review PHR market and disseminate findings
- Provide data to help inform discussion
- Not scientific survey but a market scan
- Phase 1: contact as many vendors as possible as part of AHIC invitation for public participation
- Unstructured data collection with some guiding questions
- Phase 2: select vendors into three groups for structured data collection
- Examine functionality, business models, privacy/security/confidentiality
- Consumer focus groups to determine reaction and requirements
- Not yet underway
- Study interoperability/interconnectivity among current products
- Not yet underway

## Sampling Design

- 89 vendors initially identified in Phase 1
- AHIMA MyPHR website, stakeholder discussions
- Attempted to reach everyone identified in frame
- Initial email September 17th
- Follow up telephone call to all nonresponders (began October 2nd)
- 13 vendors identified as no longer in business
- Data simultaneously pulled from public web sites, publications
- Verbose descriptions provided, also some interviewed via telephone
- Data collection period closed October28th
- 24 out of 76 active vendors participated
- Data also collected on additional 49 vendors
- Sampling properties of resulting data are unknowable
- Statistical analysis relies on random selection and random non-response
- Here we have no way of knowing the relationship between our sampling frame and the true population universe, or between respondents and the true universe
- But we gain insight from those willing to respond
- Consumer-based focus groups in coming months

## Flow Chart of Phase 1

## Data Collection

## Phase 2 Panel Selection

**Criteria Used for Selecting Panel Participants**
- The process of panel selection took into account the following general considerations:
-  Had the vendor indicated a willingness to provide further detail?  If yes, it warranted a panel inclusion.
-  Did the vendor’s response to Phase 1 provide sufficient detail such that Altarum analysts could answer the panel questions?  If yes, it warranted panel exclusion.
- In addition, the following individual considerations were used to select representative vendors for inclusion.

| 
Panel | 
Critical Concept |
| --- | --- |
| Functionality | Market share (equivalent to probability-weighted sampling on population) |
| Business Model | Multiple targeted market segments; Multiple marketing practices |
| Confidentiality, Privacy, Security | Multiple architecture types |

## Flow Chart of Phase 2

- Complete
- Responses?

- Y

- CONTINUING FROM PHASE 1

- Enter detailed
- answers
- into DB

- Y

- In-depth follow-up
- with vendor
- (detailed email/
- phone consultation)

- ID vendor
- for panel

**E-mail Request **
**for Panel **
**Participation**

- Answer
- Questionnaire?

- Y

- N

- Information on
- Website?

- Review info on website and populate DB

- Y

- No Information from Vendor Collected

- N

- N

- N

## Preliminary Findings

## Architecture Type

| Architecture Type | Description |
| --- | --- |
| Standalone | Depends solely on patient input as a conduit for transmission of medical record data.  This includes paper-based PHRs; PC-based and portable-storage PHRs where the member can carry data on a portable device (e.g., CDROM, DVD, smart card, or USB flash drive); and, Web-based PHRs where the data is housed separately and is not connected to or updated by another data system. |
| Tethered | Provides read-only access to one or more data systems; akin to a “viewer” of health records or health claims data.  Data entered by the patient is not pushed or pulled into another data system (e.g., an EHR) and can only be viewed through the PHR. |
| Integrated | Provides read and write access to one or more data systems; may include data-level integration across systems and/or may be viewed through other non-PHR interfaces (e.g., an EHR). |

## Architecture Type 

## Architecture Type

## FunctionalityType of Stand-alone PHR

## Functionality

| Functionality | Definition |
| --- | --- |
| Appointment Scheduling | Can the PHR allow the consumer to schedule appointments (e.g. view open dates and times)?  This would not include emailing the provider with available dates and times. |
| Deductible/Co-pay Tracking | Does the PHR allow the consumer to keep track of how much they have paid into their health insurance deductible or the total amount they have paid in co-payments? |
| Discharge Instructions | Does the PHR capture patient specific discharge instructions? |
| Multiple Languages | Does the PHR have the ability to be translated into languages other than English? |
| Multiple View | Does the PHR support multiple views of the data it contains (e.g. does it present information differently to providers)? |
| Online Communication Ability | Does the PHR support online communication between the patient and the provider (secure messaging or email)? |
| Patient Education Information | Does the PHR show other types of patient information (e.g. educational materials, information on over the counter or alternative drugs/therapy, or links to health care information on the internet)? |
| Patient Outcomes | Does the PHR capture patient self-reported outcomes (e.g. reaction to drugs, whether or not the consumer’s condition is improving)? |
| Patient Reminders | Does the PHR give patient reminders for appointments or wellness checkups (e.g. annual exams, mammograms, immunizations)? |
| Prescription Refill | Does the PHR include the ability to order pharmacy refills? |

## All Architecture Functionality

## Standalone PHR Functionality

## Tethered PHR Functionality

## Integrated PHR Functionality

## Data Elements

| Data Elements | Definition |
| --- | --- |
| Advance Directives/Living Will | Can the PHR store information such as advance directives or living wills? |
| Allergy History | Can the PHR capture allergy history (e.g., medication, food, environmental, insect)? |
| Condition History | Can the PHR capture condition history? |
| Demographic Data | Can the PHR capture demographic data (e.g., age, sex, date of birth) |
| Encounter History | Can the PHR capture encounter history (e.g., office visits, ER visits)? |
| Family History | Can the PHR store family medical history? |
| Free-text Documentation | Does the PHR allow consumers to store free-text writing (e.g., medical journal/diary)? |
| Home Monitored data | Can the PHR capture consumer self-reported home monitored information (e.g., blood pressure, glucose monitoring) |
| Immunization History | Can the PHR capture immunization history? |
| Insurance Information | Can the PHR store insurance information (e.g., contract numbers, contact number, type of insurance)? |
| Laboratory Results | Can the PHR store the results from laboratory tests? |
| Lifestyle/behavioral data | Can the PHR capture consumer self-reported lifestyle/behavioral information (e.g., exercise, diet)? |
| Medication History | Can the PHR capture the consumer's medication history (e.g., date and dose)? |
| Procedure History | Can the PHR capture the types and dates of the consumer's procedures (e.g., surgical)? |

## Data Types

## Standalone PHR Data Elements

## Tethered PHR Data Elements

## Integrated PHR Data Elements

## Marketing PracticesTarget Markets

## Marketing PracticesNumber of Targeted Markets

## Pricing PracticesConsumer Fee Types

## Pricing PracticesDistribution of One Time Fees

## Pricing PracticesDistribution of Yearly Fees

## Pricing PracticesFee Type by Architecture

## Critical Success Factors

## Privacy & Confidentiality ConceptDefinitions

| Privacy & Confidentiality Concept | Definition |
| --- | --- |
| Access Based on Role | Does the PHR divide users into groups or classes (such as family members, health professionals, etc.) and restrict data visibility based on rules that are specific to each group? |
| ER Access | Does the PHR provide a means for access in an emergency? |
| Family Access | Is there a way that family members who participate in the account holder's care can be authorized as a proxy to view or change data? |
| Individual Access | Can this PHR provide different access levels for different individual providers?   |
| Policy - Privacy | Does your organization have PHR-specific privacy/confidentiality policies in place?  |
| Policy - Privacy Available to Consumer | Can the account holder or other users view or print the privacy policy? |
| Restrict Certain Data from View? (Block view) | Can the account holder restrict certain data items from view (such as certain meds, or encounters with a certain health professional)? |
| Sensitive Data Separation | Because data about mental health and substance abuse, reproductive health, etc. are often sensitive, does the PHR sequester this data in its design? |

## Privacy and Confidentiality Attributes

## Security Concept Definitions

| Security Concept | Definition |
| --- | --- |
| Encryption | Are the data in the PHR encrypted in some fashion? |
| Log or Audit Trail - Access | Does the PHR keep an audit trail of all access events?  Access events primarily include access (screen display or printing) and export or data sending. |
| Log or Audit Trail - Data Update | Does this PHR keep a log or audit trail of all data updates?  Data updates include those by a user (e.g. patients, health professionals) as well as data imported from outside sources. |
| Policy - Security | Does your organization have PHR-specific security policies in place? |
| Policy - Security Available to Consumer | Can the account holder or other users view or print the security policy? |
| Separate Physical Data | Is the primary storage for the account holder's PHR data on a device (including PDAs, smart cards, USB, paper, etc.) as compared to, an internet or database server? |
| Synchronize Data/Back-up Mechanisms | Is there a mechanism to synchronize or store a copy of the data to protect against possible loss? |
| User Authentication | Does this PHR support authentication of specific users?  That is, does it have a mechanism to require that a user who tries to sign in gives some evidence that they are indeed that person? |

## Security Attributes

## Questions?

- Stanley Chin
**Director, Practice Development**
- Phone: (703) 575-1716
- stanley.chin@altarum.org
- Robert Lecker
**Director, Informatics**
- Phone: (703) 575-1691
- robert.lecker@altarum.org
- Dan Armijo
**Deputy Director, Informatics**
- Phone: (734) 302-4636
- dan.armijo@altarum.org