The XY Files in an MT World : Health Information Technology

A 50-Dollar Saddle On A 5-Dollar Horse

Jay Vance — Thu, 12 Nov 2009 13:11:00 GMT

Back in May of 2009 I wrote a highly enthusiastic blog post entitled " Lessons From An iPhone ." It's with a great deal of disappointment and outright irritation that I now compose the sad sequel, which I could just have easily called "Lessons From A...(read more)

Update: More Details On MTIA/Verizon Health Information Exchange Project

Jay Vance — Wed, 04 Nov 2009 23:33:00 GMT

From a press release from MD-IT , one of the charter members of the Medical Transcription Service Consortium, with some interesting tidbits highlighted: The Medical Transcription Service Consortium (MTSC) – formed by ICSA Labs, an independent division...(read more)

Transcription Providers, Verizon To Create Health Information Exchange Infrastructure For Transcribed Medical Records

Jay Vance — Wed, 04 Nov 2009 17:26:00 GMT

In a move reported by Reuters and other sources, a newly formed industry group called the Medical Transcription Service Consortium has announced plans to create "a new IT platform for the secure exchange of digitized transcriptions of physician-dictated...(read more)

A Call for Plug-and-Play EHRs

Jay Vance — Fri, 22 May 2009 14:37:00 GMT

Nothing like great timing. In my last blog post, I suggested that electronic health record (EHR) and personal health record (PHR) technology needs to become more like an iPhone in order to achieve widespread acceptance from technology-shy physicians and...(read more)

Lessons from an iPhone

Jay Vance — Tue, 19 May 2009 12:33:00 GMT

I admit it, I was suffering from iPhone envy. As an unabashed technophile (i.e., hard-core geek), I couldn't help but be intrigued by all the cool things the iPhone was supposedly capable of doing. When one of your colleagues says something to the effect...(read more)

National Verbatim Transcription Day

Jay Vance — Mon, 04 May 2009 22:12:00 GMT

What do you suppose it would take for the health care field, not to mention politicians and the general public, to truly understand and appreciate the value medical transcriptionists bring to the healthcare documentation process? I've thought about this...(read more)

Beth Israel/Google Health Fiasco--Is Technology Really the Problem?

Jay Vance — Tue, 28 Apr 2009 11:55:00 GMT

Recently the Boston Globe has been reporting on problems arising when Beth Israel Deaconess Medical Center sent insurance claims data (i.e., billing codes) to Google Health PHR as a means of summarizing patients' medical condition. As it turned out, this...(read more)

HHS Provides Guidance on Protecting PHI

Jay Vance — Tue, 21 Apr 2009 12:24:00 GMT

When you see a document with a title such as Guidance Specifying the Technologies and Methodologies That Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals for Purposes of the Breach Notification Requirements...(read more)

“Reinvestment Is Not Just About Technology”

Jay Vance — Mon, 16 Mar 2009 20:03:00 GMT

The above is the title of a very insightful and thought-provoking blog post by Dr. Nick van Terheyden, Chief Medical Officer for M*Modal. He begins his article by quoting another blog post by Julian Alssid and Jonathan Leviss, who contend that investing...(read more)

Is Speech Rec Wrecked?

Jay Vance — Mon, 09 Mar 2009 17:25:00 GMT

In response to my fellow HIM Insider blogger Jeanne Johnston's post entitled "Speech Wreck," I'd like to offer my own perspective on the use of speech recognition technology (SRT) in medical transcription. I have a fair amount of experience with back-end SRT, both as a working editor and in a supervisory capacity in a production environment. Over the past few years I've also managed to collect a lot of anecdotal and statistical information about how SRT impacts working transcriptionists.

I will tell you up front that I've long been a vocal advocate for fairness in compensation for SRT editors, as well as a vocal critic of the way SRT is often marketed. I believe there is plenty of objective evidence to prove that a good speech recognition platform will pay for itself on the basis of increased productivity alone without having to reduce the net compensation for editors. By that I mean that if SRT provides a 50% increase in productivity in the number of lines, characters, etc. that can be produced by a given number of editors in a given period of time, significant savings will be realized even if the payroll for editors remains the same. For the same money, the editors are producing 50% more work in the same amount of time. That's a win for the institution any way you look at it. For this reason, I get very cranky when I hear that SRT is being used as an excuse to reduce compensation for editors to the point where they make less money in a given period of time. But to be honest, some of the blame for that kind of scenario has to rest on the shoulders of the editors who put up with that kind of unfair treatment.

In 2006 I put together a small-scale survey (202 respondents) of MTs who had been working as speech recognition editors for at least six months, to find out how SR was impacting productivity and compensation. The results showed the following:

- 28% of respondents found that editing SR took about the same amount of time it would have taken to keyboard manually, meaning no productivity gain overall.
- 32% saw a 25% increase in productivity compared to manual keyboarding
- 19% saw a 50% increase in productivity
- 10% saw a 75% increase in productivity
- 9% saw a 100% increase in productivity, i.e., double the amount of lines, characters, etc. in the same time period.
- 2% saw a greater than 100% increase in productivity.

What this tells us is that the largest bloc of SR editors--a total of 51% of respondents--saw an average increase in productivity of between 25% and 50%. This confirms the anecdotal information I had collected via informal conversations with MTs working as SR editors in a variety of situations on a variety of SRT platforms.

In the same survey, I asked respondents how their rate of compensation had changed as a result of working as editors compared to traditional transcriptionists. Here are those results:

- 31% received the same rate of compensation for editing as they had received for transcription
- 18% received a rate that was 25% less for editing as compared to transcription
- 9% received a rate that was 33% less
- 27% received a rate that was 50% less, i.e., half of the rate they received for transcription
- 9% received a rate that was 67% less
- 6% received a rate that was 75% less

My interpretation of these figures is that while there was no doubt a statistically significant number of editors whose reduced rate of compensation combined with a relatively small increase in productivity had resulted in a decrease in their overall compensation, that group did not by any means represent a majority of SR editors.

A third question I asked respondents was how satisfied overall they were working as SR editors as compared to transcribing. The results I found quite fascinating:

- 21% said they were very dissatisfied
- 22% said they were somewhat dissatisfied. These two categories totaled about 43%
- 31% said they were somewhat satisfied
- 26% said they were very satisfied. These two categories totaled 57%

At least based on the results of this admittedly small sampling of editors, there was not an overwhelmingly negative attitude toward using SR, and in fact a solid majority was either somewhat or very satisfied with their overall experience with SR.

The overall picture I get from the survey results as well as the anecdotal information I've come across is that there is a wide spectrum in terms of the impact of SRT on productivity, compensation, and overall satisfaction among MTs working as SR editors. Consequently, I don't believe there is enough objective evidence to conclude that speech recognition has proven to be a widespread disaster for the MT working class. As with any scenario involving people, technology, and money, mileage is going to vary widely. In my experience, there are simply too many factors that can influence productivity, compensation, and overall satisfaction with speech recognition technology to draw hard and fast conclusions about the impact SRT is having on working MTs on the whole.

Having said that, as long as ANY working MTs or SR editors are being taken advantage of, there will always be a need for advocacy for fair compensation. Nothing I have written here is intended to minimize the culpability of employers who treat employees unfairly. But again, by far the most effective advocacy for fair compensation consists of being willing to say "No" to substandard compensation. Until MTs and editors are willing take that stand en masse, there will always be someone willing to squeeze one more drop of blood from the stone.

HITECH Makes Business Associates Liable Under HIPAA

Jay Vance — Mon, 02 Mar 2009 16:14:00 GMT

Medical transcription providers should be educating themselves on how the Health Information Technology for Economic and Clinical Health Act (HITECH) portion of the American Recovery and Reinvestment Act of 2009, also known as the stimulus bill, is changing the way HIPAA regulations will apply to business associates. Up to this point, business associates of covered entities were not directly liable under HIPAA for breaches of private health information (PHI). As a result of HITECH, however, business associates, including transcription providers, will now be directly liable for failure to adhere to HIPAA regulations regarding the use of PHI.

According to Ed Jones from hipaa.com:

Application of the Security Rule to business associates of covered entities is a significant change. Previously, if there were a breach involving a business associate of which the covered entity were aware, then the covered entity could just terminate the contract if the breach was not remedied. Responsibility and liability rested with the covered entity. With the change in the HITECH privacy provisions of ARRA, the business associate now has responsibility and liability directly for a breach. A breach requires notification, which is triggered when there is an incident of "unsecured protected health information." The Secretary of HHS is required to issue guidance on what constitutes "unsecured protected health information" within 6o days of February 17, 2009. In the absence of such guidance in the time specified, then a default definition pertaining to a failure of encryption as endorsed by the National Institute of Standards and Technology (NIST) of such information [applies]. The notification provision requires both covered entities and business associates to notify affected parties directly and individually in a timely manner, and to use appropriate public media for cases involving over 500 individuals. This is a specification that was not defined under HIPAA Administrative Simplification. Increased penalties for a breach by a covered entity are immediately effective.

Writing for WTN News, attorney John Barlament explains further:

For the first time, business associates must comply directly with many of HIPAA's Security Rules. This will require every business associate to take several actions, including appointing a security official, developing written policies and procedures, and training its workforce on how to protect electronic protected health information ("EPHI"). These provisions go well beyond the previous requirements for business associates, where business associates only had to comply with the written business associate agreement.
Business associates also will need to follow HIPAA's Security Rules relating to physical safeguards (such as locking computers that contain EPHI), technical safeguards (such as encrypting emails) and the requirement to adopt written policies and procedures. Failing to do so will - for the first time - subject a business associate to civil monetary penalties and criminal penalties for each notification (and, as discussed below, the civil monetary penalties are now increased).

A covered entity or business associate that has a specified security breach will be required to notify each individual affected by the security breach. This can involve written notification by mail or, if specified by preference by the individual, email. If the covered entity or business associate lacks current contact information, it may be required to post notice of the breach on its website or in newspapers or other broadcast media (e.g., television). For certain large breaches (involving more than 500 residents in a particular area) a "prominent media outlet" must be notified of the breach. The U.S. Department of Health and Human Services ("HHS") also must be contacted, and HHS is to establish a website listing these breaches. There is an exception for certain unintentional breaches.

The Act states that business associates must comply directly with certain HIPAA Privacy Rules, primarily the requirement to have and follow a business associate agreement. The scope of this change is unclear. It could mean that every entity must determine whether it is a business associate with respect to a covered entity. If so, the business associate may be required to enter into a business associate agreement with the covered entity. Previously, it was a covered entity's responsibility to identify all its business associates (a business associate did not need to identify whether it actually was a business associate).

The civil monetary penalties are significantly increased. Currently, the amount of the penalty is generally $100 for each violation. This $100 amount (and its related cap of $25,000 for multiple violations) increases to $1,000 per violation for a violation due to "reasonable cause and not to willful neglect" (with a maximum penalty of $100,000); $10,000 for each violation that was due to willful neglect and is corrected (subject to a $250,000 maximum penalty); and $50,000 for each violation if the violation is not corrected properly (subject to a maximum penalty of $1,500,000 during a calendar year). These changes are immediately effective (i.e., they are in effect today) and represent a dramatic increase in the penalties under HIPAA.
In addition, state attorney generals can now bring a HIPAA enforcement action against a covered entity or business associate that violates these rules. Further, the state attorney general can obtain attorney's fees under such an action (although the attorney's fees are discretionary and not mandatory).
HHS - the main enforcer of HIPAA - now is required to conduct "periodic audits" to ensure that both business associates and covered entities are compliant with these new rules. Audits were possible under the old regulations. However, audits tended to be fairly rare, perhaps due to a lack of funding at HHS. Now, some monetary penalties or settlements collected by HHS are transferred to HHS's Office of Civil Rights to be used for purposes of enforcing HIPAA. This appears to solve the funding issue that HHS had apparently experienced. Thus, clients can expect to see increased HIPAA audits and enforcement.

So what does all this mean for the independent MT contractor and mom-and-pop transcription provider, not to mention regional and national MT service providers? While we don't yet know what the final HHS guidelines will look like, it seems clear to me that a whole boatload of new liability has just been dumped on MTs, whether we're ready for it or not. I'll be following the progress of the HHS rule-setting process with great interest, and will report back as new information becomes available.

Re-Dictation: Harnessing the Power of Front-End Speech Recognition Technology

Jay Vance — Mon, 23 Feb 2009 13:54:00 GMT

As all long-time transcriptionists know, years of high-level production transcription inevitably take a toll on the fingers and wrists. What many MTs may not know, however, is that modern consumer speech recognition technology (SRT) offers a possible alternative to all that keyboarding. I call this option "re-dictation," which is the process of using a front-end speech recognition (SR) application such as Dragon Naturally Speaking or Windows Speech Recognition to "re-dictate" transcripts rather than type them on a keyboard. It takes some getting used to, but I've personally found it to be a useful alternative when I want to give my hands a rest.

The technical requirements are not particularly complex. In addition to the SR software, I recommend using a PC headset with one earphone and a boom microphone. For me, at least, having one ear "open" to hear myself speaking while using the other ear to listen to the dictation works best, but your mileage may very. Once you have the hardware and software components assembled, you're ready to begin the re-dictation process.

If you're new to using front-end SRT, the first step will be to train the software to recognize your voice. Dragon Naturally Speaking, the program I use, has an extensive array of training tools available. The first step in training is to read aloud from prepared samples of text; later you can also add additional words to the application's vocabulary, either manually or by scanning documents on your hard drive, and then train the program by reading the new words aloud. Some versions of Dragon come with an extensive medical vocabulary included, but are quite a bit more expensive. I've had good success with off-the-shelf versions of the program and have not seen the need to spend the extra few hundred dollars to get the medical version.

