Name of the blog

Cardiac Surgery MD Group Agrees to Pay $100,000 Settlement to HHS for Lack of HIPAA Safeguards

Mon, 30 Apr 2012 09:21:51 -0900

By: Helen Oscislawski, Principal at Attorneys at Oscislawski LLC

And the HIPAA money keeps rolling to the feds. A late settlement (announced April 17) is with a cardiac surgery physician group in Phoenix, Arizona, which has agreed to pay a hefty sum after someone reported to HHS that the MD group was potentially compromising patients' PHI by posting appointments on an internet-based calendar, which prompted OCR to then investigate and find the physicians to be out of compliance with HIPAA's safeguards.

The following April 17, 2012 Press Release is on HHS' News Release website:

Phoenix Cardiac Surgery, P.C., of Phoenix and Prescott, Arizona, has agreed to pay the U.S. Department of Health and Human Services (HHS) a $100,000 settlement and take corrective action to implement policies and procedures to safeguard the protected health information of its patients. The settlement with the physician practice follows an extensive investigation by the HHS Office for Civil Rights (OCR) for potential violations of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security Rules.The incident giving rise to OCR’s investigation was a report that the physician practice was posting clinical and surgical appointments for its patients on an Internet-based calendar that was publicly accessible. On further investigation, OCR found that Phoenix Cardiac Surgery had implemented few policies and procedures to comply with the HIPAA Privacy and Security Rules, and had limited safeguards in place to protect patients’ electronic protected health information (ePHI).

This case is significant because it highlights a multi-year, continuing failure on the part of this provider to comply with the requirements of the Privacy and Security Rules,” said Leon Rodriguez, director of OCR. “We hope that health care providers pay careful attention to this resolution agreement and understand that the HIPAA Privacy and Security Rules have been in place for many years, and OCR expects full compliance no matter the size of a covered entity.

The HHS Resolution Agreement can be found on HHS' website here. OCR’s investigation revealed the following specific issues with this group's HIPAA program:

Phoenix Cardiac Surgery failed to implement adequate policies and procedures to appropriately safeguard patient information;

Phoenix Cardiac Surgery failed to document that it trained any employees on its policies and procedures on the Privacy and Security Rules;

Phoenix Cardiac Surgery failed to identify a security official and conduct a risk analysis; and

Phoenix Cardiac Surgery failed to obtain business associate agreements with Internet-based email and calendar services where the provision of the service included storage of and access to its ePHI. This last finding being a significant one, and underscores that HIPAA BA Agreements MUST be entered into with vendors who have access to ePHI to facilitate a service to covered entities!

With the HITECH Rules in OMB and due out by mid June (unless an extension is sought by OMB), it will be particularly interesting to see if the Final Rules address the HITECH Act's requirement for percentages being paid out to individuals "damaged" by breaches of their information. The HITECH Act required rules on that topic to be out by this summer. Since an individual's report to HHS triggered this particular investigation and subsequent settlement, some are suggesting that such percentage payouts to individuals for HIPAA violations could in effect become almost like a whistle-blower provision and incentivize patients and others to submit reports to HHS for potential investigation. I think that might be the point.

But for now, this case just underscores once again that the best way for physician practices (and other covered entities) to protect themselves is to have a fully robust HIPAA compliance program developed and implemented. Don't forget to also conduct a Security Gap Audit. Finally, don't forget to provide regular training to your employees.

Peeling Back BCBS’ $1.5 Million HIPAA Settlement Onion

Wed, 21 Mar 2012 04:13:31 -0900

By: Helen Oscislawski, Principal at Attorneys at Oscislawski LLC

