Personal Health Record Data Transfer Between Health Plans (275)

Transcription

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

2 BASED ON ASC VERSION HEALTH PLAN PERSONAL References to and data elements from the Continuity of Care Record (CCR) have been extracted, with permission, from ASTM E Standard Specification for Continuity of Care Record (CCR), copyright ASTM International, 100 Barr Harbor Drive, West Conshohocken, PA A copy of the complete standard may be purchased from ASTM, 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, (phone) (fax), hq@hl7.org. A copy of the pertinent standards may be purchased from HL7, Portions of the transaction and version Technical Report Type 3 have been reproduced with permission of Washington Publishing Company (WPC) [ and the Accredited Standards Committee 12 (ASC 12) [ through their secretariat, the Data Interchange Standards Association, Inc., (DISA) [ 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 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 ii

3 HEALTH PLAN PERSONAL BASED ON ASC VERSION Table of Contents 1 Purpose and Business Information Implementation Purpose and Scope Version Information Implementation Limitations File Size Limitation Business Use PHR Data Transfer Process: Employer Group Change PHR Data Transfer Process: Individual Change PHR Data Transfer Process: Employer Open Season Business Terminology Transaction Acknowledgments Functional Acknowledgment Implementation Acknowledgment Data Overview Operating Rules Transaction Sets Presentation Examples Implementation Usage Industry Usage Loops Transaction Set Listing Implementation Standard Segment Detail ST 275 Transaction Header BGN Beginning Segment NM1 Sender Health Plan Name PER Information Source Contact Information NM1 Recipient Health Plan Name PER Recipient Health Plan Contact Information NM1 Information Requestor Name PER Information Requestor Contact Information REF Request Tracking Information DTP Date PHR Transfer Was Requested L Assigned Number NM1 Subscriber Name PER Subscriber Contact Information DTP Date PHR is Generated EFI Electronic Format Identification BIN Binary Data Segment SE 275 Transaction Set Trailer iii

4 BASED ON ASC VERSION HEALTH PLAN PERSONAL 3 Examples Business Scenario - Use of 275 Plan to Plan PHR Transfer A External Code Sources...A International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)...A Current Procedural Terminology (CPT) Codes...A Health Industry Level 7 (HL7)...A Centers for Medicare & Medicaid Services National Provider Identifier...A Centers for Medicare and Medicaid Services PlanID...A International Classification of Diseases, 10th Revision, Procedure Coding System (ICD-10-PCS)...A 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

5 HEALTH PLAN PERSONAL BASED ON ASC VERSION 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

6 BASED ON ASC VERSION HEALTH PLAN PERSONAL vi

7 HEALTH PLAN PERSONAL BASED ON ASC VERSION 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 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

8 BASED ON ASC VERSION 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 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 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

9 HEALTH PLAN PERSONAL BASED ON ASC VERSION 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

10 BASED ON ASC VERSION 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 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 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

11 HEALTH PLAN PERSONAL BASED ON ASC VERSION 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 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 Individual Change 5

12 BASED ON ASC VERSION 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 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

13 HEALTH PLAN PERSONAL BASED ON ASC VERSION Figure 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

14 BASED ON ASC VERSION 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 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

15 HEALTH PLAN PERSONAL BASED ON ASC VERSION The plan to plan PHR transfer standard uses the 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

16 BASED ON ASC VERSION 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: ) 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 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 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

17 HEALTH PLAN PERSONAL BASED ON ASC VERSION transfer standard. The detailed data domains with data elements are included as Appendix A - PHR Data Dictionary. Table 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 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

18 BASED ON ASC VERSION 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

19 HEALTH PLAN PERSONAL BASED ON ASC VERSION 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

20

21 HEALTH PLAN PERSONAL BASED ON ASC VERSION 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

22 BASED ON ASC VERSION Implementation Usage HEALTH PLAN PERSONAL 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

23 HEALTH PLAN PERSONAL BASED ON ASC VERSION 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 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

24 BASED ON ASC VERSION HEALTH PLAN PERSONAL 18

25 ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE Transaction Set Listing 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

26 ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE MAY IMPLEMENTATION 4, Health Plan Personal Health Record Data Transfer Table 1 - Header PAGE # POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT ST 275 Transaction Header R BGN Beginning Segment R 1 LOOP ID A SENDER HEALTH PLAN NAME NM1 Sender Health Plan Name R PER Information Source Contact Information R 1 LOOP ID B RECIPIENT HEALTH PLAN NAME NM1 Recipient Health Plan Name R PER Recipient Health Plan Contact Information R 1 LOOP ID C INFORMATION REQUESTOR NAME NM1 Information Requestor Name R PER Information Requestor Contact Information R REF Request Tracking Information R DTP Date PHR Transfer Was Requested R 1 Table 2 - Detail PAGE # POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT LOOP ID A ASSIGNED NUMBER > L Assigned Number R NM1 Subscriber Name R PER Subscriber Contact Information R 1 LOOP ID A DATE PHR IS GENERATED DTP Date PHR is Generated R 1 LOOP ID A ELECTRONIC FORMAT IDENTIFICATION EFI Electronic Format Identification R BIN Binary Data Segment R SE 275 Transaction Set Trailer R

27 ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE 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

28 ASC 12N INSURANCE SUBCOMMITTEE 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 BGN Beginning Segment O DTM Date/Time Reference O TRN Trace O 5 LOOP ID - NM1 > NM1 Individual or Organizational Name O IN1 Individual Identification O DMG Demographic Information O PRV Provider Information O PER Administrative Communications Contact O REF Reference Information O DTP Date or Time or Period O 1 LOOP ID - NM1/N N1 Property or Entity Identification O N3 Party Location O N4 Geographic Location O 1 Table 2 - Detail PAGE # POS. # SEG. ID NAME REQ. DES. MA USE LOOP REPEAT LOOP ID - L > L Transaction Set Line Number O TRN Trace O STC Status Information O NM1 Individual or Organizational Name O PRV Provider Information O PER Administrative Communications Contact O REF Reference Information O 5 LOOP ID - L/DTP > DTP Date or Time or Period O CAT Category of Patient Information Service O 1 22

29 ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE NOTES: 0800 PID Product/Item Description O 1 LOOP ID - L/DTP/EFI EFI Electronic Format Identification O BIN Binary Data Segment M 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

30 ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE 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

31 TRANSACTION SET HEADER ST ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE ST 275 TRANSACTION HEADER TRANSACTION 275 HEADER ST SEGMENT DETAIL 53 ST 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: ST ~ DIAGRAM ST ST ST ST 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 ST 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 ST 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

32 ST ASC 12N INSURANCE SUBCOMMITTEE 275 TRANSACTION HEADER TECHNICAL REPORT TYPE 3 REQUIRED ST 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 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

33 BEGINNING SEGMENT BGN ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE BGN BEGINNING SEGMENT 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: BGN ~ DIAGRAM BGN BGN BGN BGN BGN BGN BGN 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 BGN BGN BGN 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 BGN Transaction Set Purpose Code M 1 ID 2/2 Code identifying purpose of transaction set 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 In this implementation, this value indicates Employer Group Change. 02 Add In this implementation, this value indicates Individual Change. 03 Delete In this implementation, this value indicates Employer Open Season. 27

34 BGN ASC 12N INSURANCE SUBCOMMITTEE BEGINNING SEGMENT TECHNICAL REPORT TYPE 3 REQUIRED BGN 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 BGN 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 BGN 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 BGN Time Code O 1 ID 2/2 NOT USED BGN Reference Identification O 1 AN 1/50 NOT USED BGN Transaction Type Code O 1 ID 2/2 NOT USED BGN Action Code O 1 ID 1/2 NOT USED BGN Security Level Code O 1 ID 2/2 28

35 INDIVIDUAL OR ORGANIZATIONAL NAME NM1 ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE A NM1 SENDER HEALTH PLAN NAME 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 TR3 Notes: 1. Use this NM1 loop to identify the sender health plan for the PHR Use this NM1 segment to identify the organization that sends the enclosed personal health records TR3 Example: NM1PR2HEALTH PLAN ONENI123435~ DIAGRAM NM1 NM NM NM NM NM NM 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 NM NM NM NM NM NM 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

36 A NM1 ASC 12N INSURANCE SUBCOMMITTEE SENDER HEALTH PLAN NAME TECHNICAL REPORT TYPE 3 ELEMENT DETAIL USAGE REF. DES. DATA ELEMENT NAME ATTRIBUTES REQUIRED NM 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 NM 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 NM 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 NM Name First O 1 AN 1/35 NOT USED NM Name Middle O 1 AN 1/25 NOT USED NM Name Prefix O 1 AN 1/10 NOT USED NM Name Suffix O 1 AN 1/10 REQUIRED NM 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 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

37 ASC 12N INSURANCE SUBCOMMITTEE TECHNICAL REPORT TYPE A NM1 SENDER HEALTH PLAN NAME NI National Association of Insurance Commissioners (NAIC) Identification PI Payor Identification 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 NM Identification Code 1 AN 2/80 Code identifying a party or other code SYNTA: P0809 IMPLEMENTATION NAME: Information Source Identifier NOT USED NM Entity Relationship Code 1 ID 2/2 NOT USED NM Entity Identifier Code O 1 ID 2/3 NOT USED NM Name Last or Organization Name O 1 AN 1/60 31

38 ADMINISTRATIVE COMMUNICATIONS CONTACT PER A PER ASC 12N INSURANCE SUBCOMMITTEE INFORMATION SOURCE CONTACT INFORMATION TECHNICAL REPORT TYPE INFORMATION 275 SOURCE 1000A CONTACT PER INFORMATION SEGMENT DETAIL 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 TR3 Notes: 1. Required to supply the contact information for the sender health plan TR3 Example: PERICHEALTH RECORD DEPARTMENTTE F ~ DIAGRAM PER PER PER02 93 PER PER PER PER 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 PER PER PER 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 PER 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