Rady HIPAA Breach – Access Controls & Training

June 19, 2014 By

Rady Children’s Hospital in San Diego announced this week that it has discovered two instances of impermissible disclosure of patient information – both disclosures arising from employees sending spreadsheets containing PHI to job applicants.  Surprisingly, Rady employees did not learn the lesson from their northern California neighbor, Stanford, which recently settled a lawsuit for $4 Million based on similar circumstances of a vendor releasing patient information to a job applicant.  In both the Rady situations (and at Stanford) identifiable patient information was sent to job applicants in order to evaluate those applicants’ skill sets.  The spreadsheets contained names, dates of birth, diagnoses, insurance carrier, claim information, and additional information.  Combined, the breach affected over 20,000 patients.

Rady has announced that it will take the following actions to prevent future events:

• Only commercially available and validated testing programs will be used to evaluate job applicants who will be tested onsite.
• We are increasing data security by further automating flagging of emails that may contain potential protected health or other sensitive information, and requiring an added level of approval before it can be sent.
• Rady Children’s is working with our email encryption provider to further strengthen our protection of sensitive data.
• Rady Children’s continually provides employees with education regarding privacy policies. We will be using these incidents as examples to better inform our leadership team and employees about the risks and the importance of the policies we have in place and train them in these new measures we are taking.

Though these steps are important, it is quite alarming that breaches such as these are still happening.  Why are job applicants receiving spreadsheets with patient information?  As Rady notes above, training exercises are commercially available.  Breaches, such as the one at Rady and at Stanford, reveal several flaws in HIPAA compliance – but two in particular rise to the surface.

1.  Access Controls.  The HIPAA Security Rule stresses the importance of access controls both internally and externally within a covered entity (and now business associates). Who gets access to the PHI, who gives that person access, and what access do they have?  The administrative, physical, and technical safeguard requirements all touch on whether access to PHI for workforce members is appropriate.  For example, a technical safeguard requirement specifically addressing access controls requires that covered entities, and business associates “implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in 164.308(a)(4).”  45 CFR 164.312.  Covered entities and business associates alike should evaluate who within their organizations actually need access to PHI to perform job functions.  Does the HR Department or an internal/external recruiter, arguably in charge of hiring new staff, need PHI in order to perform their job duties?  (Note, I do not opine here as to whether access to PHI was properly granted to the workforce members at Rady, as I lack sufficient information to make that judgment).  Determining if access to PHI is appropriate is both a requirement of the HIPAA Security Rule (though it is “addressable” you still need to address it!) and is a good mitigation tactic to avoid impermissible breaches, such as the one here.

2.  Training.  All covered entities and business associates are responsible for HIPAA Security training for all members of the workforce.  45 CFR 164.308.  Though training may vary depending on the workforce member’s use of PHI, all staff must be trained.  Training does not end following an initial session.  Periodic security updates are specifically identified in the Security Rule as an implementation specification.  These updates do not have to be limited to information about new virus protection software installed on the system. They can include valuable tidbits like case studies, HIPAA rule reminders, and HIPAA related headlines.  For some workforce members HIPAA may not be top of mind (specifically for those in business roles that may not deal with patients or patient information on a routine basis).  Providing periodic training updates and reminders, including examples of other HIPAA breaches (i.e. Stanford here) may be very useful in driving home how easy HIPAA breaches can be…and how expensive they are.

Avoidance of HIPAA breaches altogether is nearly impossible, but proper access controls and training can help mitigate against breaches such as the one that occurred here.

For more information about HIPAA Security contact Elana Zana.

 

Filed Under: Breach Notification, Compliance, Health Information Technology, HIPAA Tagged With: , , , ,

$4.8 Million HIPAA Settlement – Patient Data on the Web

May 13, 2014 By

On May 7, 2014, HHS announced that New York-Presbyterian Hospital (“NYP”) and Columbia University (“CU”) agreed to collectively pay $4.8 million in the largest HIPAA settlement to date. The organizations settled charges that they potentially violated the HIPAA Privacy and Security Rules by failing to secure thousands of patients’ electronic protected health information (“ePHI”).

NYP and CU operate a shared data network that links patient information systems containing ePHI. On September 27, 2010, the two entities submitted a joint breach report following the discovery that the ePHI of 6,800 individuals had been impermissibly disclosed due to a deactivated server, resulting in ePHI being accessible on internet search engines. The ePHI included patient statuses, vital signs, medications, and laboratory results.