On March 13, 2012 HHS announced that Blue Cross Blue Shield of Tennessee entered into a Resolution Agreement for $1.5 Million Dollars to settle potential violations of HIPAA. You can access a copy of the Resolution Agreement here. I find this new case both instructive and frightening, but one has to peel back the layers of this HIPAA-onion to really understand why the Resolution Agreement between BCBS of Tennessee (BCBSOTenn) and HHS/OCR creates an even greater nerve-racking precedent than may be immediately apparent. First, it must be noted that OCR initiated its investigation of the Breach incident and BCBSOTenn only after BCBSOTenn submitted its HITECH Breach Report "in compliance with" 45 CFR §164.408. Therefore, HHS/OCR appears to acknowledge that BCBOTenn's reporting of the Breach was timely, proper and otherwise in compliance with the Breach Notification Rule. And, while BCBSOTenn did not seem to get much reprieve here for its diligent Breach reporting, it’s important to point out that just because a covered entity experiences a Breach does not in and of itself mean that the covered entity has violated the HIPAA Privacy or Security Rule. A covered entity must actually fall short of or be non-compliant with a HIPAA Privacy Rule standard or Security Rule standard before an actual violation can be found.

So, at least hypothetically, a covered entity could still be in full compliance with the HIPAA Privacy and Security Rules, even if it experienced a Breach involving or potentially compromising PHI.

In such a situation, as long as the covered entity properly and timely reports the Breach as required under the HITECH Breach Rule, and has a fully compliant, current, and effective HIPAA compliance program implemented, then the covered entity should be able to assert that there were no violations of HIPAA or HITECH to give rise to HHS/OCR assessing penalties against it. However, at least for BCBSOTenn, apparently the costs and burden of going through an investigation to prove that the Breach was not due to an underlying lapse its HIPAA compliance program was not worth it, at least not $1.5 Million.

What may be most chilling from a compliance perspective here, however, is that the Breach incident itself was allegedly caused by an intervening criminal act, and that BCBSOTenn had presumably paid Eastgate to provide security services to safeguard the data closet where the video and audio recordings were being temporarily stored until their scheduled relocation at the end of November 2009; and, indeed, it seems that Eastgate did have a lot of appropriate physical safeguards in place, including biometric and keycard scan security with a magnetic lock, an additional door with a keyed lock, and basic security services.

So, if BCBSOTenn contracted, paid for and relied on Eastgate to provide security services, one would think that it would be reasonable for BCBSOTenn to believe that it had taken appropriate steps to attempt to safeguard the e-PHI while it was temporarily stored at the data closet. What is not discussed in the Resolution Agreement, however, but would be interesting to know is whether BCBSOTenn’s contract with Eastgate included HIPAA BAA-type language to ensure that Eastgate was aware of the sensitive nature of what they were securing (i.e., e-PHI), and to contractually obligate Eastgate to have in place at least minimum administrative, technical and physical safeguards with regard to how it ensured the security of the data closet. This illustrates a good lesson, which is while a security vendor or a building manager may not technically be a HIPAA BA, as historically defined by HHS (because such third parties are not required to access PHI to perform their function on behalf of the covered entity), in any instance where a covered entity relies on a third party to ensure the security of its PHI or e-PHI, including software vendors, data warehouses, cloud providers and other similar types of third parties, it is important to have such third party contractually agree to have in place HIPAA BA-type safeguards, and to agree to be responsible for any damages that may arise from a Breach that is due to their own negligence. In this case, Eastgate did not respond to evaluate an unresponsive gate for the entire weekend. While it is not clear whether this may or may not have been negligent on the part of Eastgate, hopefully BCBSOTenn had provisions in its agreement with Eastgate that required insurance coverage for such incidents and will allow BCBSOTenn to also potentially make a claim for indemnification if there was indeed fault on the part of Eastgate.

Finally, despite the fact that the theft of the e-PHI was the event that precipitated HHS/OCR to conduct an investigation here, it almost seems that its settlement with BCBSOTenn had less to do with the actual Breach incident itself and more to do with what HHS/OCR may have believed could be lacking with BCBSOTenn’s general HIPAA compliance program. In fact, the corrective action plan (CAP) in the Resolution Agreement does not include any requirement to take any actions, like encryption, with regard to similarly stored data devices. Instead, the CAP focuses on HHS/OCR having the opportunity to review BCBSOTenn’s written policies for conducting a risk assessment, conducting a risk management plan, addressing facility access controls and a facility security plan, and addressing physical safeguards governing the storage of e-PHI. The CAP also requires such policies to be revised, IF HHS/OCR suggest “material changes” to the policies, and to be distributed to all BCBSOTenn workforce, who must then sign a certification of receipt, and be retrained. Now, while that is all well and good, I wonder about HHS/OCR focusing on BCBSOTenn workforce when wasn’t it the employees of Eastgate who were the ones that did not respond to the lapse in security? At least in this instance, then, the real security gap seemed to be with BCBSOTenn’s contracted security vendor’s workforce, not its own.

