ABBI+Payor+Content+Interim+Guidance

include component="page" wikiName="siframework" page="ABBI Header"

Summary
This guide was developed by the Automated Blue Button Initiative (ABBI) Payer Content Subworkgroup 2012-2013.
 * 2013 Interim Recommendations for Interoperable Blue Button Content Structure for Health Insurers, Pharmacy and other non-EMR Data Holders**.

Target Audience
This Interim Guidance is intended for Health Insurers, PBMs, Pharmacies and other non-EMR Data Holders, as well as developers understanding the structure and content of Blue Button structured data supplied by these types of entities.

Guide Status
In January 2013, this Interim Guidance was drafted and made publicly-available for comment, revision and education of the data holder & developer communities on the S&I Framework Wiki. The version here represents the compilations of the initial draft and reconciliation of comments and suggested revisions.

> ==How to Make Comments and Revisions== > Click the toggle links below to provide and/or view comments and suggested revisions (comments may take a moment to appear in the responses suggestion. Refresh your browser to view your comments). Alternative methods of providing feedback include: > * Click on "Edit" on the wiki (when logged in)and make revisions/additions > * Email henry.wei@va.gov with comments & revisions to be added, by Monday January 21st) > media type="custom" key="21919576" > media type="custom" key="21937940" > **SHORTCUT** to Recommended Blue Button Formats for Payers, PBMs, and other non-EMR data holders

Table of Contents
flat =__Summary Recommendations (Interim)__=

=
Blue Button files from health plans are typically derived from administrative claims databases, as well as self-entered data from online Personal Health Records. Data made available to patients via Blue Button+ should be:======

=
The Blue Button+ file should also include, as possible, interoperable **data elements** as covered in Recommended Data Fields and Concepts section. The base set of data fields included is file should be as consistent as possible with the data represented in the MyMedicare.gov Blue Button file. Additional fields (e.g. for wellness programs) were also recommended by the group and detailed below. These include fields to describe the patient, payer coverage, provider(s), and codified claims history (including medication where possible).======

Several options for formatting are currently possible. Each options is described below and detailed elsewhere in this guide, with the potential strengths and limitations of each choice described.

__//**Summary of Blue Button+ format options (note: multiple options can be offered simultaneously):**//__


 * 1. ASCII Plain Text Format** : the Blue Button file should ideally start with representing data fields currently shown in the MyMedicare.gov Blue Button file. The actual visual layout may differ, however plans are encourged to provide sample files and details of data fields supported if alternate structures are provided. Special note: the MyHealthEVet Blue Button file format from the Department of Veterans Affairs presents clinical data in another format, however was originally derived from clinical data rather than payer-based data, does not contain codified data, and is not recommended for interoperability purposes (but rather human-readability, basic Blue Button "non-plus" application).


 * 2. CDA-formatted XML** : for plans seeking to give consumers a file that can interoperate with clinical systems, Consolidated CDA (C-CDA) XML files should be offered, ideally in a Continuity of Care Document template (CCD). As at present there is no formal HL7 implementation guide, however several interim options and mappings are presented below, along with sample disclaimer text for consumers to understand the limitations of claims data relative to point-of-care clinical data. C-CDA files should be validated against NIST tools as well as semantic validators (e.g. http://ccda-scorecard.smartplatforms.org/ ).


 * 3. "Lightweight" XML or JSON and HL7 Fast Healthcare Interoperability Resources (FHIR)** : for plans seeking interoperability with mobile applications and RESTful APIs, FHIR-style XML and/or JSON documents may be offered. The FHIR specification patient, coverage, provider, and claims resource offer a promising way to approach this. Although this is a standard under development due to emerge in 2013-2014, because of the limitations of CDA in represent personal health financial data, it provides a method to express these EOB (Explanation of Benefit) type of data in a structured and open fashion. (See also a simplified XML and JSON representation, below.)

No currently-existing standard is ideal for all of the available data, nor all the use cases, particularly to represent personal health financial data ("EOB" content). A new standard common format is most likely needed in order for payers to represent EOB-like data for consumer applications (as opposed to payer-provider transactions). Future implementation guidance should be updated with an consumer claims-derived data standard (EOB-like) as soon as possible.


 * Blue Button+ Simplified XML and JSON**: As a starting point for future standards-development processes, or for organizations who wish to innovate ahead of the standards development process, an example open Blue Button+ simplified XML and JSON representation of MyMedicare.gov data elements is provided for reference and potential interim application. For example, organizations seeking to develop mobile application ecosystems may wish to consider this format.

Additional proprietary or closed data exchange formats and platforms also exist for health plan data interoperability with consumer-facing applications, including consumer health financial data, but are not detailed here. These were explored and discussed by the subworkgroup, and include Microsoft Healthvault, Dossia, and Intuit/Optum Open Medical Exchange Platform. =Background and History= After its launch in 2010, the Blue Button text file heralded a milestone in making digital health data available to all Americans. At the same time, although the plain-text file was originally intended to signify that patients’ access had higher priority than interoperability, it inadvertently became a “standard”. Two primary examples have emerged:
 * 1) The MyHealthEVet Blue Button file, generated from the clinical data as well as self-entered data from the patient portal from the Department of Veterans Affairs
 * 2) The CMS MyMedicare.gov Blue Button, generated from the claims data and self-entered data of the beneficiary portal

In December of 2011, the U.S. Office of Personnel Management also reinforced the need for Blue Button downloads by issuing a Carrier Letter, calling upon health plans for federal employees & dependents to make the Blue Button download available for their members.

In 2012, Americans’ access to Blue Button data grew rapidly to 80-90 million eligible lives, primary through health insurer-based member portals such as those of Aetna and UnitedHealth. Usage exceeded one million unique users in the MyHealthEVet system. Approaching 2014, Americans’ access to Blue Button is expected to grow even further through two main channels:

=Issues and Interim Approach= This section focuses on Insurer, PBM, pharmacy & other non-EMR data holder issues and the proposed interim approach. Meaningful Use creates a compelling case for EMRs to generate data as an interoperable consolidated CDA document/file. However, for non-EMR-based data holders, there are four main complications that make a standardized approach problematic:
 * 1) Providers using electronic medical records wishing to qualify for Meaningful Use incentives will be required to provide “View, Download, and Transmit” (VDT) capabilities. While VDT is not synonymous with Blue Button, the Automated Blue Button Initiative (ABBI) sought to establish a common framework by which not only could providers fulfill the VDT requirement, but enable a consumer-friendly use case. The key difference between VDT and ABBI is the intent for patients could use their health data interoperably with other providers, caregivers, applications and services, and also for patients to have more automated ways to access and transmit the data, particularly to consumer endpoints such as personally-controlled health records (PCHRs). Automation would thus reduce the barriers to consumer use of their health data, by offering more seamless ways to either “push” the data from a patient portal to a destination of the patients’ choosing, using the Direct protocol, or else by programmatic access through a secure authentication mechanism (e.g. OAuth) and more modern data interfaces (e.g. RESTful API).
 * 2) More Health insurers and other health data holders will come online with Blue Button download offerings to help meet the needs of their patients and members.
 * 1) Consolidated CDA is oriented around data generated in clinical environments rather than administrative claims environment. Although there is a wealth of clinical value from the diagnosis, procedure and pharmacy codes used in administrative claims data, health insurers and other data holders are often missing the other data fields required to populate consolidated CDA documents.
 * 2) Consolidated CDA was not designed to accommodate certain data fields of value to consumers that insurers, PBMs and other non-EMR data holders may offer, including the health financial cost details of the billed, allowed, paid charges as well as the remaining patient responsibility. These types of financial data, typically found on a paper consumer-facing “Explanation of Benefit”.
 * 3) Although interoperability standards have long-existed for non-EMR-based data holders, they are often better fit to enterprise-level transactions (e.g. ASC X12) and not been designed for consumer-facing applications.
 * 4) Most standards development organizations need years-long time and non-trivial funding (direct or indirect) to develop new standards, including discovery, harmonization, reference implementation, and revision.

The intent of the current effort, therefore, is to develop **//Interim//** guidance for non-EMR-based organizations ready to provide Blue Button that may serve three main purposes: =Interoperability as an approach to Human-Readability= The original intent of Blue Button was to enable human-readable, patient-accessible health data downloads. This remains the same, however as the consumer environment has evolved rapidly, the assumptions for file readers have changed. Namely, for non-EMR data holders, the Portable Document Format (PDF) has emerged as a common way of offering downloads in more styled and visually-compelling design – without significant interoperability. It is difficult for PDF files to be able to be loaded into another application and semantically parsed for its content). Two other standards for structured data, XML and JSON, have shown practical utility. Not only can they offer a high degree of interoperability for data, but modern web browsers are able to render XML and JSON, using style sheets, with compelling visual design, without sacrificing access to the machine-interoperable portions of the file. =Recommended Data Fields and Concepts= This section focuses on the recommended data files and concepts to represent in Blue Button files.
 * 1) To give common guidance as to how to generate and structure a Blue Button file in an interoperable format
 * 2) To serve as an accelerant for formal standards development processes


 * Blue Button files from non-EMR sources typically come from administrative claims data, as well as potentially self-entered data on Personal Health Records.**
 * To the extent that data holders already have useful and meaningful health data for consumers' Blue Button files, including from administrative claims data, the following Data Fields are recommended for inclusion in the Blue Button files.**

1. Payer name 2. Payer ID type (e.g. CMS National Plan ID) 3. Payer ID code 4. Plan ID 5. Payer web site 6. Eligibility period start date 7. Eligibility period end date (if applicable) 8. Plan Type (e.g. Medical, Pharmacy, etc.) 9. Primary Insurance vs. Secondary
 * A. Payer & Coverage Information**

