Group Minutes X12N TG2 WG02 Health Care Claims September 24-28, 2006

Transcription

1 Group Minutes X12N TG2 WG02 Health Care Claims September 24-28, 2006 Chair(s) Name Company Term End Date Phone John Bock Individual Member After February Ph: meeting Debbi Emdeon After February Ph: Meisner 2008 meeting Conny Nichols Claredi, an Ingenix Division After February 2007 meeting Ph: com Doug Renshaw Highmark After October 2007 meeting Ph rk.com Secretary(s) Name Company Term End Date Phone Katie Sullivan Fox Systems Ph: Ph: Ph: Quorum Requirement Statement (please check one) This group enforces quorum requirements for group voting items. This group does not enforce quorum requirements for group voting items. X Work Products and Status (e.g. Transaction Sets, Implementation Guides, UN/CEFACT development, etc.) Work Product ID Work Product Name Work Product Status # (if applicable) X Health Care Claim: Professional Project Proposal Drafted X Health Care Claim: Institutional Project Proposal Drafted X Health Care Claim: Dental Project Proposal Drafted X Health Care Service: Data Reporting Project Proposal Drafted Next Trimester Meeting Notification Date: January 28- February 2, 2007 Location: Denver, CO Contact Person: John Bock, Conny Nichols, Doug Renshaw, Debbi Meisner Agenda (include key items): DMs DSMOs Other Business Elections Scheduled (include position and term dates): Conny Nichols position- term through February Special Meeting Notification (e.g. Interim Conference Calls, Industry Meetings, Regulatory Agency Meetings, etc.) Date: Conference Calls: 2 nd and 4 th Thursdays of the month, 1:00 PM EST. Location: Conference Call (full workgroup) Contact Person: John Bock Agenda: Other Business Executive Summary of Current Meeting (optional, but recommended):

2 Date: Location: Agenda: Summary of Major Accomplishments: Elections Held (include position, term dates, and individual s name): Date and Minutes of Current Meeting Date: September 24-28, 2006 Location: Boston, Massachusetts HIR Process The HIR process allows for people to request implementation guide interpretations from the individual workgroups. There is currently a small workgroup in place that reviews and drafts responses to those interpretation requests. This process includes a 7 day review with an additional 2 day review of drafted responses. At this point the draft response goes to management for final approval. The workgroup is looking for additional people to participate in this process. Interested parties may join the HIR review listserve by sending an to John Bock: jbock@prodigy.net HIR point people Laurie Burckhardt Institutional Mark Carter- Professional Teresa Jensen- Dental HCP Update At the last trimester meeting the HCP rejection reason codes were discussed. Some of these codes did not make sense as they required rejection of a claim back to a provider. It was felt that most providers are not used to receiving a claim transaction, but rather they are used to a report or other such rejection notification. A survey of known repricers was conducted in order to identify currently used codes for HCP13. Results of this survey indicate the only 2 values being used by repricers for data element HCP13 are: T1 and T6. Motion: To remove all the values for HCP13 other than T1 and T6. Discussion: None Decision: Motion carries with 34 abstentions HIR 407- Ambulance Workaround Background: The current version of the guides (4010A1) does not support the reporting of pick-up and drop off locations necessary for some payers to pay ambulance claims.

3 At an earlier meeting a proposed workaround was developed, this workaround was later determined to not work. This work was left open for a small sub-workgroup to develop a different workaround, but was not finalized. HIR 407: Requests confirmation of a workaround for reporting pick-up and drop-off location. On the August 24, 2006 interim call a workaround was drafted, but it was discovered that there were multiple workarounds already being used throughout the industry and that a single one did not work for everyone. Due to this, the workgroup will not develop or recommend a single workaround for this or other items. The official response to HIR 407 will be to not develop a workaround. Individuals who need further information can be referred to others who have successful workarounds in production. Question: Why would we need to develop a work around? Response: The 4010 does not support the pickup and drop off locations as is needed by the industry. This has been addressed in future guides. Question: Where will this information be reported in the future? Response: It is accommodated at both the claim level 2310 and service level 2420 for future guides. DMs Background: At the last trimester meeting, the workgroup split into small groups to review the current standard and to draft DMs necessary to support requested changes as well as clean up some of the notes which were contradictory to current usages. Not all of the drafted DMs were reviewed and approved and the workgroup will continue this review so that we can move the DMs forward for approval. -SV1 and SV3 diagnosis pointers- The composite for the diagnosis pointer only allows for the identification of 4 diagnosis codes at the service level, although more than 4 dx codes may be reported for the entire claim. It was suggested that there should be a 1-to-1 relationship, but it wasn t felt that this was really necessary. The workgroup should determine what a responsible maximum would be. Some individuals felt that with ICD-10 on the horizon, this may create a need for additional reporting, while others felt that the added specificity of ICD-10 may eliminate the need to report multiple dx codes to accurately define a condition. At one point, there was a way to report that all dx codes reported apply to the service line, is this something we want to consider? This would not eliminate the need for additional dx pointers. Question: Is there a specific business need to support adding additional dx code pointers? Response: Yes, the 5010 comments included a chiropractic need and others are aware of a need for some laboratory services. Business Case: Composite C004 (composite diagnosis code pointer) is now limited to a max of 4 diagnosis code pointers. There are cases where at least 6 are necessary in today's environment. The transition to ICD-10 may cause an even greater deficiency. Proposed Work: Increase the number of diagnosis pointers in C004 to 8.

