Personal Health Record Data Transfer Between Health Plans (275)

005010271 Based on ASC 12 275, Version 005010 Standards for Electronic Data Interchange Personal Health Record Data Transfer Between Health Plans (275) VERSION 3.1.4

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL References to and data elements from the Continuity of Care Record (CCR) have been extracted, with permission, from ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR), copyright ASTM International, 100 Barr Harbor Drive, West Conshohocken, PA 19428. A copy of the complete standard may be purchased from ASTM, www.astm.org. References to and data elements from Continuity of Care Document (CCD) and Clinical Document Architecture (CDA) have been extracted, with permission, from Health Level Seven (HL7). Copyright by Health Level Seven, Inc., 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104, 734-677-7777 (phone) 734-677- 6622 (fax), E-mail: hq@hl7.org. A copy of the pertinent standards may be purchased from HL7, www.hl7.org/. Portions of the 12 275 transaction and version 005010 Technical Report Type 3 have been reproduced with permission of Washington Publishing Company (WPC) [www.wpc-edi.com] and the Accredited Standards Committee 12 (ASC 12) [www.x12.org] through their secretariat, the Data Interchange Standards Association, Inc., (DISA) [www.disa.org]. WPC is the copyright holder and publisher for all ASC 12 insurance-related implementation guides, upon which portions of this document is based. DISA is the copyright holder and publisher of the ASC 12 standards. America s Health Insurance Plans and the Blue Cross Blue Shield Association intend to work with ASC 12 and Health Level 7 in order to allow this document to serve as the basis for the development of an ASC 12 275 technical report type three (TR3) for health plan to health plan transfer of data and for an HL7 structured document consistent with Clinical Document Architecture and the Continuity of Care Document to contain the data transported within the 12 275. ii

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 Table of Contents 1 Purpose and Business Information... 1 1.1 Implementation Purpose and Scope... 1 1.2 Version Information... 2 1.3 Implementation Limitations... 2 1.3.1 File Size Limitation... 2 1.4 Business Use... 3 1.4.1 PHR Data Transfer Process: Employer Group Change... 4 1.4.2 PHR Data Transfer Process: Individual Change... 5 1.4.3 PHR Data Transfer Process: Employer Open Season... 7 1.5 Business Terminology... 8 1.6 Transaction Acknowledgments... 10 1.6.1 997 Functional Acknowledgment... 10 1.6.2 999 Implementation Acknowledgment... 11 1.7 Data Overview... 11 1.8 Operating Rules... 13 2 Transaction Sets... 15 2.1 Presentation Examples... 15 2.2 Implementation Usage... 16 2.2.1 Industry Usage... 16 2.2.2 Loops... 17 2.3 Transaction Set Listing... 19 2.3.1 Implementation... 19 2.3.2 12 Standard... 21 2.4 275 Segment Detail... 24 ST 275 Transaction Header... 25 BGN Beginning Segment... 27 NM1 Sender Health Plan Name... 29 PER Information Source Contact Information... 32 NM1 Recipient Health Plan Name... 35 PER Recipient Health Plan Contact Information... 38 NM1 Information Requestor Name... 41 PER Information Requestor Contact Information... 44 REF Request Tracking Information... 47 DTP Date PHR Transfer Was Requested... 48 L Assigned Number... 49 NM1 Subscriber Name... 50 PER Subscriber Contact Information... 53 DTP Date PHR is Generated... 56 EFI Electronic Format Identification... 57 BIN Binary Data Segment... 59 SE 275 Transaction Set Trailer... 60 iii

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL 3 Examples... 61 3.1 Business Scenario - Use of 275 Plan to Plan PHR Transfer... 61 A External Code Sources...A.1 131 International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)...A.1 133 Current Procedural Terminology (CPT) Codes...A.1 464 Health Industry Level 7 (HL7)...A.2 537 Centers for Medicare & Medicaid Services National Provider Identifier...A.2 540 Centers for Medicare and Medicaid Services PlanID...A.3 896 International Classification of Diseases, 10th Revision, Procedure Coding System (ICD-10-PCS)...A.4 897 International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)...A.4 B C PHR Data Dictionary...B.1 EDI Control Directory...C.1 C.1 Control Segments...C.1 ISA Interchange Control Header...C.3 GS Functional Group Header...C.7 GE Functional Group Trailer...C.9 IEA Interchange Control Trailer...C.10 D PHR Schema...D.1 D.1 ML Schema...D.1 D.2 Graphical Illustration of the ML Schema...D.18 E Operating Rules...E.1 E.1 General Policies for Transfer of PHR Data Between Health Insurers...E.1 E.2 Technical Requirements for Insurer to Insurer Transfer of PHR Data...E.6 E.3 Process for Transfer of PHR Data Between Health Insurers...E.8 E.4 Legal Requirements for Insurer to Insurer Transfer of PHR data... E.11 E.5 General Principles for Individual PHR Use...E.13 iv

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 F Change Summary... F.1 F.1 Change Summary Details... F.1 F.1.1 Global Changes... F.1 F.1.2 Section 2.4, Segment Details... F.1 F.1.3 Appendix A: External Code Sources... F.1 F.1.4 Appendix B: PHR Data Dictionary... F.2 F.1.5 Appendix D: PHR Schema... F.2 v

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL vi

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 1 Purpose and Business Information 1.1 Implementation Purpose and Scope Through the years of adopting electronic data interchange (EDI), health plans have accumulated digitized healthcare data for their members. Such data, including claims, pharmacy, administrative, and data about providers and facilities, is centered on managing the healthcare of consumers. The healthcare data from health plans can be used to construct personal health records (PHRs) for consumers. PHRs help consumers document and manage their health events and improve communication with their healthcare providers to improve patient safety and healthcare quality. It is the general consensus of the healthcare industry that health plans should serve as hosts for personal health records for consumers, as recommended by the Health Information Technology Standards Panel (HITSP). However, when consumers move from health plan to health plan, their healthcare information becomes disjointed. The data accumulated by the prior health plan is usually not available to consumers and the new health plan. Without the capability to carry over consumers' healthcare information, consumers and health plans have to start anew to accumulate health information going forward. To better support health plans in the role of maintaining the longitudinal personal health records for the consumers, personal health information should be moved from health plan to health plan along with the consumers (i.e., be portable). The purpose of this Implementation Guide is to provide a standardized data transfer mechanism for one health plan to move the personal health information that makes up a PHR to another health plan. Under the assumption that mechanism will use existing electronic data interchange standards that are familiar to most health plans, this Implementation Guide uses the existing ANSI ASC 12 patient information standard (275). While further coordination with ASC 12 is pending, this Implementation Guide bases detailed explanations on the 12 275 transaction set, which identifies the relevant code tables, and specifies values applicable for the transfer of PHR data among health plans. This solution encapsulates the ML encoded PHRs within the 12 transaction envelope to support the transfer of the PHR data from one health plan to another. The ML based content inside the 275 envelope covers the data elements that are supported by health 1

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL plan claims and administrative data and the information directly entered by consumers into their PHR. With the intention to maintain part of this standard as one of the ASC 12 Standards for Electronic Data Interchange, this document has applied the style, language, and some content that is consistent with ASC 12 Standards for Electronic Data Interchange. In particular, loop, segment, and data element constructs follow ASC 12 Standards. Several consumer self-reported data domains in the data dictionary of this standard have incorporated data elements from the draft HL7/ASTM standard Continuity of Care Document (CCD). Pending the approval from HL7/ASTM, the data elements for these self-reported data domains are not included in this Implementation Guide. This Implementation Guide is not intended to define these data elements on its own. 1.2 Version Information This Implementation Guide is based on the October 2003 ASC 12 standards, referred to as Version 5, Release 1, Sub-release 0 (005010). The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this Implementation Guide is to be determined. For the illustration purposes, we use 005010271 as the Version/Release/Industry Identifier Code for this Implementation Guide. The two-character Functional Identifier Code for the transaction set included in this Implementation Guide is: PI Patient Information (275) The Version/Release/Industry Identifier Code and the applicable Functional Identifier Code must be transmitted in the Functional Group Header (GS segment) that begins a functional group of these transaction sets. 1.3 Implementation Limitations 1.3.1 File Size Limitation The 275 transaction structure is used to transfer historical raw personal health record data from one health insurer to another. Receiving health insurers should maintain all of the original PHR data received from the sending health insurer for purposes of ensuring a longitudinal PHR for the individual. Such historical data will grow over time for active 2

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 consumers. The amount of data being transferred is potentially large. As a result of the potential impact on transmission and processing times and storage capacity, trading partners may find it necessary to establish size limitations for the overall 275 file. At a minimum, it is recommended that the content of the 275 file not exceed 400 megabytes uncompressed. It is also recommended that the file being transmitted electronically via the Internet be compressed. Preliminary testing result for 500 people employer groups indicated that the limit of 400 megabytes uncompressed is applicable and appropriate. After compression, the 400 megabytes usually result in about 5% of its original size, or 20 megabytes compressed, which is suitable for transmission over the Internet. For larger employer groups with more than 500 people, it is recommended to transfer the PHR data in multiple files, with each of which not exceeding 400 megabytes uncompressed. Since the atomic unit of the PHR data transfer is the individual document of personal health record data, the file segmentation will not affect the result of the transfer. 1.4 Business Use This Implementation Guide provides guidance to health insurers on how to transfer the personal health information contained in a PHR of their members between different health plans. Appendix E-Operating Rules for Insurer to Insurer Transfer of PHR Data contains detailed operating rules. In addition to the standard for the transfer of PHR data, health insurers agree to adopt the Operating Rules for the Insurer to Insurer Transfer of Personal Health Record Data included in Appendix E. The following is summary of the scenarios envisioned in the Implementation Guide and the Operating Rules: 1. Employer Group Change: An employer group switches from one health plan to another. The new health plan requests, with individual consent, that the prior health plan transfers the PHR data for the covered subscribers and dependents who have been enrolled by the new health plan. 2. Individual Change: An individual switches to a new health insurer (either because of change in employers or enrollment in individual market coverage). The individual requests, with consent, that their new health insurer requests a transfer of their PHR data. 3

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL 3. Open Season: An employer group offers its employees more than one health insurer to choose from. When a subgroup of employees changes health plans, the new health insurer can request, with an individual's consent, that the prior health insurer transfer the subscriber's and dependents PHR data. This Implementation Guide only supports the transfer of PHR data between health insurers. Not included are other transfer scenarios which will require separate implementation guides and operating rules (e.g., the transfer of PHR data to providers and other points of care or service such as pharmacies and lab testing facilities). However, it is envisioned the basic technical standards and operating rules will be similar. 1.4.1 PHR Data Transfer Process: Employer Group Change Scenario 1: Employer Group Change Overview: An employer changes group insurers and wants to ensure the PHR data is transferred. Figure 1.1 - Employer Group Change Step 1. General policies for transfer of PHR data between health insurers are met. Policies cover enrollment, consent, record retention, privacy, security, health insurer derived data, processes for updating PHR data, and adherence to the technical standards. 4

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 Step 2. Plan sponsor provides information to the receiving (new) health insurer. Information includes contact information for sending insurer, list of covered individuals and their member/subscriber IDs from the plan sponsor's former health insurer. Step 3. New health insurer submits request for PHR data for all enrolled individuals who have consented to the transfer. Step 4. Sending health insurer extracts PHR data and sends to receiving health insurer (according to PHR transfer standard). Step 5. PHR data is received by receiving health insurer. Step 6. PHR data is added to the individual's PHR. Step 7. Receiving insurer submits acknowledgment of receipt. Note: These steps are explained in more detail in Appendix E-Operating Rules for Insurer to Insurer Transfer of PHR Data. 1.4.2 PHR Data Transfer Process: Individual Change Scenario 2: Individual Change Overview: An individual gets a new job and changes health insurance and wants to ensure the PHR data is transferred. Figure 1.2 - Individual Change 5

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL Step 1. General policies for transfer of PHR data between health insurers are met. Policies cover enrollment, consent, record retention, privacy, security, health insurer derived data, processes for updating PHR data, and adherence to the technical standards. Step 2. Individual provides information regarding their former health plan to their new (receiving) health insurer (if not collected during enrollment). Step 3. New health insurer submits request for PHR data for the newly enrolled individual who has consented to the transfer. Step 4. Sending health insurer extracts PHR data and sends to receiving health insurer (according to PHR transfer standard). Step 5. PHR data is received by the receiving health insurer. Step 6. PHR data is added to the individual's PHR. Step 7. Receiving insurer submits acknowledgment of receipt. Note: These steps are explained in more detail in Appendix E-Operating Rules for Insurer to Insurer Transfer of PHR Data. 1.4.3 PHR Data Transfer Process: Employer Open Season Scenario 3: Open Season Overview: During open season two employees both choose new health insurers and both want to ensure their PHR data is transferred to their new insurer. 6

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 Figure 1.3 - Open Season Step 1. General policies for transfer of PHR data between health insurers are met. Policies cover enrollment, consent, record retention, privacy, security, health insurer derived data, processes for updating PHR data, and adherence to the technical standards. Step 2. Plan Sponsor provides information to the new (receiving) health insurer (if the information is not received during enrollment). Step 3. New Health insurer submits a request to each sending health insurer for each individual who has consented to the transfer. Step 4. Sending Health Insurer extracts PHR data and sends to receiving health insurer (according to PHR transfer standard). Step 5. PHR Data is received by the receiving health insurers. Step 6. PHR data is added to the individual's PHR. Step 7. Receiving insurer submits acknowledgment of receipt. Note: These steps are explained in more detail in Appendix E-Operating Rules for Insurer to Insurer Transfer of PHR Data. 1.5 Business Terminology Several key terms are defined below: 7

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL Personal Health Record (PHR) - A personal health record or PHR means a web-based or other service, provided by a health insurer, on behalf of itself or a self-funded group health plan, which is populated with data derived from claims and administrative processing and individual self-reported information. A PHR enables individuals and their families to view and manage their health information. PHRs are distinct from an electronic health record, which a health care provider uses to store and manage detailed clinical information. PHR Data - Data in an individual's personal health record from the claim and administrative systems of a health insurer and self-reported data from the individual. Plan to Plan PHR Transfer Standard - The standard which defines the data content, data encoding, data structure, and a minimum set of rules to help one health plan to transfer personal health record data to another health plan. As described in this Implementation Guide, the data content for the plan to plan PHR transfer includes system populated data domains that are supported by the common information systems of health plans, namely: Patient information Encounters Medications Providers or facilities Health plan information Subscriber information The data content also includes transaction information that describes the process of the PHR transfer such as transaction number, request time, and creation time of PHR. Data encoding for the plan to plan transfer standard is a combination of: (a) The use of 12 275 standard transaction sets to describe the transaction information that forms the envelope of the transaction; and (b) The use of the etensible Markup Language (ML) to package and describe the data contents mentioned above. The packaging and encoding of these health plan system populated data domains are defined in the PHR ML schema. The data structure defines how the data elements are arranged relative to each other. The minimum set of rules for the standard is reflected in the definition of required data elements, the scope of the data domains, etc. 8

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 The plan to plan PHR transfer standard uses the 12 275 standard as the basis for its transaction envelope. It uses Internet standard ML to encode the data domains and data elements. The definitions of the data elements and their attributes were carefully chosen to be interoperable with existing industry standards ASC 12, HL7/ASTM Continuity of Care Document (CCD), and National Council for Prescription Drug Programs (NCPDP). Note that the operating rules provide the sending plan with the option to send self-reported data to the receiving plan, if they mutually agree. The operating rules related to the collection, accuracy and usability of the self-reported data are not defined in this version of the Implementation Guide and will be addressed in future versions of the Implementation Guide (i.e. the transfer format standards and operating rules for transferring self-reported data). Implementation Guide for Plan to Plan PHR Data Transfer - This Implementation Guide illustrates the definition of the standard and an example of its application. It outlines the steps health plans must take to package and transfer the PHR information to other health plans. It also outlines the formats and structure for the electronic data interchange of PHR information between health plans. Health Insurer Populated Data - Data that exist in the health insurer information systems such as claims and administrative systems, which can be used to populate the data elements of PHR without consumer input. However, health insurers should have procedures in place for individuals to request amendment, correction or annotation of health insurer populated data. Consumer Self-Reported Data - Self-Reported Data means data in a personal health record that an individual directly enters. A list of self-reported data is included below. PHR Data Domains - Groups of data which describe different aspects of an individual's personal health information contained in a PHR. The recognized PHR data domains include system populated domains such as: Patient information Encounters Medications Lab results Providers Facilities Health plan information Subscriber information 9

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL Benefit Information Consumer self-reported data domains include items such as: Family history Physiological information Immunizations Health risk factors Advance directives Alerts (includes Allergies) Plan of care PHR Schema - The template for ML based presentation of the consumer personal health records covered by the PHR data domains. Since the individual data domains are modeled after existing standards such as 12, CCD, and NCPDP, the overall personal health record document formulated using PHR schema containing all these data domains does not entirely reflect any single standard.the PHR ML schema is created to contain all the data domains in a structure that works well with both information systems and user presentation. 1.6 Transaction Acknowledgments (source: 005010211) 1.6.1 997 Functional Acknowledgment The 997 informs the submitter that the functional group (i.e., the functional group of transactions) arrived at the destination. It may include information about the syntactical quality of the functional group. 1.6.2 999 Implementation Acknowledgment The 999 informs the submitter that the functional group arrived at the destination. It may include information about the syntactical quality of the functional group and the Implementation Guide compliance. 1.7 Data Overview The health plan based PHR data domains include fifteen categories as shown in Table 1.1 - Health Plan-based PHR Data Domains in General and Data Domains for Plan to Plan Transfer. The data elements listed as "Not Included" are consumer self-reported data elements, which are not included in this version of the plan to plan 10

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 transfer standard. The detailed data domains with data elements are included as Appendix A - PHR Data Dictionary. Table 1.1 - Health Plan-based PHR Data Domains in General and Data Domains for Plan to Plan Transfer PHR Data Domain Alignment with Existing Standards Plan to Plan Transfer Common Data Source Patient Information ASC 12N Included System Populated Encounter ASC 12N Included System Populated Medication NCPDP Included System Populated Provider ASC 12N Included System Populated Facility ASC 12N Included System Populated Health Plan Information ASC 12N Included System Populated Subscriber Information ASC 12N Included System Populated Family History HL7/ASTM CCD Not Included Self Reported Physiological Info. HL7/ASTM CCD Not Included Self Reported Immunization NCPDP Not Included Self Reported Benefit Information ASC 12N Not Included System Populated Health Risk Factors HL7/ASTM CCD Not Included Self Reported Advance Directives HL7/ASTM CCD Not Included Self Reported Alerts HL7/ASTM CCD Not Included Self Reported Plan of Care HL7/ASTM CCD Not Included Self Reported As indicated in Table 1.1 - Health Plan-based PHR Data Domains in General and Data Domains for Plan to Plan Transfer, some of the data domains are populated using the data from health plan information systems. Some of the data is collected directly from consumers. 11

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL This Implementation Guide specifies seven data domains which are included in the plan to plan transfer of PHR data. All seven data domains included for the PHR transfer can be populated with the data from health plan information systems. The first five data domains listed are the core components for the PHR. The health plan information and subscriber information data domains are included for transaction purposes only; they are not included as part of the individual's PHR. The remaining data domains are recommended to be included in the PHR offering of PHRs; however these data domains are not supported for transfer between health plans in this version of the Implementation Guide. Trading partners may make arrangement to transfer this information, based on the draft HL7/ASTM CCD standard. 1.8 Operating Rules Appendix E of the Implementation Guide includes the operating rules health insurers should implement when transferring PHR data between health insurers. The operating rules are divided into five general categories. 1. General policies: Describes the policy that the individual whose PHR data will be transferred between insurers must be enrolled by the receiving health insurer and provide consent to the transfer request. The policies are included describe: how to maintain an individual's longitudinal PHR data, an automated capability for individuals to initiate the transfer of their PHR data, the individual review and amendment of the PHR data transferred, standard record retention policies, and policies covering both individual self-reported and health insurer derived data. 2. Technical requirements: Includes general policies for standard adherence, including which standards the PHR leverages, information needed to match individuals with their PHR data, and security standards. 3. Description of the process for transfer: Describes the steps a health insurer must take to transfer PHR data between insurers including sending a request for PHR data, transferring the data, receiving the data, and creating a PHR. 4. Legal requirements: Defines organizational and regulatory compliance rules including the HIPAA Privacy and Security Rules, Federal Substance Abuse Rules, state law requirements, and terms and conditions. 5. General principles for individual PHR use: Describes principles for individual use of PHRs including individual functionalities, privacy and security, and access by designated parties. 12

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 In addition, a set of technical operating rules are observed throughout the Implementation Guide and are described in more detail in Appendix E. Data Pull Model: The receiving health insurer will initiate the PHR data transfer request. The sending health insurer will respond with the PHR data requested within 2 weeks. Consumer Control and Consent: The data in the PHR belongs to the individual. The individual must consent before the receiving health insurer makes a request for their PHR data. Acknowledgement: The receiving health insurer should send back an acknowledgment of receipt to the sending health insurer. Member Identification: Information about the individual's prior health insurer is needed for the receiving health insurer to know which PHR data to request and for the sending health insurer to know whose PHR data to send. Health Insurer Derived Data Stays with Sending Health Insurer: For PHR data covering an individual's health care encounters, the Implementation Guide and operating rules require the health insurer to only send clinical content originated from their claims data or consumer self-reported data. This guide does not support the transfer of any derived information using the insurer's analytic, disease management or other clinical decision support tools such as patient reminders or drug interaction information. The PHR should be generated and stored at the individual level. Transaction related information (e.g. information about the individual's prior health plan, the date and time the PHR data was transferred, etc.) should not be part of the individual personal health record, even though it is pertinent to the transfer of the PHR data between health insurers. 13

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 2 Transaction Set 2.1 Presentation Examples The ASC 12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable. This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. 12 STANDARD is included as a reference only. The transaction set presentation is comprised of two main sections with subsections within the main sections: 2.3 Transaction Set Listing There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic 12 transaction set. The second sub-section concerns the generic 12 standard itself. IMPLEMENTATION This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail. STANDARD 2.4 Segment Detail This section is included as a reference. There are three sub-sections under this general title. This section repeats once for each segment used in this implementation providing segment specific detail and 12 standard detail. SEGMENT DETAIL This section is included as a reference. DIAGRAM This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation. ELEMENT DETAIL This section specifies the implementation details of each data element. 15