1. Patient Name (Last, First) 2. Patient Identifier (e.g. Member ID#)
 * B. Patient Information**

1. Provider ID code (e.g. NPI) 2. Provider Name (Last & First name or organization) 3. Provider web site
 * C. Provider Information (note: may be provided on a claims-level basis)**

i. Claims ID number ii. Date of Service iii. "Procedure" Code Type (e.g. CPT, HCPCS, NDC Rx code, ICD-9 CM procedure) iv. "Procedure" Code(s) v. "Procedure" Description(s) vi. Diagnosis Codes (e.g. ICD-9, ICD-10) vii. Diagnosis Description(s)
 * D. Claims-Level Detail**
 * 1. Claim-level Detail**

i. Provider Charged Amount ("Amount charged") ii. Allowed/Negotiated Amount ("Insurance approved") iii. Paid-to-Provider Amount ("Provider paid") iv. Patient Responsibility ("You may be billed") v. Deductible Amount vi. Coinsurance Amount vii. Copay Amount viii. Coordination-of-Benefits (COB) Amount ix. Adjustments x. Explanatory Codes
 * 2. Health Financial Amounts**

1. Laboratory result data (e.g. LOINC-coded results) 2. Wellness & Care Management Program Alerts & Invitations 3. Security & Authentication Hashes
 * E. Other Health Data Elements found in non-EMR data sources**

This table, kept here for historical purposes, represents an original comparison of options available in late 2012 during the ABBI payer sub-workgroup discovery effort to understand existing standard formats and types of data contained within. NCPDP D.0 || Y || Y || Y || NCPDP D.0 || Y || Y || Y || NCPDP D.0 || Y || Y || Y ||
 * **Option** || **Human Readable** || **Eligibility** || **Provider** || **Rx** || **Diag** || **Proc** || **Financial** ||
 * MyMedicare.gov ASCII || Y || Y || Y || Y || Y || Y || Y ||
 * 835 Remittance (X12) || N || Y || Y || Y
 * 837 Submission (X12) || N || Y || Y || Y
 * Proposed cCDA extension (XML) || N || Y || Y || ? || Y || Y || Y ||
 * Consolidated CDA || N (Y w/ XSLT) || Y* || Y || Y || Y || Y || N ||
 * HealthVault EOB Type (XML) || *** With apps || N? || Y || N || Y || Y || Y ||
 * Intuit Health Expense Format (?) || ? || ? || ? || ? || ? || ? || ? ||
 * Embedded 835 (proposed) || Y || Y || Y || Y
 * Others? (Please propose)** ||  ||   ||   ||   ||   ||   ||   ||

Amount

 * **EOB-type Transaction Data : Amounts** || **X12 Transaction Set : Loop 2100 CLP (Data Element 782)** || **HealthVault (XML) explanation-of-benefits.ClaimAmounts** || **MyMedicare.gov ASCII Claim Summary Section** ||
 * Provider Charged || CLP03 Total Claim Charge Amount || charged-amount || “Amount Charged:” ||
 * Allowed/Negotiated || Calculated from CAS03 claims adjustment amount || negotiated-amount || “Medicare Approved” ||
 * Paid to Provider || CLP04 Claim Payment Amount || benefits-paid || “Provider Paid” ||
 * Patient Responsibility || CLP05 Patient Responsibility Amount || patient-responsibility || “You May Be Billed” ||
 * Copay || //(to be completed from CAS segment?)// || copay || ? ||
 * Deductible || //(to be completed)// || deductible || ? ||
 * Coinsurance || //(to be completed)// || coinsurance || ? ||
 * Adjustments || //(to be completed)// || Miscellaneous-adjustments || ? ||

Name
NM103 = Name Last NM104 = Name First NM105 = Name Middle || patient.name.full patient.name.last patient.name.first Patient.name.middle || Demographic / Full Name || patient.organization || Approximation = Primary Insurance: Policy Number? See Payer Identifier/Info fields on following pages ||
 * **EOB-type Transaction Data** || **X12 835 Transaction Set: Loop & Segment** || **HealthVault explanation-of-benefits type (XML)** || **MyMedicare.gov ASCII** ||
 * Patient Name || 2100 NM1 Patient Name
 * Patient Identifier || 2100 NM108 Qualifier (34=SSN, HN=HIC #, II=U.S. Unique Health Identifier, MI = Member ID#, MR = Medicaid #) NM109 Identification Code || patient.id

Provider

 * **EOB-type Transaction Data** || **X12 835 Transaction Set: Loop 2100 Element(s) NM1 Service Provider Name** || **HealthVault explanation-of-benefits type (XML)** || **MyMedicare.gov ASCII** ||
 * (Entity Type) || NM101 Entity Identifier Code = 82 (Rendering Provider) || (provider = organization entity) || n/a ||
 * Provider ID Code Qualifier || NM108 Identification Code Qualifier (BD=Blue Cr.; BS=Blue Sh.;FI=TIN, MC=Medicaid; PC=Prov. Commercial;SL=State License;UP=UPIN;XX=NPI) || n/a; (Healthvault organization entity type only has name, contact, type, website) || n/a ||
 * Provider ID || NM109 Identification Code || n/a || NPI? ||
 * Provider Type || NM102 Entity Type Identifier (1=Person, 2=Non-Person Entity) || provider.type || ? ||
 * Provider Name (Last or Org.) || NM103 Name Last or Organization Name || provider.name || Claim Summary / Provider ||
 * Provider First Name || NM104 Rendering Provider First Name || (provider.name) || Claim Summary / Provider ||
 * Provider Web Site || N/A || provider.website || N/A ||

Payer
Marketing Name ||
 * **EOB-type Transaction Data** || **X12 835 Transaction Set: Loop 1000 & Segment** || **HealthVault explanation-of-benefits type (XML)** || **MyMedicare.gov ASCII Plans Section** ||
 * Payer || N101 Entity Identifier Code = PR (Payer) || (“plan” as an Organization w, name, contact, type, website) || n/a ||
 * Payer Name || N102 Payer Name (free-form name) || plan.name || Plan Name
 * Payer ID type || N103 Identification Code Qualifier = XV (CMS National Plan ID) || n/a || n/a ||
 * Payer ID code || N104 Payer Identifier (other code) || n/a || (ContractID/PlanID ?) ||
 * Plan ID ||  ||   || ContractID/PlanID ||
 * Payer Web Site || N/A || plan.website || n/a ||
 * Eligibility Period || (X12 271/270 fields) ||  || Plan Period ||
 * Plan Type ||  ||   || Plan Type (e.g. 11 – Medicare Rx Drug Plan) ||
 * Primary Insurance || ? ||  || (Primary Insurance Section) ||

Procedure
Closest Healthvault = service.service-type. MyMedicare.gov = ? ||
 * **EOB-type Transaction Data** || **X12 835 Transaction Set: Loop 2100 Segment Detail** || **HealthVault explanation-of-benefits type (XML)** || **MyMedicare.gov ASCII Claims Summary Section** ||
 * Claim ID || CLP07 Payer Claim Control Number (Reference Identification) || claim-id || Claim Number ||
 * Date of Service || DTM02 Service Date || service.service-dates || Service Start Date & Service End Date ||
 * Procedure Code Type |||||| SVC01 – 1 235 Product/Service ID Qualifier (AD=ADA, ER=Jurisdiction-specific, HC=HCPCS & CPT, HP=HIPPS, IV=HIEC, N4=NDC Rx in 5-4-2; N6 = National Health Related Item 4-6; NU=UB92 Code;UPC=UPC 1-5-5 code;WK=Advanced billing concepts code)
 * Procedure Code || SVC01 – 2 234 Product/Service ID (and SVC01 -4,5,6 modifiers) || service.billing-code || ? ||
 * Procedure Description || Not Used. SVC01 - 7 || service.notes (?) || ? ||
 * Diagnosis Code || ? || service.diagnosis || Claim Summary / Diagnosis Code 1 ||

Amount
=Recommended Blue Button Formats for non-EMR-based Health Data Holders= After review of existing and emerging standards and formats, three main approaches have emerged as the most practical and interoperable approaches for Blue Button downloads for non-EMR-based data holders. This includes health insurers, pharmacy benefits managers (PBMs), and pharmacies. //**To be completed**// Specific options within the CDA standard include:
 * **EOB-type Transaction Data : Amounts** || **X12 Transaction Set : Loop 2100 CLP (Data Element 782)** || **HealthVault (XML) explanation-of-benefits.ClaimAmounts** || **MyMedicare.gov ASCII Claim Summary Section** ||
 * Provider Charged || CLP03 Total Claim Charge Amount || charged-amount || “Amount Charged:” ||
 * Allowed/Negotiated || Calculated from CAS03 claims adjustment amount || negotiated-amount || “Medicare Approved” ||
 * Paid to Provider || CLP04 Claim Payment Amount || benefits-paid || “Provider Paid” ||
 * Patient Responsibility || CLP05 Patient Responsibility Amount || patient-responsibility || “You May Be Billed” ||
 * Copay || //(to be completed from CAS segment?)// || copay || ? ||
 * Deductible || //(to be completed)// || deductible || ? ||
 * Coinsurance || //(to be completed)// || coinsurance || ? ||
 * Adjustments || //(to be completed)// || Miscellaneous-adjustments || ? ||
 * **Blue Button Recommended Format (for non-EMR Data Holders)** || **Description** || **Intended Use & Benefits** || **Known Limitations and Issues** ||
 * 1. **MyMedicare.gov-style Plain Tex**t || The CMS MyMedicare.gov ASCII plain-text format, with sufficient coded-level detail to permit interoperability || Most generic use; already implemented and shown to be feasible by MyMedicare.gov (CMS). Codified data including ICD-9, CPT codes and NPIs of high utility to downstream applications. Freely available sample files to use as models, to adapt implementations. || Human readability & usability typically needs additional utilities / apps / tools, although file by itself is technically human-readable. ||
 * 2. **CDA (Clinical Document Architecture) XML** || The HL7 CDA standard, with human-readable forms offered alongside the XML file or else a style sheet (XSL) able to render the XML in human-readable form.

A. Consolidated CDA Continuity of Care Document (C-CDA CCD)

B. Plan-to-Plan PHR Standard

C. Other || //**To be completed**//

Note: An HL7 CCD to ASCII Blue Button Transform (XSLT), based on the VA MyHealthEVet text file, is available from HL7 : http://www.hl7.org/implement/standards/product_brief.cfm?product_id=288 (free for HL7 members, $425.00 for non-members) || Cannot represent EOB-like consumer health financial data. || =Plain Text Format: Guide to offering plain text ASCII MyMedicare.gov-style plain text Blue Button file from a non-EMR source= The contents of this guidance have been adapted from CMS MyMedicare.gov Blue Button technical documents as well as sample files & guidance at [].
 * 3. **FHIR-style Document** || The XML and/or JSON documents of the emerging HL7 FHIR specification, which provide a modular approach to representing healthcare data. ||  ||   ||

This represents a reference implementation of Blue Button for health insurers and may be helpful to health insurers, PBMs, and other similar data holders gathering functional requirements for their Blue Button offering on their member portals, in addition the file standard itself.

The Blue Button download can be one of the most important functionalities of any health insurer member portal, including MyMedicare.gov, where users can download their personal health information to TXT or PDF file today. The User Interface provides a parameter screen to choose the specific information requested by the user. Based on the options selected, the corresponding web service is used to obtain the data and the Blue button file is generated. The PDF generator module uses calls to the enterprise service bus (ESB). While performing the download action whether it is TXT or PDF, the data is being formatted from the session dynamically and sent to the client browser as downloadable data. If the selection is not changed, the session data is reused instead making another web service calls.

Although other service-oriented architecture (SOA) environments are likely to be different, as an example, these are the internal web services used by MyMedicare.gov to obtain the Blue Button data (as of January 2013):


 * Blue Button web services**
 * **Option** || **Web Service Methods** ||
 * User Data || HealthManagement.GetHealthData ||
 * Claims with PDE (12, 24, 36m) || ClaimSOAP.FindBlueButtonClaimDetailServiceByProfile (ESB service) ||
 * Drugs || HealthManagement.GetHealthData.Drugs ||
 * Emergency Contact || HealthManagement.GetHealthData.EmergencyContacts ||
 * Family Medical History || HealthManagement.GetHealthData.FamilyList ||
 * Pharmacies || HealthManagement.GetHealthData.Pharmacies ||
 * Plans || NgdSrv.GetBeneMAPDPPlans ||
 * Preventive Services || NgdSrv.GetBeneCombined ||
 * Providers || MyProviders.CMSMBPGetMyProviders ||
 * Self Reported Health Information || HealthManagement.GetHealthData ||


 * Following are list of sections and Fields that are displayed in the CMS MyMedicare.gov Blue Button File:**

**Blue Button Section and Field labels** DOB Address Line 1 Address Line 2 City State Zip Home Phone Email Address Part A Effective Date Part B Effective Date || Address Type Address Line 1 Address Line 2 City State Zip Relationship Home Phone Work Phone Mobile Phone Email Address || Medical Condition Start Date Medical Condition End Date || Type Reaction Severity Diagnosed Treatment First Episode Date Last Episode Date Last Treatment Date Comments || Date Implanted || Date Administered Method Were you vaccinated in the US Comments Booster 1 Date Booster 2 Date Booster 3 Date || Date Taken Administered by Requesting Doctor Reason Test/Lab Requested Result Comments || Date Time Reading Comments: || Type DOB DOD Age Type Description || Supply Orig Drug Entry || Next Eligible Date Last Date of Service: || Provider Address Type Specialty Medicare Provider || Pharmacy Phone || Plan Period Plan Name Marketing Name Plan Address Plan Type || Employer Subsidy Start Date Employer Subsidy End Date || Policy Number Insurer Name Insurer Address Effective Date Termination Date || Policy Number Insurer Name Insurer Address Effective Date Termination Date || Provider Provider Billing Address Service Start Date Service End Date Amount Charged Medicare Approved Provider Paid You May be Billed Claim Type Diagnosis Code 1 Diagnosis Code 2 Diagnosis Code 3 Diagnosis Code 4 || Date of Service From Date of Service To Procedure Code/Description Modifier 1/Description Modifier 2/Description Modifier 3/Description Modifier 4/Description Quantity Billed/Units Submitted Amount/Charges Allowed Amount Non-Covered Place of Service/Description Type of Service/Description Rendering Provider No Rendering Provider NPI || Note: For Part D (prescription/ pharmacy) claims || MyMedicare.gov || Claim Type Claim Number Claim Service Date Pharmacy / Service Provider Pharmacy Nam Drug Code Drug Name Fill Number Days' Supply Prescriber Identifier Prescriber Name ||
 * **Sections** || **Source** || **Displayed Fields** ||
 * Demographic || MyMedicare.gov || Full Name
 * Emergency Contact || Self-Entered || Contact Name
 * Self Reported Medical Conditions || Self-Entered || Condition Name
 * Self Reported Allergies || Self-Entered || Allergy Name
 * Self Reported Implantable Device || Self-Entered || Device Name
 * Self Reported Immunizations || Self-Entered || Immunization Name
 * Self Reported Labs and Tests || Self-Entered || Test/Lab Type
 * Self Reported Vital Statistics || Self-Entered || Vital Statistic Type
 * Family Medical History || Self-Entered || Family Member
 * Drugs || Self-Entered || Drug Name
 * Preventive Services || MyMedicare.gov || Description
 * Providers || Self-Entered || Provider Name
 * Pharmacies || Self-Entered || Pharmacy Name
 * Plans || MyMedicare.gov || Contract ID/Plan ID
 * Employer Subsidy || MyMedicare.gov || Employer Plan
 * Primary Insurance || MyMedicare.gov || MSP Type
 * Other Insurance || MyMedicare.gov || MSP Type
 * Claim Summary || MyMedicare.gov || Claim Number
 * Claim Lines for Claim Number: XXXXXXXX || MyMedicare.gov || Line number
 * Claim Lines for Claim Number: XXXXXXX

The MyMedicare.gov Blue button data selection page appears prior to the download itself, and allows users to select the types of information to download. Radio button selection offers the user a choice between downloading 1) all types of information or 2) “select one or more types of information”. For the second option, check-boxes are offered for:
 * Claims
 * Drugs
 * Emergency Contact
 * Family Medical History
 * Pharmacies
 * Plans
 * Preventive Services
 * Providers
 * Self-Reported Health Information