4 Motion: To approve this DM that changes the number of dx pointers from 4 to 8. Discussion: Will this impact the paper billing forms? This would create a disparity between paper and electronic. Note: This change would not come into effect anytime soon. Decision: Motion carries with 0 opposed and 14 abstentions. K3 Segment DMs Background: Under the Administrative Simplification provisions of the Health Insurance Portability and Accountability Act (HIPAA), the NCPDP Telecommunications Standard version 5.1 and its corresponding Batch Standard version 1.1 were adopted as the approved electronic transactions for transmitting drug product billings from retail pharmacies. The ASC X12N 837P is the approved transaction for all types of professional services, the 837I for institutional services and the 837D for dental services. The first regulation published August 17, 2000 indicated that all drugs must be billed with NDC and stated the intent to eliminate HCPCS Level II codes for all drugs. Many comments were received objecting to this decision, but the regulation stood citing the need for the NDC to do rebates. Regulation (50328) states that the NCPDP transaction must be used by retail pharmacies but professional pharmacy claims must use the 837P with both the NDC and HCPCS. At this point, the SV4 segment was present in the Implementation Guide (IG) for the 837 transaction for the RX number. In 2003, the Transaction and Code Set (TCS) Rule was modified to address NDC coding. The requirement was dropped to require the use of an NDC for all drug billing except on NCPDP transactions, For the X12N transactions there would be no direct HIPAA regulatory standard for coding drugs, so the X12N standards would define the coding requirement. The X Addenda process was initiated which included removal of the SV4 segment and insertion of the 2410 drug loop (subordinate to the claim line service code SV1 and SV2). This would allow the X transactions to show the HCPCS as primary billing code with an optional NDC. The 2410 loop included three segments LIN (Drug Identification segment), CTP (Drug Pricing segment) and REF (Prescription Number) to satisfy data needs for rebate purposes. The 4010A1 allows for 25 repeats of the 2410 to accommodate compound drugs. The 4050 version changed the structure to only allow one line level service (HCPCS) and NDC. Compound billing changed to require one line for each compound, linked by the RX or linkage number. In 2003, a Medicare FAQ was written to clarify what transaction a Home Infusion Therapy provider should use. It stated: Although Home Infusion Therapy providers may be licensed as retail pharmacies in some states, their model for dispensing drugs and biologics for infusion, injection, or inhalation is very different from that of traditional retail pharmacies. While the NCPDP claim format works well for the typical drug-dispensing activities performed by traditional retail pharmacies, it does not meet the administrative, clinical, coordination of care, and medical necessity requirements for Home Infusion Therapy claims. The ASC X12N 837 is the required standard format for claims for the provision of Home Infusion Therapy. [FAQ 1880] Comments were submitted during the 5010 comment period to add additional data elements to the 5010 version to accommodate the billing and pricing of drug data. The comments were rejected citing the need for data maintenance to the standard.

5 In 2003, the Medicare Modernization Act became law. By requiring most Part D drugs to be billed on an NCPDP transaction, CMS created the need to map 837P claims billed with an NDC into an NCPDP transaction for processing by their PBM. In 2005, CMS, NCPDP, and X12 worked together to create a mapping of the 837 data elements into their equivalent NCPDP data elements. A combination of payer, provider, SDO and government representatives participated in the activities. Most of the data needs were mapped successfully. However, twenty NCPDP data elements had no 837 equivalent. With the Medicare Part D effective date of 1/1/2006 looming, it was concluded that there was no other alternative than to use the K3 in both the 2300 and 2400 loops for these remaining data elements if situationally required by the NCPDP data dictionary for use in Medicare Part D. HIR #347 was submitted requesting the use of the K3 segment in the 2300 and 2400 loops to obtain information necessary to process a NCPDP 5.1 Claim Billing transaction. On 12/20/2005, TG2 affirmed WG2 s approval and granted permission for this limited use for Part D claims. However, the use of the K3 segments is a temporary solution and a permanent home in the standard needs to be found for these data elements. Work has continued for the past year to place the K3 drug data approved with HIR347 into a formal and permanent 837P location. The DM s before you are a result of these efforts. K Loop Proposed solution NCPDP K3 Bytes Field Description Segment Comment 403-D3 1-2 Fill Number SV D6 3 Compound Code SV D8 4 Dispense as Written (DAW)/Product Selection Code SV DK 5 Submission Clarification Code SV421 NEW FIELD 429-DT 6 Unit dose SV EU 7-8 Prior Authorization Type Code SV missing value DC 9-16 Dispensing Fee AMT02 add segment; AMT01 = D7 482-GE % Sales Tax Amount Submitted SV424 NEW FIELD 483-HE % Sales Tax Rate Submitted SV425 NEW FIELD 484-JE % Sales Tax Basis Submitted SV426 NEW FIELD 426-DQ Usual and Customary Charge AMT02 add segment; AMT01 = F9 (Actual) 423-DN Basis of Cost Determination SV E DUR Reason for Service Code SV707-1 NEW FIELD 440-E DUR Professional Service Code SV707-2 NEW FIELD 441-E DUR Result of Service Code SV707-3 NEW FIELD 439-E DUR Reason for Service Code SV707-1 NEW FIELD 440-E DUR Professional Service Code SV707-2 NEW FIELD 441-E DUR Result of Service Code SV707-3 NEW FIELD 439-E DUR Reason for Service Code SV707-1 NEW FIELD 440-E DUR Professional Service Code SV707-2 NEW FIELD 441-E DUR Result of Service Code SV707-3 NEW FIELD