BASED ON ASC 12 275 VERSION 005010 2.2 Implementation Usage HEALTH PLAN PERSONAL 2.2.1 Industry Usage A transmitted transaction complies with an implementation guide when it satisfies the requirements as defined within the Implementation Guide. The presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this Implementation Guide according to the following table. Required This loop/segment/element must always be sent. Required segments in Situational loops only occur when the loop is used. Required elements in Situational segments only occur when the segment is used. Required component elements in Situational composite elements only occur when the composite element is used. Not Used Situational This element must never be sent. Use of this loop/segment/element varies, depending on data content and business context as described in the defining rule. The defining rule is documented in a Situational Rule attached to the item. There are two forms of Situational Rules. The first form is Required when <explicit condition statement>. If not required by this implementation guide, may be provided at the sender s discretion, but cannot be required by the receiver. The data qualified by such a situational rule cannot be required or requested by the receiver, transmission of this data is solely at the sender s discretion. The alternative form is Required when <explicit condition statement>. If not required by this implementation guide, do not send. The data qualified by such a situational rule cannot be sent except as described in the explicit condition statement. 16

HEALTH PLAN PERSONAL BASED ON ASC 12 275 VERSION 005010 2.2.1.1 Transaction Compliance Related to Industry Usage A transmitted transaction complies with an implementation guide when it satisfies the requirements as defined within the implementation guide. The presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this Implementation Guide according to the following table. Industry Usage Business Condition is Item is Transaction Complies with Implementation Guide? Required Not Used Situational (Required when <explicit condition statement>. If not required by this implementation guide, may be provided at the sender s discretion, but cannot be required by the receiver.) Situational (Required when <explicit condition statement>. If not required by this implementation guide, do not send.) N/A N/A True Not True True Not True Sent Not Sent Sent Not Sent Sent Not Sent Sent Not Sent Sent Not Sent Sent Not Sent Yes No No Yes Yes No Yes Yes Yes No No Yes 2.2.2 Loops This table specifies how an entity is to evaluate a transmitted transaction for compliance with industry usage. It is not intended to require or imply that the receiver must reject non-compliant transactions. The receiver will handle non-compliant transactions based on its business process and any applicable regulations. Loop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops. A nested loop can be used only when the associated higher level loop is used. The usage of a loop is the same as the usage of its beginning segment. If a loop s beginning segment is Required, the loop is Required and must occur at least once unless it is nested in a loop that is not being used. If a loop s beginning segment is Situational, the loop is Situational. Subsequent segments within a loop can be sent only when the beginning segment is used. Required segments in Situational loops occur only when the loop is used. 17

