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.

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.

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.

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.

By: Helen Oscislawski, Prinicpal at Attorneys at Oscislawski LLC

The United States Department of Health and Human Services (HHS) has announced that it will begin HIPAA audits of covered entities and business associates this November 2011, and its contracted auditor, KPMG, is required to audit up to 150 entities by the end of 2012!  HHS’s website provides detailed information regarding when the audits will begin, who may be audited, how the audit program will work, what the general timeline will be for an audit, and, generally, what will happen after an audit is completed. In addition, HHS's sample Audit Letter indicates that KPMG will focus on discovering vulnerabilities in privacy and security compliance programs, and that certain “information” and “documents” will be requested in connection with the audit. However, no additional details are given regarding what covered entities and business associates may be asked to produce.

Presumably, KPMG will not be letting the HIPAA audit cat out of the bag too soon by telling organizations exactly what information and documents they may ask for in connection with such audits, especially where one of their objectives is to identify gaps in HIPAA compliance. Nevertheless, covered entities and business associates may gain valuable insight into what to expect by looking to past guidance regarding HIPAA audits issued by HSS’s Office of e-Health Standards and Services (the “HIPAA Audit Checklist”), as well as by reviewing HIPAA audits and investigations that have taken place over the last few years.

In its formerly-released HIPAA Audit Checklist, the Office of e-Health lists out the types of personnel that may be interviewed, and the the types of policies, procedures and other documentation and evidence that may be requested.  In addition, the audit of Atlanta, Georgia’s Piedmont Hospital is informative. In February of 2007, HHS through the Office of Inspector General conducted a random HIPAA audit of Piedmont hospital.  The letter to Piedmont’s CIO announced that the focus of the audit would be on the organization’s compliance with the Security Rule and indicated that the audit would begin with an “entrance conference” 10 days after Piedmont’s receipt of the audit letter from the Regional Inspector General for Audit Services (note that the proposed timeframe for coming KPMG audits is 30-90 calendar days from the date on the applicable HHS Audit Letter).  The Piedmont audit letter also included an enclosure asking for a list of documents and information to be provided, which overlapped significantly with the Office of e-Health’s HIPAA Audit Checklist!   Covered entities and business associates may also glean additional insight from what HHS/OCR has asked for in connection with complaint-driven HIPAA investigations. HHS/OCR has posted on its website several Resolution Agreements with covered entities who have been through a HIPAA investigation.  These agreements also contain hints as to what covered entities and business associates may be asked for during a HIPAA Audit.

Until news of organizations starting to receive HIPAA audit letters starts to trickle out and KPMG begins its work, it is not possible to know exactly what KPMG will ask for and focus on.  Nevertheless, covered entities and business associates should not sit back and take a “wait and see” approach.  Rather, organizations should prepare now by completing an internal review of their HIPAA compliance program to ensure that their policies are current and are being followed by their workforce, and all other required HIPAA documentation is in place and ready to be produced in case a HIPAA Audit letter arrives in the mailbox tomorrow.

Click here to download a copy of Oscislawski LLC's November edition of "Health Law Diagnosis", which includes a list of HIPAA compliance items that all covered entities and business associates should have in order to be prepared for a HIPAA Audit.

By: Dan Janowak, Consultant, Epic Practice

The following is a fictional scenario.

A slight preamble

In the real world, things aren’t always nice and orderly, and events sometime fly by in seemingly random sequences. The first paragraph is a mad rush that might accompany a particular fictional Epic system scenario that could happen just after go live.

And so it begins (the story that is)

Your phone rings and there is an emergency change control meeting being called. Three days ago, a change was made to the system definitions, configuration, and SUP (customers’ daily copy of production). It had been overwritten and the former system definitions aren’t available. Someone had already checked back to an older environment and nothing seemed to have changed to cause the problem. It was suggested that it was possible the change was made and undone, but no one can identify what had changed in the system definitions. From the Data Courier reports, it was seen that the entire record was sent instead of just the one or two items that were most recently intended to be moved to production. But in fact, the person who had made that most recent change had a JXPORT of their change before and after they made the change.

A narration