6 414-DE Date Prescription Written DTP03 DTP01 = C8 70 Other Coverage Code SV422 NEW FIELD K Loop NCPDP Bytes Field Description Segment Comment 450-EF 1-2 Compound Dosage Form Description Code 452-EH 3-4 Compound Route of Administration 49O-UE 5-6 Compound Ingredient Basis of Cost Determination DMs Add SV4 segment to the 2410 loop. SV414 SV423 SV412 NEW FIELD Business Case: Data elements currently mapped to the K3 segments need a permanent location in the 837 standard to support drug information necessary for Medicare part D drug claims. The SV4 segment was identified as a logical segment to use since it already contained many of the data elements currently mapped in the K3 segments. The SV4 segment is currently defined in the 2400 loop of the 837 transaction but other drug information is currently defined in the 2410 loop of the 837 transaction. In order to take full advantage of the 2410 drug loop, it is necessary to add the SV4 segment in the 2410 loop. Proposed Work: Add the SV4 segment to the 2410 loop. Motion: To approve DM to add the SV4 to the 2410 loop. Discussion: Is this for home infusion only? This is for the standard which could be used by anyone in development of an IG. Is there another way to accommodate this, such as imbed an NCPDP transaction within the 837 as is done for attachments? It is felt that this would create a level of complexity that we may not really be ready for. Why not just move the SV4 from 2400 to 2410? Since others may be using it at the 2400 loop, it makes better sense to add it. Will changes be made to the SV1 or SV4 to eliminate duplication of information? Yes, this can be addressed. Decision: Motion carried with none opposed and many abstentions. Motion: To change the business case for the SV4 DM indicating what the K3 segment is being used for. (Note: This new language has been included in the business case detailed above.) Discussion: None Decision: Motion carries with 0 opposed and many abstentions. Add SV7 segment to the 2410 loop. Business Case: Data elements currently mapped to the K3 segments need a permanent location in the 837 standard to support drug information necessary for Medicare part D drug claims. The SV7 segment was identified as a logical segment to use for the drug use review (DUR) information since the SV706 data element is a DUR indicator. The SV7 segment is currently defined in the 2400 loop of the 837 transaction but other drug information is

7 currently defined in the 2410 loop of the 837 transaction. In order to take full advantage of the 2410 drug loop, it is necessary to add the SV7 segment in the 2410 loop. Proposed Work: Add the SV7 segment to the 2410 loop. Motion: To add the SV7 to the 2410 loop Discussion: We need to add to the business cases to indicate what the K3 segment is being used for, it was agreed to add language this language and is included in the business case detailed above. Decision: Motion carries with 0 opposed and many abstentions. Add additional data elements to the SV4 segment. Need to add the following 6 elements: Submission clarification code Other coverage code Route of administration Percent sales tax amount submitted Percent sales tax rate submitted Percent sales tax basis submitted Business Case: Data elements currently mapped to the K3 segments need a permanent location in the 837 standard to support drug information necessary for Medicare part D drug claims. The SV4 segment was identified as a logical segment to use since it already contained many of the data elements currently mapped in the K3 segments. However, the SV4 segment does not contain all the necessary data elements. Proposed Work: Add six new data elements to the SV4 segment. SV419 - Submission clarification code SV420 - Other coverage code SV421 - Route of administration SV422 - Percent sales tax amount submitted SV423 - Percent sales tax rate submitted SV424 - Percent sales tax basis submitted Motion: To accept this DM and add the 6 data elements to the SV4 (presumably new data elements, but workgroup accepts that architecture will identify specifics for data element identification) Discussion: Concerns were expressed that the workgroup needs to discuss data elements 1 at a time. Note: these are approved NCPDP billing requirements that are currently being mapped into the K3. If we felt this was an incorrect list we would have to work with NCPDP. Concerns were expressed that other insurance is already on the 837, there is a y/n indicator, but the NCPDP code set goes beyond this. Note: The workgroup is trying to meeting the business need established by the Part D regulation. In addition, since the workgroup approved the use of the K3 segment we now have an obligation to find a permanent home for this information. Question: Are we really creating new data elements or adding to existing data elements? Response: The workgroup won t be deciding this detail necessarily, architecture will likely decide new vs. existing. There has been some work already done surrounding this, but architecture may have a different recommendation. Note: These data elements will reference external code sets and will point to the NCPDP for values. Decision: Motion carries with none opposed and many abstentions.