BASED ON ASC 12 275 VERSION 005010 HEALTH PLAN PERSONAL 18

ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE 3 2.3 Transaction Set Listing 005010271 275 2.3.1 Implementation This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail. Refer to section 2.1 Presentation Examples for detailed information on the components of the Implementation section. 19

ASC 12N INSURANCE SUBCOMMITTEE 005010271 275 TECHNICAL REPORT TYPE 3 005010271 275 MAY IMPLEMENTATION 4, 2007 275 Health Plan Personal Health Record Data Transfer Table 1 - Header PAGE # POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT 25 0100 ST 275 Transaction Header R 1 27 0200 BGN Beginning Segment R 1 LOOP ID - 1000A SENDER HEALTH PLAN NAME 1 29 0500 NM1 Sender Health Plan Name R 1 32 0900 PER Information Source Contact Information R 1 LOOP ID - 1000B RECIPIENT HEALTH PLAN NAME 1 35 0500 NM1 Recipient Health Plan Name R 1 38 0900 PER Recipient Health Plan Contact Information R 1 LOOP ID - 1000C INFORMATION REQUESTOR NAME 1 41 0500 NM1 Information Requestor Name R 1 44 0900 PER Information Requestor Contact Information R 1 47 1000 REF Request Tracking Information R 1 48 1050 DTP Date PHR Transfer Was Requested R 1 Table 2 - Detail PAGE # POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT LOOP ID - 2000A ASSIGNED NUMBER >1 49 0100 L Assigned Number R 1 50 0200 NM1 Subscriber Name R 1 53 0400 PER Subscriber Contact Information R 1 LOOP ID - 2100A DATE PHR IS GENERATED 1 56 0600 DTP Date PHR is Generated R 1 LOOP ID - 2110A ELECTRONIC FORMAT IDENTIFICATION 57 0900 EFI Electronic Format Identification R 1 59 1000 BIN Binary Data Segment R 1 60 1100 SE 275 Transaction Set Trailer R 1 1 20

ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE 3 005010271 275 2.3.2 12 Standard This section is included as a reference. The implementation guide reference clarifies actual usage. Refer to section 2.1 Presentation Examples for detailed information on the components of the 12 Standard section. 21