In addition, important educational information on “Protecting your personal health information” appears at the bottom of the selection screen with a checkbox for the user to indicate “By checking this box, you agree that you have read and understand the “Protecting Your Personal Health Information” section shown above and wish to continue.

Three action buttons are then presented, to either Submit, Reset, or Cancel.

As this process perform multiple calls using web services, a progress bar appears on the user interface and once completed the user is redirected to Download Information page where he can choose to download either in TXT or PDF format. The download option usually prompts a “Save As…” dialog box, or based on web browser settings will download the Blue Button file automatically to the designated downloads folder.


 * Activity Log**:

The Blue Button download sub activities are captured when the beneficiary lands on the Blue button parameter page and during the download (both TXT and PDF) along with the options the user had selected prior to download//.// The enables the user to audit his or her Blue Button download activities. =CDA (Clinical Document Architecture) : Guide to offering CDA XML-based interoperable Blue Button files from a non-EMR source= The [|HL7] **Clinical Document Architecture** (CDA) is an [|XML] -based markup standard intended to specify the encoding, structure and semantics of clinical documents for exchange. CDA is part of the HL7 version 3 standard. Akin to other parts of the HL7 version 3 standard it was developed using the HL7 Development Framework (HDF) and it is based on the HL7 Reference Information Model (RIM) and the HL7 Version 3 Data Types. CDA documents are persistent in nature. The CDA specifies that the content of the document consists of a mandatory textual part (which ensures human interpretation of the document contents) and optional structured parts (for software processing). The structured part relies on coding systems (such as from [|SNOMED] and [|LOINC] ) to represent concepts. CDA Release 2 has been adopted as an [|ISO] standard, [|ISO] / [|HL7] 27932:2009. [|[1]]