8 Add a repeating composite data element to SV7 Workgroup needs to add a composite data element to SV7 which will capture the following information: Reason for service code- This is the type of utilization conflict detected Professional service code- This is the pharmicist s intervention action consulted. Result of service code- This is the action taken by the pharmacists Business Case: Data elements currently mapped to the K3 segments need a permanent location in the 837 standard to support drug information necessary for Medicare part D drug claims. The SV7 segment was identified as a logical segment to use for the drug use review (DUR) information because the SV706 data element is a DUR indicator. However, the SV7 segment does not contain the necessary data elements to indicate the specific DUR information. Proposed Work: Create a repeating composite data element for a drug use review (DUR) alert and add the data element to the SV7 segment. The composite could occur 6 times and contain these three required data elements: Reason for service code Professional service code Result of service code Motion: To approve DM creating a new composite data element for the drug use review (DUR) to allow for the reporting of: Reason for service code Professional service code Result of service code This composite could repeat up to 6 times. The workgroup presumes architecture will create and/or assign data elements as necessary. Discussion: Is 3 enough repeats? The sub-groups mission was to find locations for each of the elements carried in K3 and this was could be accomplished with 3 repeats. Some felt it was better to change increase the repeats to allow for greater reporting capability if necessary in the future. The IG can still limit its use to 3. Concern was originally expressed over inclusion of the semantic note indicating the order of use had no significance, but this was determined to be okay. Decision: Motion carries with many abstentions. DMs SV109, SV111, and SV112 There are several data elements in the SV1 segment that are Y/N indicators. The workgroup has determined to only utilize these elements when the situation applies and DMs are necessary to change the semantic notes which imply a requirement by defining both the Y and N values. General Business Case: The definition of both the Y and N values creates an implied requirement. The note should be modified to only address the Y value. General Proposed Work: The proposed work removes language in the semantic notes surrounding the N value.

9 Motion: To approve all 3 DMs to remove the N value definition in the semantic notes for SV109, SV111, and SV112.. Discussion: None Decision: Motion carries. Misc Updates DSMO # This DSMO requests the use of LOINC codes in the PWK segment for type of attachment. No actual work has been done yet on this and much of this work will be done by the joint workgroup. The claims attachment group is currently working on responding to comments received during the NPRM comment process. HSAs- At this time there is nothing new to discuss. There have been no new models identified and many organizations are just trying to figure out how to do this and to set up processes surrounding it. HIRs #453 The 837p IG does not provide specific instruction when it comes to what type of amount should appear in 2300 CLM02. Industry standard, when it comes to Ambulance claims, has always been the Gross Charge total for the claim. Adjustments are not subtracted to form this total. Recently one carrier has begun requiring Net amount to appear here or they will end up paying the gross amount for the claim and forcing the provider to refund them later. The carrier advised they are aware of the issue and that they will correct it sometime in future. We are not looking for proof they are non-compliant, but we would like to know if there is some clarification we are missing as to amount for that field in order that we, the software vendor, will be able to determine if we should indeed add an option for users to output NET amount in CLM02. The workgroup discussed that this amount should be a standard representation across the board especially because of COB. Draft Response for HIR 453: The CLM02 is the total claim charge amount. It represents the total billed charges for all of the service lines within the claim in order to create a balanced claim. Any adjustments to the total billed charges should be addressed in the adjudication process and the subsequent remittance advice. If this varied by carrier, it would cause problems with COB Claims. The provider would not be able to fulfill their obligation to report the remittance information as they received it and still have a balanced claim. Note: This draft response will be added to the web board. # 449 Would it be HIPAA compliant to submit two repeats of the Loop 2300 REF (Prior Authorization/ Referral Number) with the qualifier for prior authorization (G1)? We were not sure if the two repeats of this segment could only be used if each of the qualifiers is different (e.g. G1 and 9F). The institutional transaction appears to only allow prior authorization at the claim level. We have scenarios that require two prior authorizations for the various services on the claim. Thanks. Draft Response for HIR 449:

10 Like qualifiers sent in two Prior Authorization or Referral Number REF segments do not violate the X096A1 Institutional Claim implementation guide. However, submitters should recognize that receivers may have difficulty matching prior authorization or referral numbers to the correct service when two authorization or two referrals are submitted on the same institutional claim. Receivers may also overlay the first prior authorization or referral number REF with the second received. Draft proposed recommendation: The workgroup strongly recommends that submitters not send more than one prior authorization or more than one referral per institutional claim (that is, per CLM loop ID-2300) Disclaimer: X12N's interpretations are intended only to clarify the implementation guides. It is not within X12N's scope to comment on the actions of specific entities such as regulatory bodies, carriers, and providers, nor to render an opinion on an individual entity's compliance with HIPAA or other federal or state regulations. Requests concerning interpretations of the HIPAA regulations as issued by the Department of Health and Human Services should be submitted via to Note: This draft response will be added to the web board. TG4 Liaison There was discussion surrounding the need for a workgroup volunteer to participate in TG4. This liaison would represent the workgroup and provide feedback as necessary. If there are interested parties, they may discuss with the co-chairs. Update for Attachment/Claims Joint Workgroup At a previous trimester meeting, volunteers signed up for a joint workgroup between X12 and HL7 to look at data collected in claims, attachments, and Pas and identify changes as well as addressing future business needs. As of this time, the project plan is still being developed. Once a project plan is completed, it will move forward into management development. At this time there will probably be a kickoff conference call to set ground rules etc. Note: Others interested in this joint transaction workgroup should send an to Conny. Conny.Nichols@Ingenix.com DM At the last trimester meeting, the workgroup approved a DM recognizing a new code list and establishing a way to access this code list for the reporting of payer typology. The Payer Typology code list code list was developed by the Public Health Data Standards Consortium and creates a more granular way for reporting type of payer than is currently available in the SBR09. Architecture had some issues with the code list and its structure. Architecture wanted to be able to look up a single code, rather than using the various levels as established in the code list. In order to address this, the code list was flattened out creating a need for increased data length for its reporting.

11 In order to do this the DM for accomplishing this needed be changed and expand the maximum data length from 4 to 6 bytes. Motion: To re-approve this modified DM. Discussion: None Decision: Motion carries with none opposed and 2 abstentions. Management Update --The comparison between the 4010 and 5010 will have a picture of the 4010A1 and the 5010 and there will be a header that explains the change. These are being developed by the publisher. --The focus was on legislative update and real time transactions which will be discussed later common content is produced by TG4 and contains the structure we use to develop new TR3s. It is being developed prior to our development of the TR3s and therefore, now is the time to make comments on the front matter. The workgroup should review the common content now. The 5020, for all practical purposes is pretty much done. Any comments will be applied for future versions. The workbook contains rules for the guide development process as well as the common content (such as appendix B, front matter). The long term objective is to expand on the common content to include those items that do not change across the guides such as the ST and SE segments. Due to this change, the workgroup needs to start following and paying attention to this development. Note: the 5020 will be finalized at this meeting. ACTION: Co-chairs will communicate how to access this workbook. When this is made available co-chairs will also ID a timeline for reviewing. Question: How should comments be submitted? Response: Through the co-chairs and they will compile them and develop a workgroup comment. Individuals can still send comments directly to TG4 especially if they disagree with the workgroup comment. PS1 A question came up about the PS1 segment in conjunction with the NPI, is there not a way to report an NPI for PS1? The NPI would be reported in PS101. This is clearer in the 5010, where a note specifically ties it back to the purchase service provider loop, where the identifier reported in the purchase service provider loop is also reported in PS101 which is an NPI if you have one. The identifier is being placed in both locations since PS101 is a mandatory element. Taxonomy There is a problem with the way the notes are written surrounding taxonomy in the 4010A1 versions of the 837 guides. The professional and dental guides only allow for the reporting of taxonomy at the billing/pay to level when this information represents the rendering provider. This is not sufficient with the introduction of group taxonomies and there may be a need to collect both the group taxonomy and the rendering taxonomy.