ASC 12N INSURANCE SUBCOMMITTEE 005010271 275 TECHNICAL REPORT TYPE 3 STANDARD 275 Patient Information Functional Group ID: PI This 12 Transaction Set contains the format and establishes the data contents of the Patient Information Transaction Set (275) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used to communicate individual patient information requests and patient information (either solicited or unsolicited) between separate health care entities in a variety of settings to be consistent with confidentiality and use requirements. Patient information consists of demographic, clinical, and other supporting data. Table 1 - Header PAGE # POS. # SEG. ID NAME REQ. DES. MA USE LOOP REPEAT 0100 ST Transaction Set Header M 1 0200 BGN Beginning Segment O 1 0300 DTM Date/Time Reference O 3 0400 TRN Trace O 5 LOOP ID - NM1 >1 0500 NM1 Individual or Organizational Name O 1 0600 IN1 Individual Identification O 1 0700 DMG Demographic Information O 3 0800 PRV Provider Information O 1 0900 PER Administrative Communications Contact O 2 1000 REF Reference Information O 5 1050 DTP Date or Time or Period O 1 LOOP ID - NM1/N1 5 1100 N1 Property or Entity Identification O 1 1200 N3 Party Location O 1 1300 N4 Geographic Location O 1 Table 2 - Detail PAGE # POS. # SEG. ID NAME REQ. DES. MA USE LOOP REPEAT LOOP ID - L >1 0100 L Transaction Set Line Number O 1 0150 TRN Trace O 1 0175 STC Status Information O 1 0200 NM1 Individual or Organizational Name O 1 0300 PRV Provider Information O 1 0400 PER Administrative Communications Contact O 1 0500 REF Reference Information O 5 LOOP ID - L/DTP >1 0600 DTP Date or Time or Period O 1 0700 CAT Category of Patient Information Service O 1 22

ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE 3 005010271 275 NOTES: 0800 PID Product/Item Description O 1 LOOP ID - L/DTP/EFI 1 0900 EFI Electronic Format Identification O 1 1000 BIN Binary Data Segment M 1 1100 SE Transaction Set Trailer M 1 1/0500 Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations. 1/0800 The PRV segment is only used in Loop NM1 when identifying a requestor or responder who is also a provider. 2/0150 The TRN segment in Loop L identifies a previously sent transaction set. The L loop provides supporting or additional information for that item when TRN is used. 2/0175 The STC segment in L loop identifies the status and action requested in a prior transaction when the response is provided in this transaction. 2/0200 The NM1 segment in loop L identifies an individual provider within a responder group. 23