This case certainly raises questions and concerns with investigation and enforcement processes, but also offers some instruction. First, it is important for covered entities to review their contracts with third parties that may have access to PHI, and most certainly if such third party may be directly or indirectly responsible for ensuring the security of its PHI. Covered entities should include clear language regarding allocation of responsibility for security, and severe repercussions, including potential indemnity, if the vendor falls short. Contracts with technology vendors, cloud providers, facility security providers, and the like are all potential areas where security weaknesses and gaps may exist.

Finally, while the outcome of the BCBSOTenn situation may tempt many to be more hesitant with reporting Breaches to HHS, that is not advisable. Not reporting a Breach incident when it is legally required to be reported under the law could just lead to additional potential penalties for violations of the HITECH Breach Rule. Thus, while Breach reporting clearly can lead to an OCR investigation, as it did here, the best defense may be for covered entities and business associates to ensure that their HIPAA Policies and Procedures are well-developed, updated, and implemented so that they can all be handed to HHS/OCR as proof of full HIPAA compliance, despite any Breach incident having occurred.

Integration Capabilities EHRs Will Need To Have For The Future

Fri, 16 Mar 2012 09:42:20 -0900

Stage 2 of Meaningful Use (MU) is approaching very quickly and appears to require true interoperability. Although current generation EHRs do some interoperability required for Stage 2, they won’t meet or exceed those expectations of modern interoperability. Next generation EHRs will more than likely need a more sophisticated integration capability.

Here are 12 outlined integration capabilities that next-generation EHRs will need to have as outlined by Shahid Shah, software analyst and author of the blog, The Healthcare IT Guy:

1. Single sign-on (SSO)

2. Patient context awareness and context transitions between apps

3. Publishing widgets; next generation EHRs should have the ability to publish features as widgets through authorization and authentication

4. Consuming Widgets

5. Mash-ups with or without content management interoperability services standards

6. Customizable dashboards. Future EHRs should be able to provide highly customizable dashboards that can be tailored by each user and role

7. Interactive Voice Response (IVR). These have been around for quite some time, but next generation EHRs should use IVRs to improve collaboration with patients and other physicians

8. Voice recognition. Integration with voice commands and speech recognition should be able to perform data collection

9. Natural language understanding; next generation EHRs should take type or spoken data and automatically convert it into structured data

10. Customizable import and export of data. Many current EHRs don’t allow the easy import and export, so future EHRs should allow advanced customization for lists

11. HL7 info button because it’s important for future EHRs to connect the patient context and details available in the EHR to public knowledge resources

12. HL7 data types and messages. MU Stage 2 has standardized on HL7 2.5.1 and next generation EHRs need to use it across the board

Information gathered from Healthcare IT News.

February 29th is the Last Day to Report Breaches of <500 to HHS!

Thu, 23 Feb 2012 09:27:56 -0900

By: Helen Oscislawski, Principal at Attorneys at Oscislawski LLC

For those that have been logging their "small" breaches (i.e., less than 500 individuals affected) and waiting to report them to HHS at the end of the year, next Wednesday, February 29th is the LAST day to get your information entered into HHS' Breach reporting website. While covered entities may opt to report each small breach to HHS throughout the year (i.e., including the onsies and twosies), the other option is to log each small breach during the calendar year and report all such small breaches to HHS within 60 days of the end of such applicable calendar year.

A couple of important points to note about reporting small breaches to HHS:

First, the HHS-reporting "buck" stops with the covered entity, not the Business Associate. Even if a breach was caused by a Business Associate (BA), under the current HITECH Breach Rule, the BA's only reporting obligation is to the covered entity; the covered entity is solely responsible for reporting all reportable Breaches to HHS.