12 On the institutional side, the note restricts the use to the billing/pay to level when it represents the service facility and is wrong in other ways. Gail Kocher and John are working with OESS to develop an FAQ which addresses these short comings and opens up the use of taxonomy in the implementation guides. Question: Will an FAQ work on the compliance level? Response: Yes, the purpose of the FAQ in this instance is to supercede/clarify the rule or IG in this case. Update on DMs After meeting with architecture there were several modifications made to the earlier DMs. Note: The workgroup does not need to re-vote on all of these as many were approved contingent on architecture s counsel. -The 2 DMs written for moving the segments to the drug loop has become a single DM. - A data element for percentages was located and will add the word Drug DMs that require additional changes are detailed below: -SV107- Original DM increased the pointers from 4 to 8, after meeting with architecture their preferred handling from a design perspective is to use a repeating data element. This would include an elimination of C004 composite and making it a repeating data element. Question: Does this make the DM more difficult? Not really, we have the option to do what we originally requested, make the composite a repeating composite or make a repeating data element. Question: Isn t there an aspect of the composite that establishes a hierarchy? Yes, right now the order is significant and the repeating data element will need to establish the same. There were some concerns that the repeating data element would be more confusing because we still have the composite elements throughout the standard, others felt this was simply an education issue. Nobody was opposed to moving forward with the repeating data element. Business Case: Composite C004 (composite diagnosis code pointer) is now limited to a max of 4 diagnosis code pointers. There are cases where at least 6 are necessary in today's environment. The transition to icd-10 may cause an even greater deficiency. Proposed Work: Delete C004 composite diagnosis code pointer. Redefine SV107, SV311, SV605, EB14, and EQ05 to a repeating data element. Make the date element 1328 a repeating data element with a repeat of 12. Add a semantic note to indicate significance of order. "The first pointer designates the primary diagnosis and remaining diagnosis pointers indicate declining level of importance. Motion: To change the repeat to 12 in the underlying standard. Discussion: None Decision: Motion carries with several abstentions.

13 Motion: To approve the revised DM and move forward to other impacted workgroups Discussion: None Decision: Motion carries with 2 abstentions. -LQ- The workgroup failed to include a position for the segment in the proposed work. So we chose 5507 and selected 99 repeats to align with the 835 standard. Proposed Work: Add LQ to the 2430 loop in the 837 standards in position The segment will be optional with a repeat of 99. Motion: To approve this modification and move this DM forward. Discussion: On this DM we reference the 835, but we are not making a change to the 835? Correct, the 835 will be removed. Decision: Motion carries with 1 abstention. -Y/N indicator- There were a number of DMs done for the Yes/No indicators. Original notes surrounding the Yes/No indicators reference both the Y value and the N value. The workgroup decided to only require these elements when the situation was met. Architecture asked for further clarification in the business cases. addition to the language already included in the business cases. The workgroup will add; In This was exemplified by several comments received during the comment period indicating that the TR3 did not include the value of "N" in the list of codes. The workgroup decision is to not use the data element unless the situation applies. Motion: To move forward with the Y/N indicator DMs to include this new business case language. Discussion: None Decision: Motion carries with 3 abstentions. -MIA and MOA- Within the MIA and MOA segments the semantic note references the code source number as part of the semantic note. Per architecture the place for reporting a code source reference is not the semantic note. Business Case: Each of the semantic notes for these data elements references the code source 411 in the semantic note. The code source reference should be removed from the semantic note and listed as a code source reference independent of the semantic note. Proposed Work:

14 Revise semantic notes to: Semantic: MIA05 is the claim payment remark code. Semantic: MIA20 is the claim payment remark code. Semantic: MIA21 is the claim payment remark code. Semantic: MIA22 is the claim payment remark code. Semantic: MIA23 is the claim payment remark code. Semantic: MOA03 is the claim payment remark code. Semantic: MOA04 is the claim payment remark code. Semantic: MOA05 is the claim payment remark code. Semantic: MOA06 is the claim payment remark code. Semantic: MOA07 is the claim payment remark code. Add to each of these data elements: "code source 411: claim payment remark code. Motion: To move this DM forward. Discussion: Since this is a semantic note, does the 835 have to approve it? Yes. Decision: Motion carries with no abstentions. The 835 workgroup did not understand the basis for this DM. The protocol is to not list the code source in the semantic note, in addition the code source the semantic note pointed to did not meet the needs for all uses. Conference Calls Conference call schedule is as follows: 2 nd and 4 th Thursdays of the month 1-3 PM Eastern Current call info: phone: pass-code: In order to get notification of conference calls and cancellation, sign up for the list serve. Listserve signup instructions Go to: Access: Quick Links and select: Listserve Signup Fill in information and select listserve: X12N TG2 WG2 Healthcare Claims Project Proposals Project proposals have been drafted for moving forward with the versions of the guides. Even though the draft guides we will be working on will not be the 5050 versions, because we are not there yet, the registry has to show what we are aiming for and in order for the workgroup to include the necessary DMs this will be the Professional Project Proposal Set ID 837 Version/Release Owning Group TG2/WG2