For organizations such as health plans or others with data not classically derived from provider systems such as EMRs, data from health care claims transactions and other sources e.g. Personal Health Records (PHRs), Health Risk Appraisals/Assessments, and care management platforms (e.g. the Medical Management arm of a health insurer) may be adapted to populate Blue Button files.

The following are intended to be helpful interim guidance to organizations with non-EMR data seeking to offer interoperable Blue Button files in CDA XML format. The interim nature of these recommendations is based on the remaining work needed for formal implementation guide development, in terms of HL7 standards development & balloting, should a more formal definition of a Blue Button CDA XML format be needed, particularly as a template within consolidated CDA (C-CDA).

Note on CDA and Consumer Health Financial Data (EOB-like)
The ABBI Payer Content subworkgroup of the Standards & Interoperability workgroup has recognized that certain data -- e.g. consumer health financial data commonly found on Explanations of Benefits -- have no existing straightforward way of being expressed in CDA or consolidated CDA today. For organizations seeking to embed this data, e.g. to enable consumer-facing price transparency & health financial literacy tools, the following approaches are possible: 1. Await a HL7 C-CDA Template and Implementation Guide that supports consumer health financial data 2. Append the data in an parseable format as a separate C-CDA unstructured document 3. Offer separately, not C-CDA, as structured & interoperable content with codified information (e.g. ASCII format above or FHIR-style document below)

Many health plans already offer this type of consumer health financial data separately in a non-interoperable file, e.g. as plainly-available format (e.g. plain text or PDF), with online downloadable Explanations of Benefit. These files are not highly-interoperable, i.e cannot be read into consumer-facing applications.

//** To be added: **// Alternate examples of proprietary formats and implementations that have supported EOB-like data for consumer applications - Healthvault - OptumInsight/Intuit Open Medical eXchange (OMX)

**HL7 Implementation Guide for CDA® R2: Plan-to-Plan Personal Health Record (PHR) Data Transfer**
The HL7 P2P-PHR Implementation Guide was not expressly designed for consumer-facing downloads, and is also based upon an older version of the Continuity of Care Document (CCD) that is need adaptation to the consolidated CDA format. Nonetheless it is available as an interim way of structuring PHR data in an interoperable format. The HL7 Plan-to-Plan PHR Data Transfer Standard ([]) offers an Implementation Guide to help health plans interested in formatting their PHR data into a CDA (XML) document, within a constraint on the CCD continuity of care document from the base specification of CDA Release 2 – Continuity of Care Document (2007).

The Plan-to-Plan PHR implementation guide (IG) was produced and developed through the efforts of a joint project initiated by America's Health Insurance Plans (AHIP) and the Blue Cross Blue Shield Association, with participation from ASC X12. Data elements from the standard are also referenced in the original OPM Guidance from 2011 from the Carrier Letter to plans supporting federal employee health plans. (See http://www.opm.gov/carrier/carrier_letters/2011/2011-21-4.pdf )

Note the caveat: although this represents the most mature and developed standard for this type of data and source, the standards was developed for the exchange of personal health records (PHRs) between health insurance plans, rather than direct download by consumer per-se, and that is also based upon an older version of the Continuity of Care Document specification (2007), and as such has limitations.

__**Examples:**__ (to be completed) HCSC implementation/pilot