ASC 12N INSURANCE SUBCOMMITTEE 005010271 275 TECHNICAL REPORT TYPE 3 2.4 275 Segment Detail This section specifies the segments, data elements, and codes for this implementation. Refer to section 2.1 Presentation Examples for detailed information on the components of the Segment Detail section. 24

TRANSACTION SET HEADER ST ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE 3 005010271 275 ST 275 TRANSACTION HEADER 005010271 275 TRANSACTION 275 HEADER ST SEGMENT DETAIL 53 ST - 275 TRANSACTION HEADER 12 Segment Name: Transaction Set Header 12 Purpose: To indicate the start of a transaction set and to assign a control number Segment Repeat: 1 Usage: REQUIRED 54 TR3 Example: ST2751234005010271~ DIAGRAM ST ST01 143 ST02 329 ST03 1705 TS ID TS Control Imple Conv Code Number Reference M 1 ID 3/3 M 1 AN 4/9 O 1 AN 1/35 ~ ELEMENT DETAIL USAGE REF. DES. DATA ELEMENT NAME ATTRIBUTES REQUIRED ST01 143 Transaction Set Identifier Code M 1 ID 3/3 Code uniquely identifying a Transaction Set SEMANTIC: The transaction set identifier (ST01) is used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set). 168 Use this code to identify the transaction set ID for the transaction set that will follow the ST segment. Each 12 standard has a transaction set identifier code that is unique to that transaction set. CODE DEFINITION 275 Patient Information REQUIRED ST02 329 Transaction Set Control Number M 1 AN 4/9 Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set 142 The Transaction Set Control Number in ST02 and SE02 must be identical. The number must be unique within a specific interchange (ISA-IEA), but can repeat in other interchange. 25