15 Name Health Care Claim: Professional Replacement of 222 Project Delegate Project Alternative Doreen Espinoza John Bock Purpose/Scope The Health Care Claim: Professional Implementation Guide describes the use of the ANSI ASC X12 Health Care (837) transaction set to submit and transfer professional claims and encounters to primary, secondary, and subsequent payers. Trading Partners Health care providers, such as physicians, practitioners, and suppliers Health care and property/casualty (including workers compensation) payers Clearinghouses, repricers, VANS, etc. Exceptions None References ANSI ASC X12N 837 Health Care Claim: Professional Implementation Guide (005010X222) Coordination ANSI ASC X12N TG2/WG2 (Health Care Claims) developers for the dental, institutional, professional / workers compensation implementation guides. ANSI ASC X12N TG2/WG3 (Health Care Claim Payment) ANSI ASC X12N TG2/WG4 (Health Care Enrollments) ANSI ASC X12N TG2/WG5 (Health Care Claim Status) ANSI ASC X12N TG2/WG9 (Patient Information & Attachments) ANSI ASC X12N TG1/WG3 (Workers Compensation and Disability) Motion: To approve the professional project proposal. Discussion: Agreed to change the term tertiary to subsequent payers in the purpose/scope as there is the ability to go beyond 3. Decision: Motion carries with 2 abstentions. Institutional Project Proposal Set ID 837 Version/Release Owning Group TG2/WG2 Name Health Care Claim: Institutional Replacement of 223 Project Delegate Project Alternative Harvey Mintz Doug Renshaw

16 Purpose/Scope The Health Care Claim: Institutional Implementation Guide describes the use of the ANSI ASC X12 Health Care (837) transaction set to submit and transfer institutional claims and encounters to primary, secondary, and subsequent payers. Trading Partners Health care providers, such as physicians, hospitals, and suppliers Health care and property/casualty (including workers compensation) payers Clearinghouses, repricers, VANS, etc. Exceptions None References ANSI ASC X12N 837 Health Care Claim: Institutional Implementation Guide (005010X223) Coordination ANSI ASC X12N TG2/WG2 (Health Care Claims) developers for the dental, institutional, professional / workers compensation implementation guides. ANSI ASC X12N TG2/WG3 (Health Care Claim Payment) ANSI ASC X12N TG2/WG4 (Health Care Enrollments) ANSI ASC X12N TG2/WG5 (Health Care Claim Status) ANSI ASC X12N TG2/WG9 (Patient Information & Attachments) ANSI ASC X12N TG1/WG3 (Workers Compensation and Disability) Motion: To approve the institutional project proposal Discussion: None Decision: Motion carries with 1 abstention. Dental Project Proposal Set ID 837 Version/Release Owning Group TG2/WG2 Name Health Care Claim: Dental Replacement of 224 Project Delegate Project Alternative Ken Erdmann John Bock Purpose/Scope The Health Care Claim: Dental Implementation Guide describes the use of the ANSI ASC X12 Health Care (837) transaction set to submit and transfer dental claims and encounters to primary, secondary, and subsequent payers.

17 Trading Partners Health care providers, such as dentists and physicians Health care and property/casualty (including workers compensation) payers Clearinghouses, repricers, VANS, etc. Exceptions None References ANSI ASC X12N 837 Health Care Claim: Dental Implementation Guide (005010X224) Coordination ANSI ASC X12N TG2/WG2 (Health Care Claims) developers for the dental, institutional, professional / workers compensation implementation guides. ANSI ASC X12N TG2/WG3 (Health Care Claim Payment) ANSI ASC X12N TG2/WG4 (Health Care Enrollments) ANSI ASC X12N TG2/WG5 (Health Care Claim Status) ANSI ASC X12N TG2/WG9 (Patient Information & Attachments) ANSI ASC X12N TG1/WG3 (Workers Compensation and Disability) Motion: To approve dental project proposal. Discussion: None Decision: Motion carries with none opposed and no abstentions Reporting Project Proposal Set ID 837 Version/Release Owning Group TG2/WG2 Name Health Care Service: Data Reporting Replacement of 225 Project Delegate Project Alternate Bob Davis Wanda Govan-Jenkins Purpose/Scope The Health Care Service: Data Reporting Implementation Guide describes the use of the ANSI ASC X12 Health Care Claim (837) transaction set for the following business usages: Reporting health care service data for use in health data statistical analysis from provider data Reporting health care service data to satisfy governmental mandates necessary to regulate the health care industry Reporting health care service data to measure utilization rates. Trading Partners

18 Health care providers, such as, hospitals and physicians Health care payers, such as, insurance companies, HMO's, and PPO's Local, state, and federal governmental authorities or their reporting agents Trade organizations, such as, hospital associations Exceptions/Limitations Intended as a vehicle to report health care service data to authorized authorities or based on trading partner agreement. It is not intended to satisfy all health care reporting needs. References ANSI ASC X12N Health Care Service Data Reporting (004050X225) Coordination ANSI ASC X12N TG2/WG2 (Health Care Claims) ANSI ASC X12N TG2/WG9 (Patient Information & Attachments) Motion: To approve the reporting project proposal Discussion: Should we indicate this is not intended to be used to request payment? If it is added, it was suggested to not add to the limitations but rather to the use. A poll indicates nobody has concerns about this due to the name of the guide itself. Is the note regarding authorized authorities too limiting? Perhaps, and language adjusted. Decision: Motion carries with 1 abstention. Real-Time Adjudication Dan Kazzaz, X12 Chair has been trying to figure out ways for increasing industry involvement in X12. Some of his thoughts regarding this included standards harmonization, but he felt this was already being done, another was real time adjudication. There are lots of pilots happening for real time adjudication, some of which are HIPAA compliant and others that are not. Dan is planning to set up joint conference to discuss this further and get the dialogue started. There is a small group who is working in conjunction with WEDI which designed a survey to evaluate the market response. Brief overview of survey results: There were about 200 responses. 4 to 1 ratio of respondents indicating interest in real time adjudication 50% indicated they would participate 40% indicated they might participate 10% indicated no, they would not participate The survey itself really didn t get out to the market as a whole since most respondents were already members of WEDI and/or X12. Ultimately, there needs to be additional members of the industry present in order to better drive where things go. What we do know, is that the NCPDP transactions work better and we have that data model.

