Your SlideShare is downloading. ×
Stark Exceptions 20080325
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Stark Exceptions 20080325

1,657
views

Published on

Covers the basics of the "Stark II Exceptions" that allow hospitals to provide electronic medical record systems for community physicians

Covers the basics of the "Stark II Exceptions" that allow hospitals to provide electronic medical record systems for community physicians

Published in: Health & Medicine, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,657
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Stark II: New Exceptions and Safe Harbors for EHR sharing and e-prescribing Andy Spooner, MD Chief Medical Information Officer March 2008
  • 2. Federal Antikickback (“Stark II”) Law
    • Prohibits a physician from making referrals for designated health services to an entity with which the physician has a financial relationship, unless an exception applies.
  • 3. H.R. 4157
    • July, 2006: House of Representatives passed the Better Health Information System Act
      • Includes a provision calling for legislative relief from federal anti-kickback and Stark physician-self referral laws for hospitals to assist physician office practices with investment in health IT.
      • Effective October 10, 2006
  • 4. Exception for EHR Arrangements
    • Software and training services must be necessary and used to create, maintain, transmit or receive electronic health records;
    • The software is interoperable at the time it is provided to the physician (communicate and exchange data accurately with different systems)
    • Items and services are provided to a physician by a hospital that furnishes designated health care services;
  • 5. Exception for EHR Arrangements
    • The donor does not take any action to limit or restrict the use of the system;
    • The physician pays at least 15% of the donor’s cost for the items and services (no financing allowed);
    • The physician/practice does not make the receipt of the service a condition of doing business with the donor;
    • Eligibility and/or the amount of the items or services is not determined by volume/value of referrals.
  • 6. Exception for EHR Arrangements
    • The arrangement is in writing
    • The donor does not have actual knowledge of the fact that the physician possesses or has obtained items or services equivalent to those provided by the donor.
    • Items/services can be used for any patient without regard to payer status, etc.
    • Items and services do not include staffing of physician offices and are not used to conduct personal business, unrelated to medical practice.
  • 7. Exception for EHR Arrangements
    • The EHR software contains prescribing capability that meets the standards under Medicare Part D;
    • The arrangement does not violate the anti-kickback statute or any Federal or State law or regulation governing billing or claims submission; and
    • The transfer of items occurs on or before 12/31/2013.
  • 8. Hospital Considerations
    • Are the HHS and IRS rules clear enough?
    • How will current physician EMR owners respond to a subsidy to competing practices?
    • What product should we offer?
    • What’s the support model?
    • Are we prepared for a long-term commitment?
    • How do we deal with the desire to customize? The expenses of customization?
    • Can we issue a voucher instead?
    • What counts as “interoperable”?
  • 9. Interoperability Defined
    • At the time of the donation, software is able to
      • communicate and exchange data accurately, effectively, securely, and consistently with different
        • information technology systems
        • software applications, and networks
        • settings
      • exchange data such that the clinical or operational purpose and meaning of the data are preserved and unaltered
  • 10. IRS Guidelines - May, 2007
    • No threat to hospitals’ tax exempt status
    • Items and services must be available to all hospital staff at the same level of subsidy unless the level of subsidy varies based on criteria related to meeting the healthcare needs of the community
    • Both parties must comply with HHS regulations and allow the hospital “to access all of the electronic medical records created by a physician using the health IT items and services subsidized by the hospital.”
  • 11. Community Physician Considerations
    • How does it connect to other systems? The hospital system? What alternatives to data access exist?
    • Cost: Minimum of 15% plus hardware.
    • How customizable is the product?
    • Is support included? Extra? How?
    • Subsidies help, but not if we are not ready for the change.
    • In selecting EMR subsidies offered by hospitals, does the physician have to be a member of the hospital’s medical staff? Depending on this answer, which hospital-offered product is the best?
    • Language in IRS memorandum appears to allow hospitals unlimited access to records of patients with no relationship with the hospital.
    • Does the donated EMR result in taxable income to the physician?
  • 12. Product Selection
    • Products hospitals use are not necessarily what a small practice should use
    • If the hospital and the practice use the same product, should it be the same system ?
    • CCHIT certification (not a problem)
    • Medicare-compliant eRx (not a problem)
    • Primary-care flavor (not usually a problem, unless you use the hospital build)
  • 13. Toughest Problems
    • Practice management systems exist in practices
      • Must be interfaced to EMR or replaced
      • Wide variability in systems used
    • Hardware infrastructure necessary
      • Required for implementation
      • Not covered by exception
    • Autonomy vs. feasibility
      • Turnkey EMR does not exist
      • Who pays for how much customization?