Second, follow a “GOLDILOCKS rule” of “Not too much, not too little -- just right.” Covered entities must report all relevant information requested on HHS' online reporting form. However, there are several fields that ask for a typed response. For example, HHS asks for a "brief description of the breach" including how it happened, any additional information about the breach, type of media and PHI. HHS similarly asks the covered entity to describe "other actions taken" in response to the breach. But, while a covered entity must report what it is required to report by law, offering too much information (including impermissibly disclosing patients' PHI, among other things) could land the covered entity in hot water.

Finally, you better have remembered to collect ALL the required information on your Breach Log! A covered entity that is planning to report small breaches at the end of the calendar year must plan ahead and know what information to collect and document, and hint: It's a lot of information that you might not be able to recall at the end of the year unless you documented it as you went along. Among the information that covered entities should be collecting about each "small" breach includes:

Date of the breach?
Date the breach was discovered?
Approximate number of individuals affected?
What "type" of breach was it? (select: theft, loss, improper disposal, unauthorized access, hacking/IT incident, other, or unknown)
Location of the Breach? (select: laptop, desktop computer, network server, e-mail, portable electronic devices, electronic medical record, paper, other)
What type of information was involved? (select : demographic info, financial info, clinical info, other)
What safeguards were in place prior to the breach? (select: firewalls, packet filtering, secure browser sessions, strong authentication, encrypted wireless, physical security, logical access control, antivirus software, intrusion detection, biometrics)
Date individuals were notified? (note: that this date should never be more than 60 days after the Date of Discovery entered, and in any case any "unreasonable delay" in notifying individuals (even if less than 60 days) could be a trigger a closer look by HHS)
Actions taken in response (select : privacy & security safeguards, mitigation, sanctions, policies and procedures, or other)

Even though HHS withdrew the Interim Final Breach Notification Rule during the summer of 2010 (and even though we continue to wait for a final revised version of that rule to be published), covered entities are still required to report all breaches (if there is a positive "Harm" determination) to HHS. HHS specifically points out on its website that "[u]ntil such time as a new final rule is issued, the Interim Final Rule that became effective on September 23, 2009, remains in effect." For Breach Notification training & education, visit our Workshops.

State AG Brings First HIPAA Lawsuit Against Business Associate

Mon, 13 Feb 2012 10:59:58 -0900

By: Krystyna Monticello, Attorney at Oscislawski, LLC

A final "omnibus rule" is expected to clarify the HITECH business associate (and other) provisions this year, but in the meantime, much confusion remains. Despite the lack of final business associate rules, and confusion or not, Minnesota has dived head first into action against a business associate for HIPAA violations. In the first HIPAA enforcement action directly against a business associate, Minnesota Attorney General Lori Swanson has brought an action against Accretive Health, Inc., pursuant to her authority under HITECH. In addition, multiple violations of Minnesota law are alleged, including the Minnesota Health Records Act, debt collection statutes, and consumer protection laws.

Accretive functions in multiple capacities for covered entities in Minnesota, including as treatment coordinator, debt collector and quality cost control and management partner. A breach last summer of data compiled by Accretive resulting from a stolen unencrypted laptop left in a rental car by an employee affected at least 23,531 patients. Information that was on the laptop included personal identifying information (name, address, phone number, Social Security Number), "medical scores" predicting the frailty, complexity and likelihood a patient would be admitted to the hospital, and dollar amounts allocated to the patient's health care provider, as well as whether patients had certain conditions such as bipolar disorder, depression, high blood pressure, asthma, and back pain.

The HIPAA violations are quite extensive, with the complaint alleging:

Failure to implement policies and procedures to prevent, detect, contain and correct security violations;
Failure to implement policies and procedures to ensure appropriate access to electronic PHI by members of its workforce and prevent those without authorized access from accessing such PHI in violation of HIPAA;
Failure to effectively train all members of its workforce, agents and independent contractors, on the policies and procedures regarding PHI as necessary and appropriate to carry out their functions and maintain security of the PHI;
Failure to identify and respond to suspected or known security incidents and mitigate to the extent practicable harmful effects known to them;
Failure to implement policies and procedures to limit physical access;
Failure to implement policies and procedures governing receipt and removal of hardware and electronic media containing electronic PHI within and without the facility;
Failure to implement technical policies and procedures for electronic information systems to allow access only to those granted access rights; and
Failure to implement policies and procedures as otherwise required by HIPAA.

This action has the potential to set precedent in Minnesota as to just how much transparency and information should be viewed as "necessary" for patients to make informed choices regarding their health care and medical records and the extent to which health care entities must take affirmative action to notify patients of their role in their health care. Although the extensive HIPAA violations are merely one drop in the bucket of allegations against Accretive (e.g., fraud and deceptive practices, failure to notify of status as debt collector, release of health records in violation of the Minnesota Health Records Act), the enforcement action against Accretive makes it quite clear that covered entities aren't the only ones who need to be scrambling to get their ducks in a row. While other state Attorney Generals have previously brought actions against covered entities (e.g., Vermont, Indiana, Connecticut), now that a state has gone after a business associate directly, it would not come as a surprise to see other states joining in, even despite the lack of business associate rules. For more information regarding what covered entities and business associates can do to prepare for a HIPAA audit or ward off the potential for enforcement action against them, see our November 17 blog post with links to additional HIPAA resources. A copy of the complaint against Accretive may also be found here.

ACO Rule Keeps HIE Consent “On the Fence”

Thu, 09 Feb 2012 05:00:02 -0900

By: Helen Oscislawski, Principal at Attorneys at Oscislawski LLC

When DHHS published its Proposed ACO Rule in April 2011 and then the Final ACO Rule in November 2011 (I’ll refer to them as the “ACO Rules”), discussions focused predominately on issues such as who is “qualified” to participate, what the required governance structure should be, what methodology will be used to assign Medicare beneficiaries, and what the payment models will be. However, as I digested the ACO Rules, my reading deliberately slowed down as I zeroed in on the not unremarkable language and comments CMS included with regard to sharing individually identifiable health information in the ACO context. Among other things, the ACO Rules would authorize key data sharing between CMS and an ACO. In particular, four categories of data could potentially be shared:

Aggregated Data
Personal Identifiers
Personally Identifiable Claims Data
Prescription Claims Data

In the Preamble to the Proposed Rule, CMS emphasized the importance of sharing these forms of data in order provide more complete information for the services provided or coordinated for the ACO beneficiary populations, better achieve improvements in the quality of care and gain a better understanding of the population served while lowering the growth in health care costs. Notably, while the ACO Rules would permit Medicare beneficiaries to “opt-out” of certain data sharing, other data would be shared without the patient’s consent. Moreover, it is clear that CMS deliberately chose to proceed with an opt-out approach, given its concerns regarding beneficiary participation and ACO Participant administrative burdens. In the Preamble to the ACO Rules, it noted that:

An opt-out approach is used successfully in most systems of electronic exchange of information because it is significantly less burdensome on consumers and providers while still providing an opportunity for caregivers to engage with patients to promote trust and permitting patients to exercise control over their data.” See 76 Fed Reg. 19560 (2011).

CMS acknowledges in the ACO Rules that there could be privacy concerns with sharing identifiable information, but nevertheless takes the position that the HIPAA Privacy Rule permits disclosure for purposes of sharing Medicare Part A and Part B claims data with ACOs participating in the Shared Savings Program. The agency also specifically notes that the disclosures of claims data would be permitted as “health care operations”. Under HIPAA, a covered entity may disclose PHI to another covered entity for the recipient’s health care operations if they both have or had a relationship with the individual, the records pertain to that relationship, and the records will be used for a health care operation function meeting one of the first two paragraphs in the definition of health care operation under HIPAA.

