Nuesoft Website  |  Blog Home  |  Contact Information

In a recent post by John Lynn on the EMR and HIPAA blog, he broached the subject of off-site backup services, and suggested some solutions for medical practices that need a way to back up their patient data.

Nuesoft has nothing but respect for Lynn and the EMR and HIPAA blog, but we can’t help but feel that this post missed the mark a bit. Rather than encouraging medical practices to look for quick and easy fixes to the pesky backup problem, why not remove backups from the health information technology dialogue? Data backups are a by-product of client server technologies of the 1990s. To truly reach the level of widespread health information technology adoption that the government is envisioning, then we need to look toward more modern and viable HIT solutions.

Most EMR solutions installed in medical practices are client server models. While users of some of these client server systems may opt for a backup solution like those described in Lynn’s blog, the vast majority will handle backups themselves. Let’s be realistic – how many doctors have the time or the expertise to adequately replicate data and ensure that it is completely secure (and HIPAA compliant) and fault tolerant? To do so requires a practice’s main server and its database to be replicated via a back up server within the same network, or connected via a wide area network, and then monitored constantly. The answer is, most doctors aren’t equipped or staffed to handle back ups, and the result is that the back ups just won’t get done – or at least not to a level that is adequate or truly secure.

Nuesoft wonders, in this push for broad EHR adoption, why aren’t more people concerned about the fault tolerance issue and discussing it openly? EHRs are truly mission critical applications. Timely access to information by a provider can have life or death consequences. Consider this: there are 161,200 medical practices in the United States. If we assume that a conservative 45 percent of these practices adopt a client server EMR under HITECH, and that a mere 1 percent of those EHR systems go down and leave users without access to patient data, think of the number of practices – and patients — that would be impacted! Providers would be without access to patient charts, and would lack the ability to review drug allergy or interaction information, medical history, or other critical components of the patient record.

This is a frightening – albeit realistic picture of the potential risk that client server models, with their many shortcomings, pose to the health care system. It’s time to stop talking about ways to help physicians compensate for client server technologies, and embrace emerging technology models such as Software as a Service (SaaS), or cloud computing, which are better suited to a mission critical environment. Even in the event that a SaaS program is temporarily unavailable, the data is safe, whereas with a client server scenario the loss is more often than not a permanent loss and the downtimes are much lengthier. The HITECH Act gives us the perfect opportunity to usher in new technologies like SaaS that will expand interoperability and relegate legacy technologies to a thing of the past.

Today marks the start date for many of the new HIPAA rules that were propagated as part of the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009. The revised rules include a new public/media relations component, updated restrictions and provisions for accounting and disclosures of protected health information, and increased civil and criminal penalties for violators.

HIPAA previously applied only to covered entities (i.e. health care providers, health insurance companies and clearinghouses). One of the biggest changes under the HITECH rules is that business associates, or third party service providers that handle PHI of covered entities, must now comply directly with HIPAA, and will be held liable for security breaches of patient files or information stored in their systems.

In general, the revisions give HIPAA “sharper teeth,” with stiffer penalties for violators and mandatory audits by the Department of Health and Human Services (HHS). Penalties now range from $100 to $50,000 per violation, with a maximum in any one year ranging from $25,000 to $1.5 million. The new law requires HHS to investigate complaints, impose penalties for willful neglect and conduct periodic audits of both covered entities and business associates to ensure they are in compliance with the rules.

For more tips on how your practice or company can remain in compliance review Nuesoft’s HIPAA fact sheet, and tune in on March 1 to our HIPAA podcast. Visit the Nuesoft Web site for details.

The “red flags” rule is now scheduled to take effect on June 1, 2010, after another delay announced earlier this week by the Federal Trade Commission as it considers new legislation that would exempt small businesses, including medical practices, from compliance. The rule mandates the creation of identity theft prevention programs, and will apply to any organization that can be considered a creditor with “covered” accounts (i.e.-commercial accounts that involve multiple transactions). Most providers, many medical billing companies and some health plans are expected to comply.