Once you've gone through the initial training process, it's time to start re-dictating. The process is quite simple: you play a short snippet of the dictation file, stop playback, dictate that phrase into your headset microphone and watch the words appear on your computer monitor. As is the case whenever you use front-end speech recognition software, you'll need to make corrections from time to time. In many cases you can do this using voice commands, with little or no keyboarding.

As you get used to the re-dictation process, you may find you're able to "overlap" at times, that is, listen to the dictation and re-dictate at the same time.

The question often arises as to how re-dictation compares to keyboarding in terms of speed. For many high-speed typists, re-dictating will be slower, there's no question about it. But if it comes down to a choice between not working at all (or working in pain) versus working a little slower using SRT, re-dictation is an option not to be hastily overlooked.

An important caveat to using SRT, whether of the front-end or back-end variety, is that meticulous review of the words on the screen is a must. When you switch from keyboarding to speech recognition, it's amazing how easily your brain can be tricked into thinking your eyes are seeing something that really isn't there. Speech recognition is still an imperfect technology, and you can never assume that the program got everything right. Whether you edit your work in real time as you go, or re-read the entire document after you've finished, or both, using speech recognition makes careful review even more critical to accurate transcription.

For many years, speech recognition technology has been a boogey man to many MTs, a mysterious force to be feared and resisted. Re-dictation is an example of harnessing the power of this technology to work for us, not against us.

Bits & Pieces

Jay Vance — Tue, 17 Feb 2009 20:10:00 GMT

Here are a few items of information from the past week I thought you might be interested in.

1. Transcription Service Provider Runs Afoul of the VA

From a Department of Veterans Affairs press release: During a routine internal inspection, the Department of Veterans Affairs (VA) discovered a contractor providing medical transcription services who was not following the Department's rules for protecting medical information.

Although there is no evidence that any patient information was disclosed as a result of the violation, VA has suspended the contractor from receiving any sensitive information from the Department until the contractor guarantees compliance with VA's standards for information technology (IT) security.

"VA insists that contractors, as well as our own personnel, adhere to the highest standards for protecting personal information," said Secretary of Veterans Affairs Eric K. Shinseki. "When we detect a problem, as happened in this case, we will quickly fix it, and we will ensure such problems are not happening elsewhere."

The issue involves a contractor whose employees create written transcripts of recordings made by health care professionals while performing physical examinations, reporting on surgeries, and taking patients' histories. VA officials found the contractor's employees used computers that do not adhere to government policy on security.

Based on this incident, the Secretary has launched an intensive examination of all VA's contracts to ensure all contractors properly safeguard information about VA patients, Veterans and employees.

2. New PHR Requirements in Stimulus Bill

Health Data Management is reporting that the economic stimulus bill will impose new consumer protection requirements on vendors of personal health records.

The vendors must notify affected individuals following the discovery of a breach of unsecured identifiable health information in PHRs. Vendors also must notify the Federal Trade Commission.

Further, a third-party service provider that provides services to a PHR vendor or covered entities that offer PHRs must notify affected vendors or entities of a breach. "Such notice shall include the identification of each individual whose unsecured PHR identifiable health information has been, or is reasonably believed to have been, accessed, acquired or disclosed during such breach," according to the legislation.

The FTC shall treat violations as unfair and deceptive acts or practices under the Federal Trade Commission Act. The legislation requires the FTC to publish interim final regulations within 180 days of enactment.

The requirements will remain in effect unless Congress enacts new legislation governing PHR breach notifications.

3. Medpedia Opens Public Health Care Technology Platform

TechCrunch is reporting that Medpedia has unveiled a public version of its technology platform for the worldwide health community. Combining social networking with Web 2.0 health information, Medpedia's website offers consumers a Wikipedia for health information, a LinkedIn network for health professionals, and a Facebook-like platform where consumers and experts can have a medical dialogue about treatment and conditions.

Medpedia has developed partnerships with Harvard Medical School, Stanford School of Medicine, Berkeley School of Public Health, University of Michigan Medical School and other health organizations to help bring content and medical networks to the site. Many of the health institutions are offering the content free of copyright restrictions. Already, 25 medical and government institutions in both the U.S. and the U.K. have signed on to Medpedia to use its professional network.

4. U.S. Army Adopting Dragon Speech Recognition

According to FierceHealthIT, the U.S. Army Medical Department is adopting speech recognition technology in a big way as part of an effort to boost its clinicians' satisfaction with the military's electronic medical record system. The new system will allow physicians to speak their notes into the EMR at the patient's bedside, rather than enter them later when their memories aren't as fresh.