Over the past year, privacy, patient consent and HIE opt-in/opt-out continues to be debated (sometimes painfully). The debate continues essentially because certain stakeholders hold different and strong views on if, when and at what point affirmative patient consent is required (under current law) or should be required (through promulgation of new rules). As a result, some HIE collaboratives have required affirmative patient consent before any data is shared. Similarly, Recommendations from the ONC Tiger Team include, in part, that consent should be obtained before any information is shared with third parties, including Business Associates and HIOs(except where sharing is directed exchange (provider-to-provider), or between providers participating in an OHCA (as as side note, query if ACOs might qualify as OHCAs? probably...at least in some cases)). Others have determined that the value of networked electronic HIE – i.e., healthcare quality improvement and cost reduction – is most efficiently realized when certain data is readily shared without prior authorization or consent, in accordance with HIPAA's exceptions, as a presumed default. Now with CMS throwing its views on consent & opt-in/opt-out into the ring, at least with respect to ACO's data-sharing with Medicare, I'm sure many are anxious to see if the forthcoming HITECH Final Rule and NHIN Governance Rule will offer clear standards for the current HIE consent conundrum, or continue to precariously balance this issue on the fence....... I know I personally can't wait to see. For more a more detailed analysis of privacy and the ACO Rules, download our firm's February 2012 edition of our Health Law Diagnosis Newsletter.

For this article and other articles from Helen Oscislawski, click here.

CMS Provides Guidance on Meaningful Use Appeals Process

Tue, 31 Jan 2012 09:22:00 -0900

By: Helen Oscislawski, Principal at Attorneys at Oscislawski LLC

The Centers for Medicare and Medicaid Services (CMS) have released additional guidance for hospitals and eligible professionals on the Medicare Electronic Health Record (EHR) Incentive Program appeals process. The CMS Office of Clinical Standards and Quality (OCSQ), together with Provider Resources, Inc., the CMS appeals support contractor, will accept and review appeals filed by eligible professionals and hospitals. For those individuals and organizations participating in the Medicaid EHR Incentive Program, each state will have its own process for Medicaid appeals. CMS began accepting appeals December 1, 2011. Appeals may be filed by eligible professionals and hospitals through an online web portal. In addition to eligibility determinations, eligible professionals and hospitals may appeal denials of status as a meaningful user as well as incentive payment calculations. For hospitals, the deadline to appeal eligibility determinations has been extended to January 30, 2012. In general, a hospital or eligible professional has sixty (60) days after the issuance of an incentive payment to appeal the amount of the payment made. Additionally, hospitals and eligible professionals have thirty (30) days to appeal denials of their status as a meaningful user after receipt of a letter with the results of a meaningful use audit conducted by CMS. Limited extensions will be granted on a case-by-case basis under extenuating circumstances.

The first OCSQ informal review determination was released on January 19, 2012. CMS plans on making this and other OCSQ appeals opinions available in February on its EHR Incentive Program Appeals website. These opinions may provide additional guidance to eligible professionals and hospitals seeking to attest in 2012 for their first payment year.

What are Ten Problems with ICD-10? (continued)

Thu, 15 Dec 2011 11:22:00 -0900

A few days ago, I posted five potential problems of the transition from ICD-9 to ICD-10. You can find that post by scrolling down to the title “What are Ten Problems With ICD-10?” This blog post will explain another five potential issues that could occur with the transition. Let us know what you think by writing in our comments section underneath this article.

Testing is a sixth concern of ICD-10. Practices will determine what code represents the health and condition of a patient. Even the correct use of ICD-10 will be difficult to assess from a processing standpoint. If incorrect monitoring is in place, it won’t be noticed until later down-the-road. Industry testing of ICD-10 remains unverified – Before a claim goes out the door, there’s a chance that it could pass through multiple systems on the provider side. Even within the payer, it might have to be transmitted through multiple systems.

With all the uncertainty surrounding ICD-10, it will more than likely disrupt cash flow. The productivity dip that coders and physicians will encounter will have a negative impact for some time. AR days will spike – so providers should prepare. Payers will react and will likely want more specificity for payment. High ranking officials at BlueCross note that although the majority of payers will not disrupt their payments drastically on day one, several factors could result in a claim being mispaid or denied. Mapping errors or the incorrect ICD-10 code to the claim could cause these errors.