The time just after go live can be quite the whirlwind, especially for those who take stress and anxiety seriously, or have no choice. In the story, a change in live functionality that was undesired had been detected, but not fast enough. And based on how most Epic customers are set up, the ability to recover changes made the day before weren’t useful because the change in live functionality had been detected too slowly. Yes, the fictional people should have been more vigilant or spent more time monitoring the system, but they were probably all very busy taking care of other issues that had arisen after go live.

Fortunately the fictional organization had a strong change control team with the primary rule being ‘Don’t Break Prod.’ Except, there wasn’t a required policy that certain very important records and pieces of information were always recorded – usually by an Epic technology called JXPORT to record the ‘before’ and ‘after’ a change to enable putting production back to its former state of being. The good news is that the strong change control team had a document that was required reading for each team member that gave advice on how to better manage their changes and increase the ability to mitigate or reverse changes that later turned out to have unintended effects.

The story continues…

After the meeting and more investigation of the Data Courier table, it turned out that a different change had occurred a couple days ago but hadn't been noticed as having the undesired effect. The change from three days ago had also been recorded with JXPORTs before and after the change. Those changes were triaged, updated, and a new set of changes were tested and moved to production.

The Closing

What happened in the story above is that two changes had been made and the users who made those changes had gone above and beyond change control requirements, but they used change control suggested methods to record their changes. Days later, it was determined that the most recent change was blamed, but vindicated for causing an undesired shift in live functionality and the earlier change was then identified, validated, tested, and updated to produce the desired shift in live functionality. No real harm, no real foul. These things happen, and the more tools we have available to prevent or mitigate them, the better.

Without the record of the changes before and after each set of changes, the investigation into what broke production, or rather what caused an undesirable shift in live functionality could have taken weeks to figure out and restore instead of a single afternoon. The results could have been the wrong person being disciplined or fired.

In general, the faster things can be restored, figured out, or made to work as expected, the more confidence and good will that gets generated. We also become better partners to each other, our stakeholders, and our respective organizations. Reputations can be significantly impacted.

No matter how strong the change control team, a good, strong document on how to prevent and mitigate undesired changes to live functionality can save the day.

By: Dan Janowak, Consultant, Epic Practice

The beginning of the story

An email notification appears and it is a Director noting, "I can't tell what happened with this account. Can you tell me why this account is in ‘HB Acct WQ (Work Queue) 347?’ And, I'm seeing a lot of system action activity in Account History."

The investigation and troubleshooting

You check Account Maintenance and have gotten no further than the director who has proven time and again to be on top of her game. You know about Record Viewer and have the security as a build team member to use it. You check the Hospital Account (HAR) and scan through the very “techie” bits of data until you come across the WQ activity.

You determine that a user manually placed the account into the WQ, which means it will stay there forever, or until the account moves to a closed status; whichever comes first. Going further, you find the system action information stored on the HAR , and combined with the Audit Trail in Account Maintenance, you figure out someone has been working an account over the past two weeks. The user apparently had conflicting information as noted in the Account Notes, so the account kept bouncing between system auto actions because of the related changes to account information.

The pot of gold

The “smoking gun” can be found in many places, but Record Viewer is nearly a one-stop-shop for the investigation of individual cases. That’s because it has the ability to click on Hyperlinks to jump to the next linked record to follow the trail to the smoking gun. The savvy consultant can find definitive answers with the combination of Record Viewer (a direct view into the database) and a report tool like Account Query, Census reports of Department Appointment Reports (DARs), or reporting workbench reports. Record Viewer shows most, but not all data Epic has stored regarding the records. And it isn’t the only Epic technology that can do what it does (Some of us may recall using EAVIEWID way back in the early Epic day).

After the above investigation (which could take as little as five minutes with the right tools), you forward your answer back to your director to give them that little pot of gold you found, generating confidence and added good will. The end user was doing good work, but the timing and nature of the information caused some turbulence.

The Closing

If you don’t follow all of the above, that’s ok. It is written to quickly skip over an enormous topic, while still giving enough hints for the investigators/build teams to add to their tool kit. And, it’s enough hints for others to know what questions to ask if they are looking for a person who can find the smoking gun.

In essence, you need four things:

1) A tool like Record Viewer or EAVIEWID to be able to view all details of a single record, or just the important pieces all in one place/screen.