The Army is rolling out Dragon Medical speech recognition software to 90,000 clinicians worldwide. It's taking this step as part of a larger program, run by the U.S. Army Surgeon General, designed to help improve providers' experience with AHLTA, the military's EMR. The program, MEDCOM AHLTA Provider Satisfaction, has already invested in touch-screen laptop computers and wireless networks.

A Major Step Forward for PHRs

Jay Vance — Wed, 19 Nov 2008 16:27:00 GMT

On November 12, acting CMS administrator Kerry Weems and HHS Secretary Michael Leavitt announced a pilot program which will enable Medicare members in Arizona and Utah to use their choice of four commercial personal health record (PHR) providers to access their own data from CMS databases. Beginning in early 2009, beneficiaries with Original Medicare will be able to use Google Health, HealthTrio, NoMoreClipboard.com, or PassportMD to maintain a PHR which will include Medicare information from CMS.

Said HHS Secretary Mike Leavitt, "This pilot is a major step forward for Medicare. It will provide information and tools that will empower consumers to manage their health better. Importantly, the pilot provides beneficiaries with a choice of products to meet their individual needs."

What I find remarkable about this new endeavor is that CMS, by all accounts a fairly conservative entity when it comes to sharing its data and embracing new technologies, is actually going to allow both consumers and third-party service providers to access personal health information (PHI) of Medicare beneficiaries. It's hard to see this move as anything less than an explicit endorsement of a "Health 2.0" infrastructure in general and of the concept of PHRs in particular. It would also, evidently, signify that CMS has accepted the HTTPS Internet transmission protocol as secure enough for PHI. From what I hear, in the past CMS has been loathe to allow the transmission of PHI data to or from its databases via the Internet.

CMS funds more than half of the healthcare in the U.S., and isn't shy about attempting to drive adoption and change through its reimbursement policy. I will be very curious to see whether or not, by offering patients access to their own claims data, CMS will create patient expectation that will motivate the private payer community to do the same. It will also be interesting to see what effect this move will have on adoption of PHRs by consumers. Again, it's hard not to see this as a golden opportunity for MTs and others in the health care documentation arena to jump on this bandwagon by providing value-added services to help consumers establish and maintain their own PHRs. CMS and major online players such as Google Health have already done a lot of the marketing work for us with this new initiative.

Society For Exorbitantly Expensive And Difficult To Implement EHRs (SEEDIE)

Jay Vance — Mon, 10 Nov 2008 16:58:00 GMT

Someone alerted me to this spoof website and I got a big kick out of it. It's a great followup to my last post regarding implementing an electronic health records (EHR) system in this country.

From the website's "SEEDIEspeak" page:

SEEDIE invites industry insiders to provide commentary on the value of certification on our blog. The following post is from Brantley Whittington, CEO of EHR vendor Extormity.

Much is made these days in healthcare IT circles about interoperability. This so-called "holy grail" has lulled many into believing that EHR systems should be able to easily and inexpensively exchange data using standard communication protocols.

Our company, Extormity, sells a suite of EMR software solutions, and we can't keep all the acronyms straight! I can't explain the difference between an HL7, a CCR and an XPHR, and I do this for a living! In fact, we tried to participate in some interoperability exhibitions at a few conferences, and we couldn't make our systems talk with those from other vendors. We also took a look at CCHITSM Certification, and quickly realized there was no way we could meet 263 criteria in 40 some categories. We're all for certification, but what's wrong with setting the bar low? Why does CCHIT have to make certification so rigorous?

We threw up our hands and decided to work with other like minded vendors to start our own organization - SEEDIE. This "take our ball and go home" approach puts the power where it belongs - in the hands of a few very large, very profitable companies who know how to build the complex, proprietary systems required to turn the EHR space into a multi-billion dollar market in a short period of time.

Is interoperability a pipe dream? Absolutely not.

Is interoperability expensive? We think it should be! We believe that true interoperability requires organizational will and a tremendous amount of money from customers to fund it. Given enough in custom integration fees, we can build an interface that will allow our EMR to exchange clinical data with a toaster oven. It all boils down to dollars and desire.

EHR vendors who tout plug and play interoperability are eroding the potential value of the healthcare IT market. Look for the SEEDIE seal when you select an EHR partner, and you will know with confidence that your added investment will support aggressive industry growth forecasts.

Whoever the author of this website is, I absolutely agree with him or her that we're making the whole EHR compatibility/interoperability issue much more complicated than it has to be. If we're really serious about cutting costs in health care, rejecting expensive proprietary systems in favor of open-source software and established file formats would be a logical place to start.