005010271 275 ST ASC 12N INSURANCE SUBCOMMITTEE 275 TRANSACTION HEADER TECHNICAL REPORT TYPE 3 REQUIRED ST03 1705 Implementation Convention Reference O 1 AN 1/35 Reference assigned to identify Implementation Convention SEMANTIC: The implementation convention reference (ST03) is used by the translation routines of the interchange partners to select the appropriate implementation convention to match the transaction set definition. When used, this implementation convention reference takes precedence over the implementation reference specified in the GS08. IMPLEMENTATION NAME: Implementation Convention Reference Identifier 190 005010271 This field contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (ST- SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time. 26

BEGINNING SEGMENT BGN ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE 3 005010271 275 BGN BEGINNING SEGMENT 005010271 BEGINNING SEGMENT 275 BGN SEGMENT DETAIL No ne BGN - BEGINNING SEGMENT 12 Segment Name: Beginning Segment 12 Purpose: To indicate the beginning of a transaction set 12 Syntax: Segment Repeat: 1 1. C0504 If BGN05 is present, then BGN04 is required. Usage: REQUIRED 55 TR3 Example: BGN0112345620060514083001~ DIAGRAM BGN BGN01 353 BGN02 127 BGN03 373 BGN04 337 BGN05 623 BGN06 127 TS Purpose Reference Date Time Time Reference Code Ident Code Ident M 1 ID 2/2 M 1 AN 1/50 M 1 DT 8/8 1 TM 4/8 O 1 ID 2/2 O 1 AN 1/50 BGN07 640 BGN08 306 BGN09 786 Transaction Action Security Type Code Code Level Code O 1 ID 2/2 O 1 ID 1/2 O 1 ID 2/2 ~ ELEMENT DETAIL USAGE REF. DES. DATA ELEMENT NAME ATTRIBUTES REQUIRED BGN01 353 Transaction Set Purpose Code M 1 ID 2/2 Code identifying purpose of transaction set 1000215 The values selected below are intended to capture the business scenarios of plan-to-plan PHR data transfer using existing approved 12 codes. Notes indicating a specific use for this implementation are included where appropriate. A petition to accommodate the specified business scenario will be submitted to 12. CODE DEFINITION 01 Cancellation 1000216 In this implementation, this value indicates Employer Group Change. 02 Add 1000217 In this implementation, this value indicates Individual Change. 03 Delete 1000218 In this implementation, this value indicates Employer Open Season. 27

005010271 275 BGN ASC 12N INSURANCE SUBCOMMITTEE BEGINNING SEGMENT TECHNICAL REPORT TYPE 3 REQUIRED BGN02 127 Reference Identification M 1 AN 1/50 Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier SEMANTIC: BGN02 is the transaction set reference number. IMPLEMENTATION NAME: Submitter Transaction Identifier REQUIRED BGN03 373 Date M 1 DT 8/8 Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year SEMANTIC: BGN03 is the transaction set date. IMPLEMENTATION NAME: Transaction Set Creation Date REQUIRED BGN04 337 Time 1 TM 4/8 Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99) SYNTA: C0504 SEMANTIC: BGN04 is the transaction set time. IMPLEMENTATION NAME: Transaction Set Creation Time NOT USED BGN05 623 Time Code O 1 ID 2/2 NOT USED BGN06 127 Reference Identification O 1 AN 1/50 NOT USED BGN07 640 Transaction Type Code O 1 ID 2/2 NOT USED BGN08 306 Action Code O 1 ID 1/2 NOT USED BGN09 786 Security Level Code O 1 ID 2/2 28