HHS Office for Civil Rights’ (“OCR”) subsequent investigation determined that neither entity had conducted an accurate and thorough risk analysis or developed an adequate risk management plan to address potential threats and hazards to ePHI security. Further, OCR found that NYP failed to implement appropriate policies and procedures for authorizing access to its databases and failed to comply with internal policies on information access management.

NYP agreed to pay $3.3 million and CU agreed to pay $1.5 million. In addition, both entities agreed to Corrective Action Plans that require each entity to:

  • Conduct a comprehensive and thorough risk analysis;
  • Develop and implement a risk management plan;
  • Review and revise policies and procedures on information access management and device and media controls;
  • Develop an enhanced privacy and security awareness training program; and
  • Provide progress reports.

Additionally, CU must also “develop a process to evaluate any environmental or operational changes” that impact the security of ePHI it maintains.

This settlement again highlights the necessity for healthcare organizations and business associates to create and implement Security policies and procedures, and to engage in a security management process that ensures the security of patient data.

For assistance on the HIPAA Security Rule requirements, drafting and implementing Security policies and procedures, or general HIPAA assistance please contact Elana Zana or Jefferson Lin.

 

Filed Under: Breach Notification, Compliance, Health Information Technology, HIPAA, HITECH Tagged With: , , ,

Stolen Laptops Lead to $2 Million in HIPAA Settlements

April 28, 2014 By

Last week HHS announced close to $2 Million dollars in HIPAA settlements with Concentra and QCA Health Plan due to the theft of unencrypted laptops.  However, the message from HHS is not just the importance of data encryption, rather its performance and follow through with security risk analysis and implementation of security policies and procedures.  Further, the close to $2 million in fines do not include the additional costs and time it will take both of these health care organizations to comply with the OCR corrective action plans.

Concentra

The larger settlement and corrective action plan involved Concentra Health Services, a subsidiary of Humana, Inc., which operates more than 300 medical clinics nationally, including urgent care, occupational and physical therapy, and wellness services.  Concentra agreed to a $1,725,220 settlement with HHS for potential violations resulting from the breach notification associated with a stolen unencrypted laptop.  Specifically, the Resolution Agreement identified the following two deficiencies:

(1) Concentra failed to adequately remediate and manage its identified lack of encryption or, alternatively, document why encryption was not reasonable and appropriate and implement an equivalent alternative measure to encryption, if reasonable and appropriate, from October 27, 2008, until June 22, 2012 (date on which a complete inventory assessment was completed and Concentra immediately took action to begin encrypting all unencrypted devices) (see 45 C.F.R. § 164.312(a)(2)(iv)).

(2) Concentra did not sufficiently implement policies and procedures to prevent, detect, contain, and correct security violations under the security management process standard when it failed to adequately execute risk management measures to reduce its identified lack of encryption to a reasonable and appropriate level from October 27, 2008, (date of Concentra’s last project report indicating that 434 out of 597 laptops were encrypted) until June 22, 2012 (date on which a complete inventory assessment was completed and Concentra immediately took action to begin encrypting all unencrypted devices) (see 45 C.F.R. § 164.308(a)(1)(i)).

Interestingly, while the Security Rule allows for flexibility in implementation for certain measures, including data encryption under 45 CFR 164.312, this high settlement amount indicates that healthcare organizations (including now business associates) who choose not to implement encryption standards must be able to explain themselves.  HHS, in the Resolution Agreement, faults Concentra not only for failing to encrypt the data, but in light of a decision not to encrypt, Concentra was faulted for failing to implement an alternative to encryption (though unclear what a reasonable alternative to encryption would be).  Now, not only does Concentra have this large settlement payment due to HHS, but it has to comply with the corrective action plan, which includes the implementation of a security management plan (with a security risk analysis baked in), encryption obligations, security awareness training, and annual reports to HHS.  And if Concentra fails to comply, HHS has reserved its right to impose civil monetary penalties (which were significantly increased under the HITECH Act).

QCA Health Plan of Arkansas

The smaller settlement of $250,000 was with QCA Health Plan of Arkansas, a healthcare insurance provider.  The impetus for this settlement and corrective action plan was the theft of an unencrypted laptop from an employee’s car which contained PHI belonging to 148 individuals (note that this breach affected less than 500 individuals).  The Resolution Agreement determined that:

A.  QCA did not implement policies and procedures to prevent, detect, contain, and correct security violations, including conducting an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI it held, and implementing security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with 45 C.F.R. § 164.306 from the compliance date of the Security Rule to June 18, 2012.