**Assembling a new CDA Blue Button file using pre-populated data from administrative claims and/or personal health record (non-EMR-based) data**
To build a consolidated CDA (C-CDA) continuity of care document (CCD), interpretations are needed to sort available administrative claims data to pre-populate certain concepts and sections, while other may rely solely upon patient/member-entered data, and/or patient self-reported data derived from interactions with the data holder.

These patient-generated data in the non-EMR world may come not only from direct entry in member portals and personal health records (PHRs) but also several other sources common to health plans, such as health risk assessments/appraisals, care management platforms used to manage wellness and disease management offerings, and other rapidly emerging sources of patient-generated data such as wearable devices and mobile applications.

__**Special note on patient-generated data standards:**__ As standards evolve for patient-generated data in the EMR world, particularly with regard to future stages of Meaningful Use, this guidance will likely need to adapt to those standards. There is a group in HL7 currently addressing to structure patient-generated data into C-CDA, and has applied for a LOINC code to represent the information itself; ballotting is expected in mid-2013.

An example of claims data mapping to C-CDA, with Conf # and XPath references, is attached here.

In addition, a higher-level section-by-section listing of sources and remarks is provided in the table below.


 * **Consolidated CDA (C-CDA) CCD Section** || **Available in claims or patient-generated data** || **Remarks** ||
 * Advance Directives || Patient-generated* || The specifics of advance directives are not typically a component of administrative claims data from health insurers. *From a clinical care management platform, there may be case manager detail on advance directives. If so, this would be an appropriate section to document the advance directive, e.g. for oncology case managers in health insurers' medical management function.

There are Level II HCPCS codes e.g. G8259, that indicate the patient is documented to have a surrogate decision maker or advance care plan in their medical record, which may be of some utility to populating this section -- indicating the *existence* of advance directives. ||
 * Allergies || Patient-generated and claims || Required in cCDA with standardized vocabulary / codes. See the Blue Button companion guide code list spreadsheet (linked below) for an example set that may be helpful to organizations seeking to filter ICD-9 codes etc. for allergies, i.e. an allergy code set / mapping. PBMs and other pharmacy-specific data holders may choose to populate this section more directly with detailed allergy data.[[file:ABBI_Payer_Companion_Guide_Requirements_Mapping_DRAFT 12-14-2012.xlsx]] ||
 * Encounters || Claims || Diagnosis and procedure codes for office visits and physician evaluation (i.e. CPT codes) and similar provider interactions can signify encounters, but several practical issues arise. 1) Codes are not always linked together as part of an encounter; 2) there are typically no times of day; 3) in cases where an individual is referred in the same day to a specialist (i.e. multiple providers and multiple encounter codes on same day), it can be difficult to figure out how to match up the type of encounter with the provider, and what happened / what diagnoses were being addressed. These can sometimes be solved with heuristics and grouper tools (e.g. episode-grouping).

A grouping of claims by provider identifier, date of service, and place of treatment can identify an encounter. Any procedures codes that match that pattern would be the activities.

//A set of example procedure codes to indicate a provider encounter is supplied here as an example://
 * To be completed** ||
 * Family History || Patient-Generated and Claims || All health data-holding entities should be aware of GINA, the Genetic Information Non-Discrimination Act, with respect to additional policy on genetic information that may include family history, and is separate from HIPAA and other requirements.

//A set of example ICD-9 codes to indicate a family history status is supplied here as an example:// __**CDC Value Set link:**__ C-CDA Vaccine Administered Value Set - []
 * To be completed** ||
 * Functional Status || Patient-Generated* || May be supplied by care management platforms as well if relevant information, e.g. activities of daily living (ADL) functional status is captured & structured in those systems. ||
 * Immunization (Vaccination) || Patient-Generated and/or Claims || Data holders are advised to consult //C-CDA Value sets,// which are static value sets vs. larger, dynamic value sets, referenced by OID, e.g. hosted by CDC//.// The Blue Button companion guide code list spreadsheet for an example set that may be helpful to organizations seeking to filter ICD-9 and CPT codes etc. for immunizations and vaccinations, i.e. a mapping list of immunization codes.

|| @http://www.cms.gov/Medicare/Coding/MedHCPCSGenInfo/ ||
 * Medical Equipment || Patient-Generated and/or Claims || Several CPT codes and HCPCS codes represent medical equipment. More detail on the HCPCS Level II codes for medical equipment may be found at this CMS link:
 * Medications || Patient-Generated and/or Claims || Medication is a required section of cCDA CCD. RxNorm codes are preferred; however NDC codes may be more commonly available in payer and PBM data (e.g. MyMedicare.gov files; data derived from ASC X12 transactions).

For health plan members without prescription benefit coverage through the health plan e.g. national segment employer/ASO plans, this section can be populated with patient-generated or pharmacy-integrated data streams. || templateId 2.16.840.1.113883.10.20.22.2.18. For health plans and insurers seeking to pre-populate this section, note that the section contains "Coverage Activity", which contains "Policy Activity" The LOINC code 48768-6 specifically refers to payment sources in the Coverage Activity. The Policy Activity within this entire section and Coverage Activity refers to the actual policy or program providing the coverage -- most commonly the health insurer.
 * Payers || Patient-Generated and/or Claims || A payer section is enumerated and described in the Consolidated CDA guidance at@http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258 as Payers Section 48768-6, template

Some of the most significant fields for implementers to recognize and map into the C-CDA template are highlighted below:

Health Insurance Type (CONF# 8904) Payer (Conf #8908) Health Plan ID (Conf #8909) Health Plan Address (Conf #8910) Health Plan Phone, Email, and/or Web URL (Conf #8911) Health Plan Name (Conf #8913) Guarantor Information (Conf #8961) Effective Date of Financial Responsibility (#8963) Health Plan Coverage Dates (Conf #8918, 8919, 8920); note that "low" and "high" are more colloquially translated as the Start and End date of eligibility / coverage. Patient Member ID (Conf #8922) Patient Relationship to the Subscriber (#8924) Subscriber ID (Conf #8937)

Health insurers and health plans are encouraged to look to common industry definitions of eligibility & coverage time frames, e.g. CAQH CORE standards and definitions, in defining functional requirements for the coverage & eligibility data to be mapped into the consolidated CDA template payer section. A recent example of a CAQH glossary may be found here : [] ||
 * Plan of Care || Patient-Generated or Other* || Unlikely if this can be generated through patient-generated data, although health plan care management systems may generate a plan of care distinct from claims data.

In particular, health plans with medical management functions & operations may wish consider populating invitations for wellness and disease management programs within their structured Blue Button output. Likewise, for members already working with a care management staff member (e.g. nurse, health coach), the Plan of Care section (18776-5) may be a reasonable place to document plans of care recommended, managed, or developed for the patient.


 * Care Alerts** may also be considered for inclusion here from health plans with rules engine-enabled claims-based clinical decision support functions to communicate gaps in care. Plan of Care can also be repositioned to the "top" of the document to make the gaps-in-care alerts more prominent in the case of communicating to a provider.

//To be completed: LOINC code to identify care alerts// ||
 * Problem || Patient-Generated and/or Claims || Required CCD cCDA section. The most simplistic manner to populate this section is to adapt ICD-9 diagnosis codes from billing data, however not all diagnoses, particularly "rule-out" or working/hypothetical diagnoses represent true clinical problems for the patient, nor active problems per se. Non-EMR data holders may wish to use //**heuristics or other grouping algorithms**// to filter the ICD-9 code history of a given patient to pre-populate the Problem section of a consolidated CDA.

In general, for C-CDA sections like "Problem", health insurers and other non-EMR data sources should take great care in disclaiming the source of the data from administrative claims data, as opposed to direct patient care. A sample disclaimer is provided at the end of this guidance. ||
 * Procedures || Patient-Generated and/or Claims || Procedures section of C-CDA is intended to represent surgical or other typically invasive interventions or other medical procedures. Non-EMR data holders are recommended to not necessarily cluster all "CPT"-type "procedures" into this category, but rather filter for the intended meaning of procedure as by the C-CDA guidance.


 * //To be updated//** ||
 * Results || Patient-Generated and/or Claims || Some payers may have access to laboratory result data, particularly for fully-insured health plans. LOINC-coded laboratory results may be fitted to this Results section of the cCDA CCD.

Consult local CLIA & HIPAA guidance for laboratory data sharing with patients. ||
 * Social History || Patient-Generated and/or Claims || See “Examples of codes for Social History data” ||
 * Vital Signs || Patient-Generated ||  ||

Blue Button FHIR-type Content
FHIR (Fast Healthcare Interoperability Resources) is an emerging specification from HL7, but not yet a ballotted standard.

This section of the interim guidance is currently in revision.

Readers are encouraged to refer to www.fhir.org as well as Grahame Grieve's explanation at @http://www.healthintersections.com.au/?p=1309 on how to use FHIR as a potentially, lighter/faster way to implement structured Blue Button data, as well as create a simpler path to offering programmatic access via secured RESTful APIs.

A strawman XML definition is provided here for illustration purposes only, modelled from the MyMedicare.gov Blue Button file and fields represented:


 * 

















</netAmount>

<span style="font-family: 'Courier New',Courier,monospace;"><allowedAmount></allowedAmount>

<span style="font-family: 'Courier New',Courier,monospace;"><coveredAmount></coveredAmount>

<span style="font-family: 'Courier New',Courier,monospace;"><nonCoveredAmount></nonCoveredAmount>

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;"><unitAmount></unitAmount>

<span style="font-family: 'Courier New',Courier,monospace;"><unitQuantity></unitQuantity>

<span style="font-family: 'Courier New',Courier,monospace;"><netAmount></netAmount>

<span style="font-family: 'Courier New',Courier,monospace;"><allowedAmount></allowedAmount>

<span style="font-family: 'Courier New',Courier,monospace;"><coveredAmount></coveredAmount>

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;"><bodySite></bodySite>

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;"><subLine></subLine>

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;">

<span style="font-family: 'Courier New',Courier,monospace;"></Claim> ||

As an example of a FHIR-type document, a resultant JSON representation of a sample file is also possible, and looks like this:

code { "Claim" : { "identifier": { "id" : { "value" : "9427984358334" } },   "type" : { "coding" : { "code" : "PartB" }   },    "period" : { "start" : { "value" : "2012-09-21" } },   "patient" : { "type" : "Patient", "id" : "example-abbi" },   "billingProvider" : { "Organization" : { "identifier" : [ { "label" : "Provider No", "identifier" : { "id" : "A300070363" }       }, {           "use" : "official", "label" : "Provider NPI", "identifier" : { "system" : "http://us.gov/NPI", "id" : "1124324181" }       } ]        "name" : { value : "MANHATTAN ENDOSCOPY CENTER L" }, "address" : { "line" : "CL #4685 PO BOX 95000", "city" : "PHILADELPHIA", "state" : "PA", "dpid" : "191954685" }     }    },    "netAmount" : { "value" : "386.60". "units" : "$" }   "allowedAmount" : { "value" : "386.59", "units" : "$" }   "coveredAmount" : { "value" : "386.59", "units" : "$" }

"line" : [ { "code" : { "coding" : { "system" : "http://cms.gov/Medicare/Coding/type-of-service-codes", "code" : "1", "display" : "Medical Care" }     }      "unitAmount" : { "value" : "386.59", "units" : "$" }     "unitQuantity" : { "value" : "1" }     "netAmount" : { "value" : "386.59", "units" : "$" }     "allowedAmount" : { "value" : "386.59", "units" : "$" }     "service" : [ { "type" : { "coding" : { "code" : "G0105", "display" : "Colorectal Cancer Screening; Colonoscopy On Individual At High Risk" }       }        "period" : { "start" : "2012-09-21", "end" : "2012-09-21" }       "location" : { "Location" : { "code" : { "coding" : { "code" : "24", "display" : "Ambulatory Surgical Center" }            }          }        }      } ]    },    {      "code" : { "coding" : { "system" : "http://cms.gov/Medicare/Coding/type-of-service-codes", "code" : "2", "display" : "Administrivia" }     }      "unitAmount" : { "value" : "0.01", "units" : "$" }     "unitQuantity" : { "value" : "1" }     "netAmount" : { "value" : "0.01", "units" : "$" }     "allowedAmount" : { "value" : "0.00", "units" : "$" }     "service" : { "type" : { "coding" : { "code" : "G8907" }       }        "period" : { "start" : "2012-10-22", "end" : "2012-10-22" }       "location" : { "Location" : { "code" : { "coding" : { "code" : "24", "display" : "Ambulatory Surgical Center" }            }          }        }      }    }],    "text" : { "status" : "generated", "div" : "..." } } } code

= Sample Disclaimer for non-EMR sourced Blue Button = The intent of this disclaimer is to help Blue Button file recipients understand that the health data provided through insurance claims information is a bit different from that they might find in doctor's charts. Namely, that it's used for payment purposes, and not necessarily complete, and may even contain errors.

<span style="background-color: #ffffff; font-family: Arial,sans-serif; font-size: 8pt;">Information provided through the Blue Button by your health or pharmacy plan includes only information submitted to participating insurance companies for payment purposes. The information is not a medical report, nor is it intended to be a complete record of a patient's health information. Certain information may have been intentionally excluded (due to its sensitivity-psychiatric, substance abuse, HIV/AIDS, sexually transmitted diseases, and abortion related data) and the health record may also contain errors. Physicians must use their professional judgment to verify this information and should not exclusively rely on this information to treat their patients.
 * Adapted Sample Disclaimer for non-EMR sourced Blue Button (2013): **

<span style="background-color: #ffffff; font-family: Arial,sans-serif; font-size: 8pt;">Information provided through the CareProfile includes only information submitted to participating insurance companies for payment purposes. The information is not a medical report, nor is it intended to be a complete record of a patient's health information. Certain information may have been intentionally excluded (due to its sensitivity-psychiatric, substance abuse, HIV/AIDS, sexually transmitted diseases, and abortion related data) and the health record may also contain errors. Physicians must use their professional judgment to verify this information and should not exclusively rely on this information to treat their patients.
 * Original (2012), adapted with help from Humana: **

=**Medication-Only Data: Blue Button for Pharmacies and Pharmacy Benefits Managers (PBM)**= Medication and pharmacy history data, including prescription claims are highly valuable to patients. Even on their own without other clinical data, these medication data also constitute an important potential for application developers -- particularly mobile application developers -- to innovate novel tools to help consumers. These tools include applications for medication adherence, medication reconciliation (a JCAHO requirement), medication affordability, pharmacy resource navigation, clinical decision support (e.g. drug interaction checking; therapeutic duplication; generic substitution), adverse event monitoring, care coordination, and a number of other potential use cases.

As noted above there are several possible ways to represent this medication data in an interoperable format. The Consolidated CDA templates however largely appear to represent more holistic snapshots of a patient's medical history. Also, in the initial exercise (Fall/Winter 2012), limited participation by experts or companies in the PBM (Pharmacy Benefits Managers) and Pharmacy (Retail & Wholesale) space leads to only limited guidance here.

For PBMs or Pharmacies interested in making interoperable Blue Button data for its members/patients/covered lives, the interim recommendation and guidance for interoperable Blue Button data formatting follows a similar approach as that given about to health plan & payer health data holders: 1. **ASCII Plain Text structured text**, following the MyMedicare.gov Blue Button style and in particular, how Medicare Part D medication and prescription claims history are formatted (including NDC codes) -- and ideally codified allergy data as well. 2. **XML document in CDA**(Clinical Document Architecture), with attention to edication Section schema : e.g. http://wiki.siframework.org/CDA+-+Medications+Section, as well as guidance for Allergies Sections : e.g. http://wiki.siframework.org/CDA+-+Allergies+Section. 3. **"Lightweight" XML and/or JSON formats**: for example, HL7 FHIR (see www.fhir.org) and the FHIR Patient, Provider, Coverage and Medications resources, and potentially an Allergies resource if one is developed. Other lightweight structured formats are possible in either XML or JSON. For best adoption and utility amongst developers (e.g. for consumer visualization tools, applications, and services), if a non-standard format is used, the data holder should ideally provide a developer-accessible data field listing, description, schema and set of sample files.

=**HIPAA and Other Privacy and Security Compliance Notes**= Both original (plain text and PDF) Blue Button implementers as well as automated Blue Button implementers are encouraged to understand the privacy and security regulations, particularly those recently updated in January, 2013.

A link to the Final Rule that appeared in the Federal Register 1/25/2013 is provided here for convenience: URL: https://www.federalregister.gov/articles/2013/01/25/2013-01073/modifications-to-the-hipaa-privacy-security-enforcement-and-breach-notification-rules-under-the
 * <span style="font-family: Arial,Helvetica,sans-serif;">Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules Under the Health Information Technology for Economic and Clinical Health Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules **

Health data-holder organization are encouraged to consult with the HHS Office of Civil Rights to understand consumers' rights to their health data, and any potential penalties for not providing health information upon request by the patient. An excerpt and link is provided for convenience here:

URL: http://www.hhs.gov/ocr/privacy/hipaa/understanding/consumers/index.html
 * <span style="font-family: Arial,Helvetica,sans-serif;">Understanding HIPAA Privacy: For Consumers **

Excerpt: <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">**Who Can Look at and Receive Your Health Information** <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">The Privacy Rule sets rules and limits on who can look at and receive your health information <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">To make sure that your health information is protected in a way that does not interfere with your health care, your information can be used and shared: <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">Your health information cannot be used or shared without your written permission unless this law allows it. For example, without your authorization, your provider generally cannot:
 * <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">For your treatment and care coordination
 * <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">To pay doctors and hospitals for your health care and to help run their businesses
 * <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">With your family, relatives, friends, or others you identify who are involved with your health care or your health care bills, unless you object
 * <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">To make sure doctors give good care and nursing homes are clean and safe
 * <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">To protect the public's health, such as by reporting when the flu is in your area
 * <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">To make required reports to the police, such as reporting gunshot wounds
 * <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">Give your information to your employer
 * <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">Use or share your information for marketing or advertising purposes
 * <span style="background-color: #ffffff; font-family: Verdana,Arial,sans-serif,'Trebuchet MS',Tahoma; font-size: 14px;">Share private notes about your health care

Interested members of the Blue Button community are encouraged to subscribe to the HHS OCR Privacy & Security Listserve for additional updates and information about health information privacy and security. A summary of archived announcements is also available. URL: http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/listserv.html
 * <span style="font-family: Arial,Helvetica,sans-serif;">Sign Up for the OCR Privacy & Security Listserv **