From an analytics point of view, the benefit of ICD-10 will be hard to see for years. Data mining between both coding systems will be too difficult. Data collection and storage is not the problem – it’s when data analytics comes into play that it becomes a problem. There isn’t a one on one match between the two. Those dual sets will make it tough for insurance underwriters because those underwriters tend to set rates based on a retrospective analysis of data. The granularity of moving from version 9 to 10 will make it tough – a payer could identify claims that are associated with cardiology, but not know how many conditions or codes are involved with cardiology.

The expense of transitioning to version 10 is unfunded by the government. Organizations have to undertake this completely on their own expense which makes it tough, especially because calculating how much it could cost is a guessing game. Until providers are told the transition plan of their software providers (vendors), they can’t really determine a budget. For hospitals using older vendor systems, it might be better for them to just replace that old system with a new one in order to limit transitional issues.

The success of the conversion depends on the communication of thousands of organizations. Because one organization is ready does not mean it is enough for a successful transition. Each trading partner needs to be prepared, too; those partners include clearinghouses and additional providers. It affects everyone along the line – payers, providers, and software vendors. Vendors’ software may need to be upgraded, so many are working vigorously on those upgrades in order to be ready for conversions. Constant communication between everyone along the line will ensure the smoothest transition.

Federal Government Releases Updated DURSA for NHIN Participants

Tue, 13 Dec 2011 06:53:35 -0900

By: Helen Oscislawski, Principal at Attorneys at Oscislawski LLC

An Amended and Restated DURSA dated May 3, 2011 was released November 30, 2011. The DURSA is an acronym for the "Data Use and Reciprocal Support Agreement." It is a comprehensive agreement to govern the exchange of health data through the Nationwide Health Information Network Exchange (NHIN). It is a multi-party single agreement that establishes the rules of engagement and obligations to which all Participants agree and that all Participants sign as a condition of joining the NHIN community. A clean copy of the updated DURSA can be downloaded from the NHIN's Participant "Onboarding" Website, or by clicking here. The Office of National Coordinator (ONC) has also posted a Redline version comparing the most recent May 2011 version of the DURSA against its predecessor (scroll all the way down to the "DURSA" subcategory).

According to a PowerPoint posted by the ONC that summarizes all the changes to the November 2009 version of the DURSA, here are some of the more significant ones that NHIN Participants can expect:

The term “Nationwide Health Information Network” is defined more broadly, and ONC is phasing out its use altogether.
The composition of the Coordinating Committee is being downsized/reduced significantly. ONC indicated that the current composition is not scalable given the rapid growth in the number and type of Participants.
The definition of "Permitted Purposes" has been revised to support varied types of transactions and not preclude legitimate reasons to transact Message Content including treatment, payment, limited healthcare operations with respect to the patient that is the subject of the data being exchanged, public health activities, meaningful use, and disclosures based on an authorization from the individual.
Each Participant is required to (i) validate information about its Users prior to issuing the User credentials; (ii) use the credentials to verify the identity of its Users before enabling the User to transact Message Content; and (iii) provide truthful assertions. The November 2009 version did not specifically require Participants to “identity proof” their Users or explicitly require a Participant to submit truthful information in the assertions and statements that accompany a Message. At the time, the DURSA developers assumed that these issues would be addressed in the Specifications, but they were not.
Combines duties of a responder and requestor into duties of a Submitter, and adds that Messages must comply with Applicable Law, the DURSA, Operating P&P, applicable Performance and Service Specifications. Submitter must represent that all assertions or statements related to the submitted Message are true and accurate. Also, it is the responsibility of the Submitter – the one disclosing the data – to make sure that it has met all legal requirements before disclosing the data, including, but not limited to, obtaining any consent or authorization that is required by law applicable to the responding Participant.
Removed 24 notice requirement to Coordinating Committee before suspending a Participant. Recognized that process is onerous. Participant can now be voluntarily suspended for 5-10 days.

The government noted that the process has proven itself inefficient and has impeded the ability to amend [Operating Policies and Procedures, and technical specifications]......