B. QCA did not implement physical safeguards for all workstations that access ePHI to restrict access to authorized users on October 8, 2011.

C. QCA impermissibly disclosed the ePHI of 148 individuals on October 8, 2011.

Unlike Concentra, QCA was not directly faulted for failing to encrypt its laptops, or failing to implement a reasonable alternative. Rather, this settlement focused instead on the lack of sufficient HIPAA Security policies and procedures, inadequacy in conducting a security risk assessment, and the failure to implement security measures, most specifically physical safeguards. The corrective action plan is also noticeably different, with a focus instead on workforce training and reporting of workforce non-compliance, rather than on encryption requirements (the press release notes that QCA encrypted its laptops following the breach).

Though like most breach cases the simple solution is to encrypt the data to avoid an actual breach, these settlements expose the depth of compliance obligations and monetary consequences associated with the failure to securely protect the PHI.  Concentra and QCA, like other health care organizations who have settled with HHS, will have years of compliance reporting obligations and security management requirements that will likely create significant cost burdens in addition to the monetary settlement obligations.  HHS has made it quite clear in its press releases and corrective action plans, healthcare organizations and business associates must create and implement Security policies and procedures, and must engage in a security management process that ensures the security of patient data post the initial implementation.

For assistance on the HIPAA Security Rule requirements, drafting and implementing Security policies and procedures, or general HIPAA assistance please contact Elana Zana.

Filed Under: Breach Notification, Compliance, Health Information Technology, HIPAA, HITECH, Security Tagged With: , ,

HHS Releases Security Risk Assessment Tool

March 28, 2014 By

Need help performing your HIPAA/Meaningful Use Security Risk Assessment?  Good news, HHS has released a tool to help!  In partnership with the Office of the National Coordinator, HHS created a tool, user guide, software, tutorial, videos and even an iOS App to help HIPAA covered entities and business associates perform the required HIPAA Risk Analysis.

The HIPAA Security Rule specifically requires (this is not an addressable specification) a Security Risk Analysis:

“Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.”  45 CFR 164.308(a)(1)

In addition, those hospitals and eligible professionals seeking to meet meaningful use in order to receive the EHR Incentive dollars or avoid the Medicare payment adjustments must fulfill a HIPAA Security Risk Assessment.

Stage 1

Stage 2
Objective. Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities.Measure. Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process. Objective. Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities.Measure. Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data stored in Certified EHR Technology in accordance with requirements under 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the EP’s risk management process.

For those hospitals and eligible professionals looking to meet meaningful use, the Security Risk Assessment tool will generate a report that can be provided to auditors.  However, the report alone is likely insufficient because both the auditors and the  meaningful use requirements (above) require the correction of security deficiencies – so merely running a Security Risk Assessment without taking actions to remedy the problem will not suffice.  To read more about meaningful use audits and security risk assessments click here. 

In addition to releasing the Security Risk Assessment tool, HHS has created a helpful true/false statement with the Top 10 Myths of Security Risk Analysis.  This document highlights the misconceptions regarding the risk assessment requirements, including that all covered entities and business associates (regardless of the size) must conduct a risk assessment pursuant to HIPAA.  Importantly, though only eligible professionals & hospitals are eligible for meaningful use incentives and Medicare payment adjustments, business associates must also comply with the HIPAA Security Rule pursuant to the HITECH Act.  Therefore, business associates must also conduct security risk assessments, and per recent guidance from HHS, business associates are likely part of the next round of HIPAA audits.

For more information about HIPAA, security risk assessments, and meaningful use please contact Elana Zana.

Filed Under: Business Associate, Compliance, Health Information Technology, HIPAA, HITECH, Incentive Payments, Meaningful Use Tagged With: , , , , ,

$4 Million Stanford Settlement – Business Associate Pays Majority

March 27, 2014 By

Remember the $20 Million class action law suit against Stanford due to the posting of an Excel file online by a Business Associate?  The law suit, driven by California state privacy laws recently settled for $4 Million, with the Business Associate paying the bulk of the settlement.  The class action suit, one of five large Stanford related large HIPAA breaches, stems from a 2010 disclosure of emergency room patient data affecting 20,000 patients. The majority of the settlement fund, $3.3 million will come from Stanford’s business associate. Stanford is contributing $500,000 for a vendor education fund and is paying $250,000 in settlement administrative costs.  Though a significant reduction from the $20 Million original claim, the $4 Million settlement price tag is not a drop in the bucket.