The American Medical Association, American Academy of Family Physicians and other industry groups have weighed in against the rule, on the basis that physicians do not meet the definition of creditors. A completely sensible argument. But medical practices need to proactively engage in some agreed-upon set of identity theft prevention practices. It’s in the best interest of consumers, not to mention practice owners, who’ll otherwise pay the price through legal costs, or through the provision of services for which they would never collect payment. Incidences of medical identity theft are increasing – enough to raise the gander of the government, which commissioned a study to assess and evaluate the scope of the problem. And smaller medical practices (which account for nearly 80 percent  of all U.S. practices) may be more vulnerable, as thieves could perceive them to be lower risk targets based on the assumption that they lack the sophisticated security procedures of hospitals or larger health care organizations.

Despite the widespread outcry from industry groups, the actual impact on a practice for complying with the red flags rule may be minimal. The new rule would simply buttress state privacy laws that already require health care organizations to respond to breaches of certain patient information. In addition, there is a great deal of overlap between the proposed FTC regulations and HIPAA, which applies to medical practices or other entities that are conducting electronic transactions.

Medical practices concerned about compliance can learn more at: http://www.ftc.gov/bcp/edu/pubs/articles/art11.shtm or http://www.ama-assn.org/ama1/pub/upload/mm/368/red-flags-rule-edu.pdf.

Privacy and security concerns are one of the many hurdles that the health care industry needs to overcome before EHR adoption catches on properly. Unfortunately, the sensible goal of making electronic health record systems interoperable (itself a complex task due to the huge variety of software solutions currently on the market) adds to these security headaches, because systems have differing levels and types of security, and security breaches in one system could, in an interoperable world, be even more serious and potentially compromise the whole nation’s records.

HIPAA (The Health Insurance Portability and Accountability Act) goes a long way to address many privacy and security concerns, but it leaves some important holes, which the Health IT Standards committee is currently seeking to address. Today, it endorsed a set of standards covering a range of security and privacy factors from access control and authentication to data integrity and document exchange. The full list of recommendations can be found here.

The idea is that these regulations are setting baselines that can be improved upon over the next few years, thus walking the fine line between being so stringent that they prevent development of compliant EHRs and hamper adoption, and yet still preventing widespread security breaches. For example, Kerberos/EUA authentication will not be allowed after 2011. This type of authentication is flawed because all users’ secret keys are stored on a central server, meaning a compromise of that one server will compromise all users. The reason it is allowed until 2011 is because some systems don’t even have enterprise-user authentication set up at the moment.

This prompts the obvious concern that hackers won’t do the sporting thing and wait till security is ramped up several years from now before trying to hack into systems. There are systems out there right now that contain patient data that are simply not secure, even by basic standards.

All of this rather worrying information provides a compelling argument that the industry should move away from the client-server model where physician practices are keeping patient information and charts on a server in the back room, to one in which technology professionals whose very job is to keep massive amounts of data safe are managing it all “in the cloud”.

Such technology companies – including Nuesoft – are likely to have security and privacy guidelines far in excess of what is mandated, because they have far more at stake in the event of a security breach. For a more technical discussion of what the HITSP standards mean and whether they are sufficient, you can read this balanced post written by a member of the HIT Standards Privacy and Security Committee.

Privacy and security concerns are one of the many hurdles that the health care industry needs to overcome before EHR adoption catches on properly. Unfortunately, the sensible goal of making electronic health record systems interoperable (itself a complex task due to the huge variety of software solutions currently on the market) adds to these security headaches, because systems have differing levels and types of security, and security breaches in one system could, in an interoperable world, be even more serious and potentially compromise the whole nation’s records.

HIPAA (The Health Insurance Portability and Accountability Act) goes a long way to address many privacy and security concerns, but it leaves some important holes, which the Health IT Standards committee is currently seeking to address. Today, it endorsed a set of standards covering a range of security and privacy factors from access control and authentication to data integrity and document exchange. The full recommendations can be found here.

The idea is that these regulations are setting baselines that can be improved upon over the next few years, thus walking the fine line between being so stringent that they prevent development of compliant EHRs and hamper adoption, and yet still preventing widespread security breaches. For example, Kerberos/EUA authentication will not be allowed after 2011.