2) A tool to move from record to record to follow the bread crumbs. Record Viewer does this easily, and EAVIEWID can do slowly and without a quick ability to go backwards in the bread crumb trail.

3) A tool like Account Query, Chronicles, Reporting Workbench, Clarity, or certain standard application reports to be able to generalize the findings from single cases to all similar cases in the system.

4) The ability to recognize who has the skills to do 1 through 3 for you or your organization.

This is meant to be a short and quick point, and yes there are additional methods and tools available, some of which are more powerful than all of the above combined - which is to say, if you don’t find your pot of gold here, then it doesn’t mean it doesn’t exist.

ICD-10 presents itself with many challenges and complexities while the deadline of October 2013 is quickly approaching. For most organizations, this type of implementation and change is hospital-wide. To put it simply, ICD-10 migration will affect nearly every department in the hospital to some extent. A wise decision for any hospital would be to have a steering committee with representation from IT, Rev Cycle, HIM, and Clinicians to ensure the smoothest transition possible. The way to attack the transition will differ depending on your unique hospital; no two transitions will be alike. However, according to Healthcare Informatics Magazine, the technical issues of ICD-10 are not too bad – it’s the training of clinicians and coders that represent the biggest obstacle.

The key to ICD-10 transition is the training of clinicians and coders as early as possible. The suggested training time of these clinicians and coders is 3 to 6 months before go-live. Do not train too early, or else you risk those individuals forgetting the training they received. Because there is such a large difference in ICD-9 and ICD-10 codes, physicians and clinicians will need to be trained in proper documentation and coders themselves will need training in the new process and code list. For physicians, an average of only 4 hours in medical school is dedicated to proper documentation for coding. Without properly identifying the diagnoses, some coding is entered incorrectly. Insurance companies can then be billed improperly or incorrectly. If this is the case, it could lead to denied claims from the payor and then more effort to recode, resubmit, and appeal the denied claim – all adding additional cost to get the claim paid.  So, proper coding the first time will help get the claim paid quicker. Educating those clinicians or physicians so they can write the correct diagnosis for the coders is extremely important.

As far as the system itself, it’s not just about adding the field by a few digits; it is literally a new coding methodology. There are thousands of new codes being introduced to the new system. Not only are the codes becoming more detailed per specific diagnosis, but the number is increasing dramatically. In a way, when do we know when something is too detailed, or there are too many codes? For example, there is code for being bitten by a turtle, and there is also a separate code for being “charged” by a turtle. Where is the line drawn for complexity of codes? How do we know if it is too much?

Many organizations are targeting their training and education processes differently. Ensuring a creative way to train in the new processes may assist in a smoother coding transition. Investing in products that show a crisscross methodology can show coders how ICD-9 codes would show in the ICD-10 system. Other organizations are researching their top diagnoses to see how much they will change from the 9 system to the 10 system. They’ll then use that research to guide and strategically educate their coders and clinicians. It is all about finding which process would be best for your specific hospital and employees.

What about the complexity of Meaningful Use (MU) and ICD-10 together? There is growing testimony that ICD-10 and MU complexities are “clashing.” According to Dr. Peter Muir, one of the first to receive federal reimbursements of MU, MU is making ICD-10 more complicated. Dr. Muir noted that because his practice is being compliant with MU, he cannot modify the coding templates as much when trying to crosslink ICD-9 and ICD-10. Instead, he advises future migrators to do the ICD-10 transition first. To be able to run a parallel in ICD-9 and ICD-10 rather than trying to modify each template in short order would make the transitions much easier. That way, many codes would automatically transfer to the ICD-10 system. But with the extreme detailing of diagnoses in ICD-10, how do we know each code would transfer properly, anyway? Transferring codes from a less detailed system (ICD-9) to a more detailed system (ICD-10) could present problems. Dr. Muir doesn’t believe the new ICD-10 system will help physicians in the practice of patient care. In fact, he thinks it will have a negative impact on healthcare in this critical time – it will cost a lot of money and not really improve care. Many doctors will be retiring earlier rather than later, he says.

What do you think about the complexity of ICD-10 and Meaningful Use? Do you think Meaningful Use and ICD-10 transitions will cause complexity issues?