The major lesson to glean from this case is that covered entities should better investigate their vendors before transmitting PHI.  Meaning not just simply executing a Business Associate Agreement with an indemnification and insurance provision (though advisable), but also reviewing/evaluating their current security policies, staff training, use of subcontractors, and encryption standards.  For more information about HIPAA please contact Elana Zana.

Filed Under: Compliance, Health Information Technology

PROTECT Act Seeks to Exclude Health IT Software from FDA Oversight

March 19, 2014 By

Last month, Senators Deb Fischer (R-Neb.) and Angus King (I-Maine) introduced proposed legislation, the PROTECT Act (Preventing Regulatory Overreach To Enhance Care Technology) of 2014 (full text available here), which seeks to remove the Food and Drug Administration’s (“FDA”) regulatory authority over certain health information technology (“health IT”) software.

Main Provisions of the PROTECT Act

Specifically, the bill proposes that “clinical software” and “health software” shall not be subject to regulation under the Federal Food, Drug, and Cosmetic Act (“FD&C Act”).  The bill defines “clinical software” as “clinical decision support software or other software (including any associated hardware and process dependencies)…that captures, analyzes, changes, or presents patient or population clinical data or information and may recommend courses of clinical action…and is intended to be marketed for use only by a health care provider in a health care setting.”

The term “health software” means “software (including any associated hardware and process dependencies) that is not clinical software and (a) that captures, analyzes, changes, or presents patient or population clinical data or information; (b) that supports administrative or operational aspects of health care and is not used in the direct delivery of patient care; or (c) whose primary purpose is to act as a platform for a secondary software, to run or act as a mechanism for connectivity, or to store data.”

Both “clinical software” and “health software” would not include software “(a) that is intended to interpret patient-specific device data and directly diagnose a patient or user without the intervention of a health care provider; (b) that conducts analysis of radiological or imaging data in order to provide patient-specific diagnostic and treatment advice to a health care provider; (c) whose primary purpose is integral to the function of a drug or device; or (d) that is a component of a device.”

The PROTECT Act also proposes that the National Institute of Standards and Technology (“NIST”) be the Federal agency that oversees technical standards used by clinical software.  In addition, the Act recommends that NIST, along with the Federal Communications Commission, the National Patient Safety Foundation, and the Office of the National Coordinator for Health Information Technology, collaborate with nongovernmental entities to develop certification processes and promote best practice standards for health IT.

PROTECT Act Supporters Cite FDA’s Overreach and Slow Process

Proponents of the bill argue that, given the FDA’s broad definition of “medical device”, the FDA’s authority to regulate health IT is too extensive and that the FDA’s slow safety review process hurts innovation.  Senator King explained to the Boston Globe, “While blood-glucose monitors, pacemakers, and other high-risk devices must remain under the current FDA regulations, low-risk software like wellness apps and electronic health records need not be subject to burdensome regulations.”

Although the FDA in September 2013 issued non-binding guidance on how the agency would regulate mobile medical applications, some in the health IT industry are uncomfortable with the uncertainty surrounding the FDA’s regulatory discretion.  Along with athenahealth, which issued a document called “In Defense of the PROTECT Act,” supporters of the bill include IBM, Verizon, McKesson, and Software & Information Industry Association.

Critics Raise Patient Safety Concerns

Critics contend that the PROTECT Act’s creation of a regulatory exception for health IT software undermines the FDA’s role in safeguarding the public’s health.  They warn that flaws with digital records systems can lead to dangerous, and even fatal, consequences.  A 2011 Institute of Medicine report found that “dosing errors, failure to detect life-threatening illnesses, and delaying treatment due to poor human-computer interactions or loss of data have led to serious injury and death.” A more recent study of medical malpractice claims confirms that electronic health record-related vulnerabilities such as faulty data entry, unexpected conversions, or incorrect files/fields can lead to medical errors.

PROTECT Act opponents argue that patient safety is an area that the FDA has experience with and should regulate, whereas NIST’s mission is to promote U.S. innovation and industrial competitiveness.  The mHealth Regulatory Coalition, along with other advocacy groups like the National Physicians Alliance, Public Citizen, and the Union of Concerned Scientists have voiced concerns about the PROTECT Act.

Conclusion

Those interested in the future policy and regulatory framework of health IT should keep an eye on this proposed legislation.  In the coming months, the Obama administration also plans to release recommendation on how health IT systems should be regulated for safety.  As the adoption of health IT and electronic health records systems expands and as health IT becomes more sophisticated, the proper role of the FDA in regulating the safety of health IT will continue to be a subject of intense debate.

