Common use of Record Layout and File Submissions Clause in Contracts

Record Layout and File Submissions. ‌ Q1: Why does CMS insist we fill the “DCN” field on Input Files? A1: The “Document Control Number” (DCN) is an ID number assigned by the VDSA partner, for its own use as a tracking code. While other information in an input record may have changed in the response record, the DCN will not. Consequently, using the DCN will always allow a VDSA partner to match and link an input record with its corresponding response record. Supplying a DCN on an input record is mandatory. On the Non-MSP Input File record layout the DCN field is Number 19. Q2: Throughout the record layouts there is a field for Medicare ID (HICN or MBI). Some of the data field descriptions state that the Medicare ID is not required if the SSN is provided. This is not explicitly stated in others. Please confirm that an SSN is an acceptable substitute for the Medicare ID in all the layouts. A2: For VDSA reporting the Medicare ID is the “gold standard.” A correct Medicare ID will always identify a Medicare beneficiary. More generally, to confirm a beneficiary data match we always need either the Medicare ID or the SSN. Having one of these numbers is necessary to determine if a Covered Individual you submit is also entitled to Medicare. We encourage you to send us both numbers in case one or the other contains an error. Note: If you provide a Medicare ID (HICN or MBI), or an SSN, on either Medicare Secondary Payer (MSP) or non- MSP input files, we will return the most current Medicare ID in the response files. Q3: We don't have all of the SSNs for all of our covered individuals. Should we include a record with no SSN or Medicare ID (HICN or MBI) on the file anyway? A3: No. Without either the Medicare ID or SSN, do not submit a record for that individual. The Medicare ID or SSN are the primary identifiers we use to confirm Medicare entitlement. Without one or both of those numbers, a record will not process. Q4: What should we do for records that do not have the SSN? A4: See if you have a Medicare ID (HICN or MBI) for that individual. If you do not, don’t send the record. Q5: Is just the SSN enough to make a match in your database? A5: Almost. Using an SSN to confirm that the individual on a submitted record is a Medicare beneficiary requires the SSN, the first 6 characters of the person's surname, first name initial, date of birth, and gender. Q6: What if we have the SSN but not all of the personal identifying information (first 6 characters of the person's surname, first name initial, date of birth, and sex code) that you need to confirm Medicare entitlement? A6: You should include as much of the personal identifying information as possible. It is often possible to find Medicare entitlement even if not all of the personal identifying information exists or is correct on the record you submit. We use a matching algorithm that accepts a match when at least 3 of the 4 personal identifying pieces of information for the submitted SSN or Medicare ID (HICN or MBI) are correct. Q7: Many of our enrollees are concerned about identity theft and are wary about giving us their Social Security Numbers (SSNs). How can we assure them that an individual’s SSN will be protected and used appropriately? A7: The collection and use of individual SSNs is now limited by an evolving body of federal and state law and regulation. When an SSN is to be used as personal health information, management of the SSN (who can collect it; for what reason; with what other entity or person can it be shared) is directed by regulations required by the Federal Health Insurance Portability and Accountability Act (HIPAA). These are called the HIPAA privacy rules. They are quite strict, and after they were fully implemented in 2004, measures to protect personal health information have become stronger. Collection of SSNs for purposes of coordinating benefits with Medicare is a legitimate use of the SSN under Federal law.

Appears in 6 contracts

Samples: Sharing Agreement, Sharing Agreement, Sharing Agreement

AutoNDA by SimpleDocs

Record Layout and File Submissions. Q1: Why does CMS insist we fill the “DCN” field on Input Files? A1: The “Document Control Number” (DCN) is an ID number assigned by the VDSA partner, for its own use as a tracking code. While other information in an input record may have changed in the response record, the DCN will not. Consequently, using the DCN will always allow a VDSA partner to match and link an input record with its corresponding response record. Supplying a DCN on an input record is mandatory. On the Non-MSP Input File record layout the DCN field is Number 19. Q2: Throughout the record layouts there is a field for Medicare ID HIC Number (HICN or MBIHICN). Some of the data field descriptions state that the Medicare ID HICN is not required if the SSN is provided. This is not explicitly stated in others. Please confirm that an SSN is an acceptable substitute for the Medicare ID HICN in all the layouts. A2: For VDSA reporting the Medicare ID HIC Number (HICN) is the “gold standard.” ”. A correct Medicare ID HICN will always identify a Medicare beneficiary. More generally, to confirm a beneficiary data match we always need either the Medicare ID HICN or the SSN. Having one of these numbers is necessary to determine if a Covered Individual you submit is also entitled to Medicare. We encourage you to send us both numbers in case one or the other contains an error. Note: If you provide a Medicare ID (HICN or MBI), or an SSN, on either Medicare Secondary Payer (MSP) or non- MSP input files, we will return the most current Medicare ID in the response files. Q3: We don't have all of the SSNs for all of our covered individuals. Should we include a record with no SSN or Medicare ID (HICN or MBI) on the file anyway? A3: No. Without either the Medicare ID HICN or SSN, do not submit a record for that individual. The Medicare ID HICN or SSN are the primary identifiers we use to confirm Medicare entitlement. Without one or both of those numbers, a record will not process. Q4: What should we do for records that do not have the SSN? A4: See if you have a Medicare ID (HICN or MBI) for that individual. If you do not, don’t don‟t send the record. Q5: Is just the SSN enough to make a match in your database? A5: Almost. Using an SSN to confirm that the individual on a submitted record is a Medicare beneficiary requires the SSN, the first 6 characters of the person's surname, first name initial, date of birth, and gender. Q6: What if we have the SSN but not all of the personal identifying information (first 6 characters of the person's surname, first name initial, date of birth, and sex code) that you need to confirm Medicare entitlement? A6: You should include as much of the personal identifying information as possible. It is often possible to find Medicare entitlement even if not all of the personal identifying information exists or is correct on the record you submit. We use a matching algorithm that accepts a match when at least 3 of the 4 personal identifying pieces of information for the submitted SSN or Medicare ID (HICN or MBI) are correct. Q7: Many of our enrollees are concerned about identity theft and are wary about giving us their Social Security Numbers (SSNs). How can we assure them that an individual’s individual‟s SSN will be protected and used appropriately? A7: The collection and use of individual SSNs is now limited by an evolving body of federal and state law and regulation. When an SSN is to be used as personal health information, management of the SSN (who can collect it; for what reason; with what other entity or person can it be shared) is directed by regulations required by the Federal federal Health Insurance Portability and Accountability Act (HIPAA). These are called the HIPAA privacy rules. They are quite strict, and after they were fully implemented in 2004, measures to protect personal health information have become stronger. Collection of SSNs for purposes of coordinating benefits with Medicare is a legitimate use of the SSN under Federal law. Q8: Don‟t state laws prohibit the use and collection of SSNs? A8: There are state laws that restrict when SSNs can be collected and how they can be used. But these state initiatives do not preempt the provisions of the Medicare Secondary Payer (MSP) or Medicare Modernization Act (MMA) regulations or the “permitted use” provisions of the HIPAA privacy rules. These federal laws allow the collection and use of SSNs to help providers and insurers manage their operations. However, state laws frequently augment the federal regulations. Some states now restrict how SSNs may be displayed, prohibiting a health plan from including an SSN on an individual‟s plan ID card for example. These state initiatives are not affected by the federal rules.

Appears in 1 contract

Samples: Sharing Agreement

Record Layout and File Submissions. Q1: Why does CMS insist we fill the “DCN” field on Input Files? A1: The “Document Control Number” (DCN) is an ID number assigned by the VDSA partner, for its own use as a tracking code. While other information in an input record may have changed in the response record, the DCN will not. Consequently, using the DCN will always allow a VDSA partner to match and link an input record with its corresponding response record. Supplying a DCN on an input record is mandatory. On the Non-MSP Input File record layout the DCN field is Number 19. Q2: Throughout the record layouts there is a field for Medicare ID (HICN or MBI). Some of the data field descriptions state that the Medicare ID is not required if the SSN is provided. This is not explicitly stated in others. Please confirm that an SSN is an acceptable substitute for the Medicare ID in all the layouts. A2: For VDSA reporting the Medicare ID is the “gold standard.” ”. A correct Medicare ID will always identify a Medicare beneficiary. More generally, to confirm a beneficiary data match we always need either the Medicare ID or the SSN. Having one of these numbers is necessary to determine if a Covered Individual you submit is also entitled to Medicare. We encourage you to send us both numbers in case one or the other contains an error. .Note: If you provide a Medicare ID (HICN or MBI), or an SSN, on either Medicare Secondary Payer (MSP) or non- MSP input files, we will return the most current Medicare ID in the response files. Q3: We don't have all of the SSNs for all of our covered individuals. Should we include a record with no SSN or Medicare ID (HICN or MBI) on the file anyway? A3: No. Without either the Medicare ID or SSN, do not submit a record for that individual. The Medicare ID or SSN are the primary identifiers we use to confirm Medicare entitlement. Without one or both of those numbers, a record will not process. Q4: What should we do for records that do not have the SSN? A4: See if you have a Medicare ID (HICN or MBI) for that individual. If you do not, don’t send the record. Q5: Is just the SSN enough to make a match in your database? A5: Almost. Using an SSN to confirm that the individual on a submitted record is a Medicare beneficiary requires the SSN, the first 6 characters of the person's surname, first name initial, date of birth, and gender. Q6: What if we have the SSN but not all of the personal identifying information (first 6 characters of the person's surname, first name initial, date of birth, and sex code) that you need to confirm Medicare entitlement? A6: You should include as much of the personal identifying information as possible. It is often possible to find Medicare entitlement even if not all of the personal identifying information exists or is correct on the record you submit. We use a matching algorithm that accepts a match when at least 3 of the 4 personal identifying pieces of information for the submitted SSN or Medicare ID (HICN or MBI) are correct. Q7: Many of our enrollees are concerned about identity theft and are wary about giving us their Social Security Numbers (SSNs). How can we assure them that an individual’s SSN will be protected and used appropriately? A7: The collection and use of individual SSNs is now limited by an evolving body of federal and state law and regulation. When an SSN is to be used as personal health information, management of the SSN (who can collect it; for what reason; with what other entity or person can it be shared) is directed by regulations required by the Federal Health Insurance Portability and Accountability Act (HIPAA). These are called the HIPAA privacy rules. They are quite strict, and after they were fully implemented in 2004, measures to protect personal health information have become stronger. Collection of SSNs for purposes of coordinating benefits with Medicare is a legitimate use of the SSN under Federal law.

Appears in 1 contract

Samples: Sharing Agreement

AutoNDA by SimpleDocs

Record Layout and File Submissions. Q1: Why does CMS insist we fill the “DCN” field on Input Files? A1: The “Document Control Number” (DCN) is an ID number assigned by the VDSA partner, for its own use as a tracking code. While other information in an input record may have changed in the response record, the DCN will not. Consequently, using the DCN will always allow a VDSA partner to match and link an input record with its corresponding response record. Supplying a DCN on an input record is mandatory. On the Non-MSP Input File record layout the DCN field is Number 19. Q2: Throughout the record layouts there is a field for Medicare ID HIC Number (HICN or MBIHICN). Some of the data field descriptions state that the Medicare ID HICN is not required if the SSN is provided. This is not explicitly stated in others. Please confirm that an SSN is an acceptable substitute for the Medicare ID HICN in all the layouts. A2: For VDSA reporting the Medicare ID HIC Number (HICN) is the “gold standard.” ”. A correct Medicare ID HICN will always identify a Medicare beneficiary. More generally, to confirm a beneficiary data match we always need either the Medicare ID HICN or the SSN. Having one of these numbers is necessary to determine if a Covered Individual you submit is also entitled to Medicare. We encourage you to send us both numbers in case one or the other contains an error. Note: If you provide a Medicare ID (HICN or MBI), or an SSN, on either Medicare Secondary Payer (MSP) or non- MSP input files, we will return the most current Medicare ID in the response files. Q3: We don't have all of the SSNs for all of our covered individuals. Should we include a record with no SSN or Medicare ID (HICN or MBI) on the file anyway? A3: No. Without either the Medicare ID HICN or SSN, do not submit a record for that individual. The Medicare ID HICN or SSN are the primary identifiers we use to confirm Medicare entitlement. Without one or both of those numbers, a record will not process. Q4: What should we do for records that do not have the SSN? A4: See if you have a Medicare ID (HICN or MBI) for that individual. If you do not, don’t send the record. Q5: Is just the SSN enough to make a match in your database? A5: Almost. Using an SSN to confirm that the individual on a submitted record is a Medicare beneficiary requires the SSN, the first 6 characters of the person's surname, first name initial, date of birth, and gender. Q6: What if we have the SSN but not all of the personal identifying information (first 6 characters of the person's surname, first name initial, date of birth, and sex code) that you need to confirm Medicare entitlement? A6: You should include as much of the personal identifying information as possible. It is often possible to find Medicare entitlement even if not all of the personal identifying information exists or is correct on the record you submit. We use a matching algorithm that accepts a match when at least 3 of the 4 personal identifying pieces of information for the submitted SSN or Medicare ID (HICN or MBI) are correct. Q7: Many of our enrollees are concerned about identity theft and are wary about giving us their Social Security Numbers (SSNs). How can we assure them that an individual’s SSN will be protected and used appropriately? A7: The collection and use of individual SSNs is now limited by an evolving body of federal and state law and regulation. When an SSN is to be used as personal health information, management of the SSN (who can collect it; for what reason; with what other entity or person can it be shared) is directed by regulations required by the Federal federal Health Insurance Portability and Accountability Act (HIPAA). These are called the HIPAA privacy rules. They are quite strict, and after they were fully implemented in 2004, measures to protect personal health information have become stronger. Collection of SSNs for purposes of coordinating benefits with Medicare is a legitimate use of the SSN under Federal law. Q8: Don’t state laws prohibit the use and collection of SSNs? A8: There are state laws that restrict when SSNs can be collected and how they can be used. But these state initiatives do not preempt the provisions of the Medicare Secondary Payer (MSP) or Medicare Modernization Act (MMA) regulations or the “permitted use” provisions of the HIPAA privacy rules. These federal laws allow the collection and use of SSNs to help providers and insurers manage their operations. However, state laws frequently augment the federal regulations. Some states now restrict how SSNs may be displayed, prohibiting a health plan from including an SSN on an individual’s plan ID card for example. These state initiatives are not affected by the federal rules. Q9: The Non-MSP Input File has an “Action Type” code field (Field 20) with values of ‛D’ for Drug Reporting Record, ‛S’ for Subsidy Reporting Record, and ‛N’ for Non-Reporting Record. Please clarify when a partner would submit an ‘N’ (non-reporting) record. A9: The ‘N’ record is a query record where you are merely asking for Medicare entitlement information. We do not store the information you submit on an ‘N’ record, which is why we call it a non-reporting record. Q10: Can we submit ‛N’ records for our retirees or other “Non-MSP” covered individuals? A10: Yes. You can submit ‛N’ records about any of your Covered Individuals. Because data submitted on ‛N’ records is not used or stored by CMS, when necessary you must still submit information about your Covered Individuals on either the MSP Input File or as a ‛D’ record on the Non-MSP Input File.

Appears in 1 contract

Samples: Sharing Agreement

Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!