The November 2009 version required 2/3 of non-governmental and 2/3 of governmental Participants to approve all changes to the Operating policies and procedures. The government acknowledged that this process has proven itself inefficient and has impeded the Coordinating Committee’s ability to revise the Operating Policies and Procedures. In the May 2011 version, the process for revising and adopting new Operating Policies & Procedures has been revised. Prior to approving new Operating P&Ps, Coordinating Committee will solicit comments from the Participants. There will be a 30 day objection period once the Coordinating Committee approves new or amended Operating P&P. New or amended Operating P&Ps go into effect unless 1/3 of the Participants object. If 1/3 object, then 2/3 of non-governmental and 2/3 of governmental Participants must approve before the new or amended OP&Ps become effective.

In the Nov 2009 version, approval of new or amended Performance and Service Specifications required the Coordinating Committee to make a determination of “materiality,” which then dictates the Technical Committee’s process of approving the Spec change. The government noted that the process has proven itself inefficient and has impeded the ability to amend the Performance and Service Specifications and adopt new Performance and Service Specifications. With the new May 2011 version of the DURSA, new and amended Performance and Service Specifications will be approved in the same way that new and amended Operating P&Ps are approved.

What are Ten Problems With ICD-10?

Fri, 09 Dec 2011 06:06:37 -0900

This will be a two part blog post. Check back in a few days for the remaining five issues.

It is well documented by now that there are several concerns surrounding ICD-10 and its impact on hospitals and healthcare enterprises across the country. In this article, I’m going to highlight five of those concerns to shed some light on what can be expected in the next two years.

A large portion of hospitals still have not completed a full assessment of the total impact of ICD-10; the industry readiness as a whole is staggeringly bad. Hospitals are taking the seriousness of ICD-10 too nonchalantly. Most aren’t quite sure how much their hospital will be affected until they see results – that’s when the shock sets in. Nearly ever department will be affected to some extent. A great example of how many departments and/or systems could be affected by the upgrade is the Kaiser Permanente Health System. After their assessment, nearly 190 systems enterprise-wide will need some sort of alteration when the ICD-10 upgrade takes place.

A second potential issue with ICD-10 is vendor readiness. While some vendors maintain that they are prepared for the transition, it is not definite that every vendor EHR will handle the transition efficiently. Some EHRs will not be totally compatible with ICD-10. This, in turn, could deem very expensive for the provider; Some may need to switch out their EHR so it works with ICD-10. While ICD-9 may fall short in many places diagnostically, ICD-10 will prove a success… in time. Hopefully most providers’ integration with their EHR does not pose a significant problem.

If your hospital or health system has a homegrown application as any part of its inventory or database, it could pose a risk in not being included in an assessment. Some departments are able to evolve their inventory without the watchful eye of their IT staff – so these types of applications could be easily overlooked. It truly has to be an enterprise-wide assessment in order to make the transition as smooth as possible. If your hospital does not have the internal resources to complete an analysis, partner with a consulting firm. While it may be more expensive, it could be more efficient and save you more time than doing it internally.

Productivity declines. What happens when a new system HAS to be implemented as mandated by the government – and that system basically wipes away experience from your coders? Their productivity will decline dramatically… at least until they are familiar with the new procedures and coding. Some hospitals have started training and knowledge programs for their coders in advance, so they can be more prepared for when the full implementation goes into effect. Some hospitals are even planning for smaller revenues from claims for the first year following ICD-10 since productivity will be down. The best thing hospitals can do right now is inform their doctors about documenting properly and training coders for what is to come with ICD-10.

Dual processing will more than likely be an issue with ICD-9 and 10. There will be a period of time in which both will be processing claims interchangeably. One might wonder, “Why?” Claims are based on the date of service, not the date of transmission. For example, a claim for service occurred on September 30th, 2013, a day before the cut-off date. However, it was dispatched on October 2nd, two days later. It would still go out in ICD-9, not ICD-10 – even though the new system had just launched. Because some claims may take months, practices and hospitals will have to deal with denied and rejected claims, hence another reason to prepare for smaller revenues.