For more information about the PROTECT Act, FDA regulation or health IT policy issues, please contact Jefferson Lin or David Schoolcraft.

Filed Under: Compliance, FDA, Health Information Technology Tagged With: , ,

Increased OIG Focus on Kwashiorkor Claims

March 10, 2014 By

In its recently released 2014 Work Plan, the OIG has announced that it will investigate hospital billing for Kwashiorkor.  Kwashiorkor is a form of severe protein malnutrition that generally affects children living in tropical and subtropical parts of the world during periods of famine or insufficient food supply. This syndrome is characterized by retarded growth, changes in skin and hair pigment, edema, and pathologic changes in the liver.

This extreme form of malnutrition, however, is very rare in the United States, which is why Kwashiorkor billing at hospitals is a target of the OIG. Because a diagnosis of Kwashiorkor on a claim also substantially increases a hospital’s reimbursement from Medicare, the OIG stated it would review Medicare payments based on Kwashiorkor claims to determine whether the diagnosis is adequately supported by documentation in the medical record.

Recently, for example, the OIG found that Wellspan York Hospital incorrectly billed Medicare inpatient claims with Kwashiorkor, resulting in overpayments of $204,000 over two years. The hospital attributed the errors to a misinterpretation of the coding guidelines for malnutrition because of a lack of clarity in the guidance.  Other hospitals, like Mercy Medical Center, have attributed Kwashiorkor errors to encoder software which incorrectly assign diagnoses of protein malnutrition to ICD-9-CM 260 (Kwashiorkor).

In light of the increased OIG focus on Kwashiorkor claims, hospitals should strengthen its controls to ensure that coding software and staff comply with Medicare billing requirements. Additionally, if there is in fact a Kwashiorkor diagnosis, hospitals should ensure that the medical record (e.g. discharge summary) substantiates the use of a Kwashiorkor diagnosis code.

For additional information regarding Kwashiorkor billing or the 2014 OIG Workplan please contact Adam Snyder or Jefferson Lin.

 

Filed Under: Compliance, Medicare, OIG Tagged With: , ,

Upcoming HIPAA Audits Will Include Business Associates

March 5, 2014 By

On February 24, 2014, the Department of Health and Human Services (“HHS”) published a notice of its proposed collection of information in connection with its HIPAA audit efforts.  Comments on the proposed collection request must be submitted by April 25, 2014.

The notice indicates HHS’s intent to survey up to 1,200 organizations, including both covered entities and business associates, to determine the organizations’ suitability for HIPAA audits by HHS.  The survey will seek information about an organization’s patient visits, use of electronic information, revenue, and business locations, among other things.  The notice hints that some sort of technology will be used to complete the survey, as HHS’s time estimate of 30-60 minutes to complete the survey includes the time needed to “develop, acquire, install and utilize technology and systems for the purpose of collecting, validating and verifying information…”. The notice does not include details on the criteria HHS will use to select an organization for an audit.

One of the notable items of this notice is HHS’s announcement that this round of HIPAA surveys will include business associates as well as covered entites.  This is a clear signal that HHS is getting serious about HIPAA compliance by all organizations who handle protected health information.

For more information about HIPAA audits and HIPAA enforcement, please contact Lee Kuo.

Filed Under: Business Associate, Compliance, HIPAA, HITECH Tagged With: , ,

2014 OIG Work Plan Contains New Priorities Specific to Hospitals

February 27, 2014 By

The Department of Health and Human Services, Office of the Inspector General (OIG) recently released its Fiscal Year (FY) 2014 Work Plan.  The Plan contains new priorities specific to Hospitals in areas related to Policies and Practices, Billing and Payments, and Quality of Care and Safety.  For a complete copy of the OIG 2014 Work Plan, please click here.

The OIG Work Plan provides a description of what the OIG will be focusing on in the coming year, giving providers insight into identifying corporate compliance risk areas and providing focus for ongoing efforts relating to compliance program activities, audits, and policy development.  Some of the hospital-specific priority areas identified as ‘New’ include the following:

A.      Policies and Practices

  1.  2 Midnight Rule: As of FY 2014, physicians should admit inpatients where they expect the patient’s care to last at least 2 nights in the hospital.  This modification is due to the OIG’s previous findings of over payments for inpatient stays, inappropriate billings and inconsistent billing practices.  OIG plans to review the impact of this new admission criteria and how billing varies among hospitals.
  2. Defective Medical Devices: OIG will review the increased costs to Medicare resulting from additional services necessitated by the use of defective medical devices.
  3. Comparison of Provider-Based and Free-Standing Clinics:  OIG will compare the payments made in provider-based settings and free-standing clinics with respect to similar procedures to determine the potential impact to the Medicare program for hospitals claiming provider-based status, and presumably, whether providers claiming provider-based status meet the criteria in 42 CFR § 413.65(d).