INDIVIDUAL OR ORGANIZATIONAL NAME NM1 ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE 3 005010271 275 1000A NM1 SENDER HEALTH PLAN NAME 005010271 SENDER HEALTH 275 PLAN 1000A NAME NM1 SEGMENT DETAIL 128 NM1 - SENDER HEALTH PLAN NAME 12 Segment Name: Individual or Organizational Name 12 Purpose: To supply the full name of an individual or organizational entity 12 Set Notes: 12 Syntax: 1. Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations. 1. P0809 If either NM108 or NM109 is present, then the other is required. 2. C1110 If NM111 is present, then NM110 is required. 3. C1203 If NM112 is present, then NM103 is required. Loop: 1000A SENDER HEALTH PLAN NAME Loop Repeat: 1 Segment Repeat: 1 Usage: REQUIRED 020 100 4 TR3 Notes: 1. Use this NM1 loop to identify the sender health plan for the PHR. 32 2. Use this NM1 segment to identify the organization that sends the enclosed personal health records. 016 100 7 TR3 Example: NM1PR2HEALTH PLAN ONENI123435~ DIAGRAM NM1 NM101 98 NM102 1065 NM103 1035 NM104 1036 NM105 1037 NM106 1038 Entity ID Entity Type Name Last/ Name Name Name Code Qualifier Org Name First Middle Prefix M 1 ID 2/3 M 1 ID 1/1 1 AN 1/60 O 1 AN 1/35 O 1 AN 1/25 O 1 AN 1/10 NM107 1039 NM108 66 NM109 67 NM110 706 NM111 98 NM112 1035 Name ID Code ID Entity Entity ID Name Last/ Suffix Qualifier Code Relat Code Code Org Name O 1 AN 1/10 1 ID 1/2 1 AN 2/80 1 ID 2/2 O 1 ID 2/3 O 1 AN 1/60 ~ 29

