1 / 75

the old, the new and the … do over

the old, the new and the … do over. RMBAA Birmingham, Alabama Wednesday, February 20, 2013. Disclosure .

tayten
Download Presentation

the old, the new and the … do over

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. the old, the new and the … do over RMBAA Birmingham, Alabama Wednesday, February 20, 2013

  2. Disclosure Claudia Murray is a principal and CEO of CMC Consulting, LLC, a firm that specializes in regulatory compliance, Medicare billing rules and coding audits. Neither Claudia Murray nor her immediate family members have a financial relationship with a commercial organization that may have a direct or indirect interest in the content of this presentation. NO COMMERCIAL INTEREST TO DISCLOSE

  3. Agenda • 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • PCI DSS Compliance • ICD-9 Coding for Original, Resubmitted and Appealed Claims • Place of Service • Site of Service

  4. Privacy, Security, Breach Notification and Enforcement Rules HIPAA in 2013

  5. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • On January 17, 2013, the Department of Health and Human Services issued the long-awaited revisions to the HIPAA rules • The rules made a number of changes to the current HIPAA privacy, security, breach notification and enforcement requirements • The new rules modify the patient authorization and other requirements related to use and disclosure of PHI for research

  6. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • Consistent with the provisions of the HITECH Act, the new rules expand patients’ rights to receive electronic copies of their PHI and restrict disclosures of PHI to health plans concerning treatment for which the patient paid out of pocket in full • The new rules provide more flexibility with respect to allowing access to decedent PHI to family members and others

  7. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • Consistent with the Genetic Information Nondiscrimination Act, the new rules prohibit most health plans from using or disclosing genetic information for underwriting purposes • The new rules impose additional restrictions on the use and disclosure of PHI for marketing by requiring written patient authorization for all communications where the CE receives remuneration for communicating with a company whose product or service is being marketed

  8. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • The definition of the term “business associate” has been expanded in the new rules to include vendors who maintain PHI, even if they do not view the PHI, and subcontractors of business associates • This change to the rules will likely result in many new vendors being considered business associates

  9. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • The new rules detail that business associates, as well as their subcontractors, are directly liable for compliance with the HIPAA security rules and certain requirements of the HIPAA privacy rules • Business Associate Agreements that were already revised for compliance with the HITECH Act may require amendment but not a significant overhaul

  10. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • The new rules change the notification requirements for breaches of unsecured protected health information (“PHI”) • It replaces the current “risk of harm to the affected patients” standard with a more objective standard to be used in determining whether a breach has occurred and whether notice of the breach must be provided to patients, the government and the media

  11. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • Under the new rules, every improper use or disclosure of PHI is presumed to be a breach unless it is demonstrated that there is low probability that the PHI was compromised as a result of the incident • This change is significant and could result in an increase in the number of breaches requiring notice

  12. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • The new rules adopt an increased, tiered civil money penalty structure for HIPAA violations provided by the HITECH Act • They also give the Office of Civil Rights discretion to impose penalties on covered entities and business associates in cases of violations due to willful neglect withoutfirst attempting to resolve the matter through informal means

  13. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • Penalties for HIPAA violations are significant • Specifically, penalties for violations caused by willful neglect, which are corrected, range from $10,000 to $50,000 per violation • The minimum penalty for an uncorrected HIPAA violation caused by willful neglect is $50,000 per violation • The penalties are capped at $1.5 million for all violations of an identical requirement in a calendar year

  14. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules

  15. 2013 HIPAA Privacy, Security, Breach Notification and Enforcement Rules • The new rules provide that each covered entity must revise its notice of privacy practices to address the new HIPAA requirements • Covered entities and business associates generally must comply with the new HIPAA requirements by September 23, 2013 • Compliance with the new requirements will also require changes to HIPAA policies and procedures

  16. Does this apply to you? Pcidss Compliance

  17. Pci data security standards • The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that ALL companies that process, store or transmit credit card information maintain a secure environment. Essentially any merchant that has a Merchant ID (MID) • The Payment Card Industry Security Standards Council (PCI SSC) was launched on September 7, 2006 to manage the ongoing evolution of the Payment Card Industry (PCI) security standards with focus on improving payment account security throughout the transaction process

  18. Pci data security standards • The PCI DSS is administered and managed by the PCI SSC (www.pcisecuritystandards.org) , an independent body that was created by the major payment card brands (Visa, MasterCard, American Express, Discover and JCB.) • It is important to note, the payment brands and acquirers are responsible for enforcing compliance, not the PCI council

  19. Who must comply with pci? • PCI applies to ALL organizations or merchants, regardless of size or number of transactions, that accept, transmit or store any cardholder data • Said another way, if any customer of that organization ever pays the merchant directly using a credit card or debit card, then the PCI DSS requirements apply • The Standard can be found on the PCI SSC's Website: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

  20. definitions • Cardholder data is any personally identifiable data associated with a cardholder • This could be an account number, expiration date, name, address, social security number, etc. • All personally identifiable information associated with the cardholder that is stored, processed, or transmitted is also considered cardholder data

  21. definitions • For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services • Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers • For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers

  22. Compliance Date • All merchants that store, process or transmit cardholder data must be compliant now • However, if you are a Level 4 merchant, you will have to refer to your merchant bank for their specific validation requirements and deadlines • All deadline enforcement will come from your merchant bank • You may also find more information on Visa’s Website: http://usa.visa.com/download/merchants/payment_application_security_mandates.pdf

  23. Pci compliance levels • All merchants will fall into one of the four merchant levels based on Visa transaction volume over a 12-month period • Transaction volume is based on the aggregate number of Visa transactions (inclusive of credit, debit and prepaid) from a merchant Doing Business As (‘DBA’)

  24. Pci compliance levels • In cases where a merchant corporation has more than one DBA, Visa acquirers must consider the aggregate volume of transactions stored, processed or transmitted by the corporate entity to determine the validation level • If data is not aggregated, such that the corporate entity does not store, process or transmit cardholder data on behalf of multiple DBAs, acquirers will continue to consider the DBA’s individual transaction volume to determine the validation level

  25. Merchant level description

  26. Meeting the requirements • To satisfy the requirements of PCI, a merchant must complete the following steps: • Identify your Validation Type as defined by PCI DSS – this is used to determine which Self Assessment Questionnaire is appropriate for your business • Complete the Self-Assessment Questionnaire according to the instructions in the Self- Assessment Questionnaire Instructions and Guidelines

  27. Meeting the requirements • Complete and obtain evidence of a passing vulnerability scan with a PCI SSC Approved Scanning Vendor (ASV) • Notescanning does not apply to all merchants • It is required for Validation Type 4 and 5 – those merchants with external facing IP addresses • Basically if you electronically store cardholder information or if your processing systems have any internet connectivity, a quarterly scan by an approved scanning vendor is required • Complete the relevant Attestation of Compliance in its entirety • Submit the SAQ, evidence of a passing scan (if applicable), and the Attestation of Compliance, along with any other requested documentation, to your acquirer

  28. You might ask… Q: I’m a small merchant with very few card transactions; do I need to be compliant with PCI DSS? A: All merchants, small or large, need to be PCI compliant. The payment brands have collectively adopted PCI DSS as the requirement for organizations that process, store or transmit payment cardholder data. Q: If I only accept credit cards over the phone, does PCI still apply to me? A: Yes. All business that store, process or transmit payment cardholder data must be PCI Compliant.

  29. You might ask… Q: Do organizations using third-party processors have to be PCI compliant? A: Yes. Merely using a third-party company does not exclude a company from PCI compliance. It may cut down on their risk exposure and consequently reduce the effort to validate compliance. However, it does not mean they can ignore PCI.

  30. You might ask… Q: My business has multiple locations, is each location required to validate PCI Compliance? A: If your business locations process under the same Tax ID, then typically you are only required to validate once annually for all locations. And, submit quarterly passing network scans by an PCI SSC Approved Scanning Vendor (ASV), if applicable. Q: Are debit card transactions in scope for PCI? A: In-scope cards include any debit, credit, and pre-paid cards branded with one of the five card association/brand logos that participate in the PCI SSC - American Express, Discover, JCB, MasterCard, and Visa International.

  31. SSL CERTIFICATION • SSL certificates do not secure a Web server from malicious attacks or intrusions • High assurance SSL certificates provide the first tier of customer security and reassurance but there are other steps to achieve PCI Compliance • A secure connection between the customer's browser and the web server • Validation that the Website operators are a legitimate, legally accountable organization

  32. Penalties • The payment brands may, at their discretion, fine an acquiring bank $5,000 to $100,000 per month for PCI compliance violations • The banks will most likely pass this fine on downstream till it eventually hits the merchant • Furthermore, the bank will also most likely either terminate your relationship or increase transaction fees • Penalties are not openly discussed nor widely publicized, but they can catastrophic to a small business • It is important to be familiar with your merchant account agreement, which should outline your exposure

  33. Breach notification • See the procedures outlined in Visa’s “What to Do If Compromised Visa Fraud Control and Investigations Procedures” document • http://usa.visa.com/download/merchants/cisp_what_to_do_if_compromised.pdf • There are at least 39 states that have breach notification laws in place • See www.privacyrights.org for more detail on state laws

  34. Revisiting an old rule ICD-9 diagnostic coding guidelines

  35. ICD-9, not ICD-10??? We’re going to discuss: • Coding from the report • Is there a difference between specificity and certainty? • Assigning a diagnosis code based on the other information, documentation or medical records • Late entries and amendments • Resubmissions and appeals

  36. 10.1 - ICD-9-CM Coding for Diagnostic Tests • The CMS instruct physicians to report diagnoses based on test results, if available • Contractors, physicians, hospitals, and other health care providers must comply with the following instructions in determining the appropriate ICD-9-CM diagnoses code for diagnostic test results

  37. 10.1.1 - Determining the Appropriate Primary ICD-9-CM Diagnosis Code for Diagnostic Tests Ordered Due to Signs and/or Symptoms • For patients receiving diagnostic services code the condition(s), symptom(s), and diagnosis to the highest degree of certainty for that visit, such as describing symptoms, signs, abnormal test results, or other reasons for the visit • Report additional codes that describe any current coexisting conditions • Do not code diagnoses documented as probable, suspected, questionable or rule out

  38. A. Confirmed Diagnosis Based on Results of Test • If the physician has confirmed a diagnosis based on the results of the diagnostic test, the physician interpreting the test should code that diagnosis • The signs and/or symptoms that prompted ordering the test may be reported as additional diagnoses if they are not fully explained or related to the confirmed diagnosis

  39. B. Signs or Symptoms • If the diagnostic test did not provide a diagnosis or was normal, the interpreting physician should code the sign(s) or symptom(s) that prompted the treating physician to order the study

  40. C. Diagnosis Preceded by Words that Indicate Uncertainty • If the results of the diagnostic test are normal or nondiagnostic and the referring physician records a diagnosis preceded by words that indicate uncertainty (e.g., probably, suspected, questionable, rule out, or working), then the interpreting physician should not code the referring diagnosis • Rather the interpreting physician should report the sign(s) or symptom(s) that prompted the study

  41. C. Diagnosis Preceded by Words that Indicate Uncertainty • Diagnoses labeled as uncertain are considered by the ICD-9-CM Coding Guidelines as unconfirmed and should not be reported • This is consistent with the requirement to code the diagnosis to the highest degree of certainty

  42. 10.1.2 - Instructions to Determine the Reason for the Test • The Balanced Budget Act (BBA) §4317(b) requires referring physicians to provide diagnostic information to the testing entity at the time the test is ordered • As further indicated in 42 CFR 410.32 all diagnostic tests “must be ordered by the physician who is treating the beneficiary • An “order” is a communication from the treating physician/practitioner requesting that a diagnostic test be performed for a beneficiary

  43. 10.1.3 - Incidental Findings • Incidental findings should never be listed as primary diagnoses • If reported, incidental findings may be reported as secondary diagnoses by the physician interpreting the diagnostic test

  44. 10.1.4 - Unrelated Coexisting Conditions/Diagnoses • Unrelated and coexisting conditions/diagnoses may be reported as additional diagnoses by the physician interpreting the diagnostic test

  45. 10.1.5 - Diagnostic Tests Ordered in the Absence of Signs and/or Symptoms • When a diagnostic test is ordered in the absence of signs/symptoms or other evidence of illness or injury, the testing facility or the physician interpreting the diagnostic test should report the screening code as the primary diagnosis code • Any condition discovered during the screening should be reported as a secondary diagnoses

  46. 10.1.6 - Use of ICD-9-CM to the Greatest Degree of Accuracy and Completeness • The following longstanding coding guidelines are part of Official ICD-9-CM Guidelines for Coding and Reporting • The testing facility or the interpreting physician should code the ICD-9-CM code that provides the highest degree of accuracy and completeness (certainty) for the diagnosis resulting from test, or for the sign(s)/ symptom(s) that prompted the ordering of the test • The “highest degree of specificity” means assigning the most precise ICD-9-CM code that most fully explains the narrative description in the medical chart of the symptom or diagnosis

  47. Why am I telling you this? • RAC auditors have been taking a harder stance on accepting diagnosis information from sources other than the radiology report • MAC denials for medical necessity often lead to resubmissions or appeals with additional diagnosis information • Recent publications detail Medicare’s viewpoint on ancillary documentation, late medical record entries and amendments

  48. Medicare has stated… • Every note stands alone, i.e., the performed services and necessary signatures must be documented at the outset • Delayed written explanations will be considered for purposes of clarification only • They cannot be used to add and authenticate services billed and not documented at the time of service or to retrospectively substantiate medical necessity • For that, the medical record must stand on its own with the original entry corroborating that the service was rendered and was medically necessary Published by CGS, a multi-state MAC

  49. Amended Medical Records • Late entries, addendums, or corrections to a medical record are legitimate occurrences in documentation of clinical services • A late entry, an addendum, or a correction to the medical record, bears the current date of that entry and is signed by the person making the addition or change Published by Noridian Administrative Services, a multi-state MAC

More Related