B.      Billing and Payments

  1.  Outpatient Evaluation and Management Services:  OIG will review payments made for outpatient E/M services to determine if they were appropriately billed as “new” or “established.”  Patients are generally considered “new” unless they were seen as a registered inpatient or outpatient within the past 3 years.
  2. Cardiac Catheterization and Heart Biopsies:  Billings for right heart catheterizations will be reviewed to determine if they were appropriately billed separate and apart from billings for heart biopsies.
  3. Payments for Patients Diagnosed with Kwashiorkor:  Due to the high level of reimbursement, billings for Kwashiorkor will be reviewed to determine whether diagnoses are supported by the medical record.
  4. Bone Marrow or Stem Cell Transplants: OIG will review procedure and diagnosis codes to determine the appropriateness of bone marrow and stem cell transplantation.

C.      Quality of Care and Safety

  1. Pharmaceutical Compounding:  In light of a recent meningitis outbreak resulting from contaminated injections of compounded drugs, OIG will review the oversight and accreditation assessment of pharmaceutical compounding in Medicare-participating acute care hospitals.
  2. Review of Hospital Privileging:  OIG will review how hospitals consider medical staff candidates prior to granting initial privileges, verification of credentials, and review of the National Practitioner Databank.

For additional information regarding the 2014 OIG Workplan or hospital/corporate compliance please contact Adam Snyder.

 

 

Filed Under: Compliance, Hospitals, OIG Tagged With: , , ,

Key Lessons Related to Stark Compliant EHR Donation Arrangements

February 26, 2014 By

Is your entity thinking about engaging in a Stark/AKS Compliant EHR Donation Arrangement?  If so, check out this list of top 5 issues to consider as you are assessing your options and your health IT alignment strategy.

1.  An EHR donation arrangement is an effective way for hospitals to align with their physicians.

In the world of health information exchange, having the technological ability to seamlessly communicate with a hospital or referring physician is crucial to effective patient care.  It enables physicians and hospitals alike to efficiently obtain patient information and to exchange this information as needed to ensure quality patient care.

2.  There are specific rules – and significant consequences for breaking those rules.

Be careful not to run afoul of the Stark or Anti-Kickback rules.  Ensure that your contracts are compliant with both Stark and Anti-Kickback and that the arrangement is not designed at rewarding referring physicians.  

3.  What is the hospital taking on when it becomes an EHR vendor?  

What are the consequences for a physician practice if the local hospital is also its EHR vendor?  In many arrangements the hospital is the contracting party with the EHR software vendor (i.e. Epic, Cerner, etc.) and owns the relationship.  Physician groups will look to the hospital to obtain necessary service, updates, modules and when the system malfunctions.  The hospital should evaluate if it is able to take on this role.

4.  Physicians need to know what to expect as recipients of an EHR donation.

Often times the physician group is giving up its autonomy in choosing the EHR vendor, configuration or customization and must often defer to the hospital to make appropriate purchase, upgrade and service decisions.  In addition, even though the hospital may be picking up the majority of the costs (no more than 85%) the investment may still be expensive (and will likely exceed the meaningful use incentive dollars).  Items such as hardware, storage, and operating system software are excluded from the donation.    

5.  Before you align, be clear about who will get the “record collection” if things don’t turn out.

Before entering into a donation arrangement the parties should have a clear understanding of what happens if the relationship goes awry.  How will the records be divided, extracted, or migrated into a new system?  Will the physician group be able to maintain a relationship with the software vendor independently?  What are the ramifications of changing vendors and separating from the hospital EHR?

Special thanks to ECG’s Michelle Holmes and OMW attorney David Schoolcraft for composing this list based on their HIMSS14 presentation “Using Stark/Anti-Kickback to Support Hospital/Physician IT Alignment Strategies.

For more information on designing Stark/Anti-Kickback compliant donation arrangements please see the previous posts describing the exception requirements and the 2013 updates.  For assistance in creating a donation arrangement please contact Elana Zana, Michelle Holmes or David Schoolcraft.

 

Filed Under: Anti-Kickback/Stark, Compliance, EHR, Health Information Technology, Stark Tagged With: , ,
Next Page»