005010271 275 1000A NM1 ASC 12N INSURANCE SUBCOMMITTEE SENDER HEALTH PLAN NAME TECHNICAL REPORT TYPE 3 ELEMENT DETAIL USAGE REF. DES. DATA ELEMENT NAME ATTRIBUTES REQUIRED NM101 98 Entity Identifier Code M 1 ID 2/3 Code identifying an organizational entity, a physical location, property or an individual CODE DEFINITION PR Payer 27 For this implementation, the PHR data transfer is between two health plans. Other possible values are illustrative for situations where other types of entities may use the same transaction to transfer PHR in the future. REQUIRED NM102 1065 Entity Type Qualifier M 1 ID 1/1 Code qualifying the type of entity SEMANTIC: NM102 qualifies NM103. CODE DEFINITION 2 Non-Person Entity 27 For this implementation, the PHR data transfer is between two health plans. Other possible values are illustrative for situations where other types of entities may use the same transaction to transfer PHR in the future. REQUIRED NM103 1035 Name Last or Organization Name 1 AN 1/60 Individual last name or organizational name SYNTA: C1203 IMPLEMENTATION NAME: Information Source Last or Organization Name 118 Required to identify the information source. NOT USED NM104 1036 Name First O 1 AN 1/35 NOT USED NM105 1037 Name Middle O 1 AN 1/25 NOT USED NM106 1038 Name Prefix O 1 AN 1/10 NOT USED NM107 1039 Name Suffix O 1 AN 1/10 REQUIRED NM108 66 Identification Code Qualifier 1 ID 1/2 Code designating the system/method of code structure used for Identification Code (67) SYNTA: P0809 CODE DEFINITION 24 Employer s Identification Number 34 Social Security Number 1000093 Health plans may not transfer Social Security Numbers if other identification Numbers are sufficient for identification purposes (e.g. member ID, subscriber ID). The transfer of SSN s must be consistent with applicable federal and state laws. 46 Electronic Transmitter Identification Number (ETIN) 30

ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE 3 005010271 275 1000A NM1 SENDER HEALTH PLAN NAME NI National Association of Insurance Commissioners (NAIC) Identification PI Payor Identification 1000094 The intention for this value is to be used until the National Plan ID is mandated. For this version of the Implementation Guide to transfer PHR between payers, use the NAIC number as the plan ID corresponding to this ID qualifier. V Centers for Medicare and Medicaid Services PlanID CODE SOURCE 540: Centers for Medicare and Medicaid Services PlanID Centers for Medicare and Medicaid Services National Provider Identifier CODE SOURCE 537: Centers for Medicare & Medicaid Services National Provider Identifier REQUIRED NM109 67 Identification Code 1 AN 2/80 Code identifying a party or other code SYNTA: P0809 IMPLEMENTATION NAME: Information Source Identifier NOT USED NM110 706 Entity Relationship Code 1 ID 2/2 NOT USED NM111 98 Entity Identifier Code O 1 ID 2/3 NOT USED NM112 1035 Name Last or Organization Name O 1 AN 1/60 31

ADMINISTRATIVE COMMUNICATIONS CONTACT PER 005010271 275 1000A PER ASC 12N INSURANCE SUBCOMMITTEE INFORMATION SOURCE CONTACT INFORMATION TECHNICAL REPORT TYPE 3 005010271 INFORMATION 275 SOURCE 1000A CONTACT PER INFORMATION SEGMENT DETAIL 009 100 5 PER - INFORMATION SOURCE CONTACT INFORMATION 12 Segment Name: Administrative Communications Contact 12 Purpose: To identify a person or office to whom administrative communications should be directed 12 Syntax: 1. P0304 If either PER03 or PER04 is present, then the other is required. 2. P0506 If either PER05 or PER06 is present, then the other is required. 3. P0708 If either PER07 or PER08 is present, then the other is required. Loop: 1000A SENDER HEALTH PLAN NAME Segment Repeat: 1 Usage: REQUIRED 017 100 8 TR3 Notes: 1. Required to supply the contact information for the sender health plan. 018 100 6 TR3 Example: PERICHEALTH RECORD DEPARTMENTTE617111111F6171111112~ DIAGRAM PER PER01 366 PER02 93 PER03 365 PER04 364 PER05 365 PER06 364 Contact Funct Code Name Comm Comm Comm Comm Number Qual Number Number Qual Number M 1 ID 2/2 O 1 AN 1/60 1 ID 2/2 1 AN 1/256 1 ID 2/2 1 AN 1/256 PER07 365 PER08 364 PER09 443 Comm Comm Contact Inq Number Qual Number Reference 1 ID 2/2 1 AN 1/256 O 1 AN 1/20 ~ ELEMENT DETAIL USAGE REF. DES. DATA ELEMENT NAME ATTRIBUTES REQUIRED PER01 366 Contact Function Code M 1 ID 2/2 Code identifying the major duty or responsibility of the person or group named CODE DEFINITION IC Information Contact REQUIRED PER02 93 Name O 1 AN 1/60 Free-form name IMPLEMENTATION NAME: Sender Health Plan Contact Name 32