Need guidance or assistance on an ICD-10 assessment or implementation? VCS can help! Email vcs@getvitalized.com, or call 610.444.1233.

By: Helen Oscislawski, Principal at Attorneys at Oscislawski LLC

In June of 2010, a large healthcare system was informed by its business associate that a breach had occurred, affecting thousands of patients at its hospital.  The breach had occurred the previous month when an employee of the business associate lost an unencrypted flash drive that may have contained patient information.  Although the breach was reported last year, news regarding the breach appears to have begun circulating this past week, most likely due to the new role of the business associate in question, which is none other than KPMG, the prominent auditing, advisory and tax company that was recently awarded $9.2M by the Office for Civil Rights (OCR) to conduct HIPAA privacy and security compliance audits!

Although the flash drive reportedly did not contain patient information such as social security numbers, addresses, personal identification numbers, dates of birth or financial information, the embarrassing fact remains that a KPMG employee used an unencrypted flash drive to carry around patient information.  Not only is it surprising that KPMG was responsible for the breach, but what is equally surprising is the length of time that went between the discovery of the loss of the flash drive by KPMG (May 10, 2010) and the report that was sent to its customer regarding the loss (June 29, 2010).  Although KPMG just barely notified its covered entity customer within the HITECH sixty (60) day notice requirement, one has to wonder why it took so long for KPMG to discover that the device was missing and/or report?    Another question to ask is why a KPMG employee would need to carry around patient information on a flash drive to begin with (especially an unencrypted one)? 

This incident just goes to show that a breach can happen to "the best" of us.  It also highlights a big problem for hospitals and other health care providers when it comes to security of patient information.  All too often residents, nurses and other health care providers copy patient information onto flash drives, laptops or other unencrypted devices which are easily lost or stolen.  These risks must be identified and aggressively managed by health care organizations and their business associates (!) to minimize the risk of breach to such organizations and the patients they serve.

HealthLeadersMedia reports that Susan McAndrew, OCR deputy director for health information privacy, wrote in an email that the case was currently under investigation and as such, OCR could not address KPMG's involvement in the breach.  When asked whether KPMG's involvement in the breach had been considered prior to awarding it the HIPAA audit contract, McAndrew stated,  "The award of the HIPAA audit contract was the result of HHS’ usual, rigorous, competitive process. Specific questions regarding the contract award are procurement sensitive."   The public notice made available by the hospital on its website stated that, KPMG has told us the company is implementing measures to avoid similar incidents in the future, including additional training and the use of "improved encryption" for its flash drives. Worthy to note, however, is that the flash drive that went missing reportedly did not have any encryption mechanisms.  One would hope though that KPMG has followed through and improved its security measures, given that it is now an ONC HIPAA auditor with the potential to access patient PHI and other information in the course of its auditing activities.

On March 23, 2010, the healthcare world changed drastically. One thing is certain: The law Obama signed into effect will impact each and every stakeholder in healthcare (patients, physicians, nurses, insurers, healthcare IT vendors, businesses, and drug makers). Since hospitals are considered to be a business, they’ll see changes first-hand.

The new law will introduce changes as to how providers should deliver care. However, there will be opportunities for hospitals to be actively involved in those changes. They can participate in pilot programs and/or demonstrations to better coordinate their payments with the quality of care provided to patients.

There is one key choice that boards of hospital directors should make: Join a pilot program to pursue the financial incentives being offered by the federal government. Billions of dollars are being offered through the economic stimulus law (ARRA of 2009) to move physician offices and hospitals away from paper records to Electronic Health Records (EHRs). According to Advance for Imaging magazine, “It’s a fact that EHR systems save lives and money.” In the long run, choosing to have a certified EHR that meets certain criteria can earn healthcare providers millions of dollars. Therefore, it is integral for hospitals to adopt EHRs – not just for the federal incentives but for the overall quality of patient care.

Hospitals must use EHRs to improve quality and lower their operating costs. They must become more efficient and proactive with their healthcare IT (optimization of systems) – In fact, the government has made it clear that healthcare IT is a priority. If hospitals are able to change and adapt to the modifications being made volatile world of healthcare, they will be able to survive.