This type of authentication is flawed because all users’ secret keys are stored on a central server, meaning a compromise of that one server will compromise all users. The reason it is allowed until 2011 is because some systems don’t even have enterprise-user authentication set up at the moment.

This prompts the obvious concern that hackers won’t do the sporting thing and wait till security is ramped up several years from now before trying to hack into systems. There are systems out there right now that contain patient data that are simply not secure, even by basic standards.

All of this rather worrying information provides a compelling argument that the industry should move away from the client-server model where physician practices are keeping patient information and charts on a server in the back room, to one in which technology professionals whose very job is to keep massive amounts of data safe are managing it all “in the cloud”.

Such technology companies – including Nuesoft – are likely to have security and privacy guidelines far in excess of what is mandated, because they have far more at stake in the event of a security breach. For a more technical discussion of what the HITSP standards mean and whether they are sufficient, you can read this balanced post written by a member of the HIT Standards Privacy and Security Committee.

There has recently been a spate of items in the news about breaches in the privacy of patient information. It seems that electronic records, while transforming the accessibility (not to mention legibility) of patient information, have also presented a new set of security headaches for practices and hospitals alike. It’s therefore essential for those health professionals considering automation or upgrading an old system to shop around for HIPAA-compliant practice management software that has advanced security measures, not only to protect patients from the mishandling of their identity and personal information, but also to protect physicians or their practices from litigation.

Tools to look out for include user-defined permissions, which allow administrators to give users different levels of access to data, and audit trails, which produce a permanent record of which authorized users accessed a patient’s chart at what time. Additionally, some application service provider (ASP) models feature better protection from hackers than others – those that are Internet-based (as opposed to Web-based) create a private platform between you and your data rather than channeling it through the very public forum of the World Wide Web.

 Technology can be misused and abused, but it can also be implemented as an effective tool to safeguard information privacy. Making sure your medical management system is secure will help prevent future lawsuits against you or your practice.

Most people that have objections to Internet-based software applications usually cite a lack of security as the reason. Particularly when it comes to applications that deal with protected health information (PHI), even some technology-savvy professionals feel safer if they have the server on-site under their control, with data only being transmitted on an internal network.

This feeling of security is, for the most part, illusory. Client servers located in offices or institutions rarely have the same level of security that ASPs are able to afford their servers due to economies of scale. Plus, having your server on-site means that you are responsible for maintaining it. Not only does this require extra resources, but it can be problematic if there’s a disaster – your on-site server is vulnerable to floods, tornadoes and fires in a way that good ASP servers are not, because they are usually situated at several diverse locations with data replicated across them. If a disaster befalls one of them, the other ones are still safe and so is your data.

Additionally, having to make your own data backups provides another opportunity for a security breach, as the University of Utah Hospitals & Clinics found out recently, when the backup tapes with medical billing information for 2.2 million patients went missing from a courier’s car. They could have taken a leaf out of the book of the university’s student health center, which unlike the hospitals and clinics division uses Nuesoft Xpress, an ASP model medical management and billing system, meaning their data remains secure and HIPAA compliant without university staff worrying about maintenance, backups or disasters.

The Health Information Portability and Accountability Act (HIPAA) of 1996 requires a unique National Provider Identifier (NPI) for each physician, supplier or other provider of health care services. To comply with this Federal mandate, all claims must be filed with NPI numbers beginning May 23, 2008.

Nuesoft Technologies has placed edits in the system to prevent claims without NPI numbers from being transmitted. In order to comply with the new standards, we are asking our clients to do the following:

1. Have NPI numbers on all claims submitted – claims will be rejected if the NPI number is missing.
2. Send only a few claims for each payer on May 23, 2008 to ensure your claim is accepted.
3. Report any payer-specific issues to NueMD Support immediately.

If your practice does not already have an NPI, you will need to get one as soon as possible. 

Failure to obtain an NPI will adversely affect your ability to successfully file claims.

To learn more, or to apply for your NPI.