19 Dan hopes to have a conference the early part of next year, hoping for January, but this might not be logistically feasible. Questions: Is this being done elsewhere such as Europe? Dan did not believe so and in his opinion he felt they weren t anywhere near where the US is today. Is there an agenda ready and will it be shared? The agenda is not ready, but yes it will be shared. Note: There are many pockets of success stories, such as the interactive claim that allows for allows communication of a claim to be done in seconds. There is some work that has already been completed, but need to move further. What are pharmacies doing as they get further into professional type items? Not sure, but likely using clearinghouses. This will be a big paradigm shift for the industry. DM from the 835 The 835 workgroup presented a DM which would allow for a one-to-one relationship between a given Claim Adjustment Reason Code (CARC) and Claim Payment Remark Codes or NCPDP Reject/Payment Codes (Remark Codes). In order to accomplish this, a new segment is being requested, Reason Adjustment Segment (RAS) as detailed below. Reason Adjustment Segment To supply CARCs and amounts as needed for an entire claim or for a particular service within the claim being paid. Total number of repeats for this segment is 99. REF ELE ID NAME RPT ATTRIBUTES Monetary Amount M R 1/ Claim Adjustment Group Code M ID 1/2 03 CXXX Composite Adjustment Reason 15 M Quantity O R 1/15 Semantic Notes 01 XXX01 is the amount of adjustment. 04 XXX04 is the units of service being adjusted Comments 00 Adjustment information is intended to help the provider balance the remittance information. Adjustment amounts must fully explain the difference between submitted charges and the amount paid. CXXX Adjustment Reason Composite To provider a reason and related explanation for a Health Care Claim or Service change in payment versus the original submitted charges.

20 REF ELE ID NAME ATTRIBUTES Claim Adjustment Reason Code M ID 1/ Code List Qualifier X/Z ID 1/ Industry Code X AN 1/ Industry Code X AN 1/ Industry Code X AN 1/ Industry Code X AN 1/ Industry Code X AN 1/30 Syntax Notes 02 P0203- If either CXXX02 or CXXX03 is present then the other must be present 04 C0403- If CXXX04 is present then CXXX03 must be present. 05 C0504- If CXXX05 is present then CXXX04 must be present. 06 C0605- If CXXX06 is present then CXXX05 must be present. 07 C0706- If CXXX07 is present then CXXX06 must be present. Semantic Notes 01 CXXX02 Qualifies CXXX03, CXXX04, CXXX05, CXXX06, and CXXX07. The number of repeats within the adjustment reason composite is based upon outreach to the industry, which found that the most common maximum number of adjustments is three. Further outreach determined that the maximum number of adjustments that could be returned based upon Texas state regulation is 11. Fifteen repeats exceeds industry usage and state mandate. The maximum number of Remark codes is based upon usage within the industry that found that five was the maximum number that could be returned. Examples: RAS*25*CO*50:HE:N175*2~ RAS*30*CO*57:HE:M103:M10*3~ RAS*5000*CO*16:HE:M77:M78>11:HE:MA126~ Motion: To approve this with the understanding that TG8 may modify wording slightly Discussion: Is the intent of this new information to assist in balancing? The intent is that all the reasons for an adjustment can be reported. Isn t the intent that this must fully explain rather than should, yes this was changed in the language. Are these amounts the same amts currently reported in CAS? Yes, it will replace the CAS and the RAS will be the only segment for reporting this. Does this require a remark code with a reason code? No, only for those where the reason code mandates a remark code. Unsure of the delimiters in the examples: the greater than sign is the repeating data element delimiter in this case. What happens with the MIA, the MOA, LQ segments? They will still have remarks codes. This is a DM for adding a new segment to the standard, all the information surrounding its use will be defined in TR3s. In the business case there was mentioning of the current structure with the MIA, MOA, LQ segments, some felt this was confusing. What version will this be in? Likely this will be in the Decision: Motion carries with no abstentions. Action Items (when applicable) Action Item Responsible Party(ies) Due Date (when applicable) Completed Date Communicate to workgroup how to access TG4 workbook. When this is made Co-Chairs None Identified Open

21 available will also establish a review timeline.