Readers Write 2/8/10
Submit your article of up to 500 words in length, subject to editing for clarity and brevity (please note: I run only original articles that have not appeared on any Web site or in any publication and I can’t use anything that looks like a commercial pitch). I’ll use a phony name for you unless you tell me otherwise. Thanks for sharing!
First Impressions of the iPad in Healthcare
By Trey Lauderdale
I don’t think we have ever seen a piece of technology as polarizing as the recently released Apple iPad. Being vice president of innovation at a healthcare-focused iPhone development company, I have received an unbelievable amount of feedback (some solicited, some not) on the good, the bad, and the ugly of the iPad’s potential uses in healthcare.
The first potential use models are the usual suspects we have all been hearing about for the last 3-6 months: entering data into the EMR, viewing medical images, observing patient data, managing alarms and alerts, etc, etc, etc. I could go on and on, but you already know all of these because they are available right now on your iPhone.
Don’t get me wrong — all of these functions are wonderful, but nothing here is really game-changing. I consider these the foundation of what is necessary to bring this device into healthcare in a useful manner.
In my opinion, the greatest impact this platform will have on healthcare is going to be from the creative juices squeezed out of the developer’s minds who will be writing applications specifically geared for the iPad and its potential use model.
You have got to look beyond version 1.0 of the iPad and into what it will become in the second, third, and onward generations of the device / platform. Apple tends to make significant improvements to their product between the first and second generation releases (2nd Gen iPhone >> 1st Gen iPhone). The limitations that have been brought up are all valid, but will be alleviated over time or through simple physical remedies.
It won’t survive in the hospital environment?
A robust, antimicrobial case will be out by the end of 2010 – it can almost be guaranteed.
No camera for image taking?
It will be there by Gen 2 (not for healthcare, but because consumers want it).
Too big to fit in a pocket?
The workflow model should not position this as an “always carried” device.
The one limitation that had me on the verge of throwing my MacBook across the office was the lack of background processing. While potentially the greatest shortcoming of the iPad, after some thought and analysis, it needs to be viewed as a mixed blessing. This device is going to have 1GHz of processing power focused on ONE application. The user experience in the currently open application is going to be amazing, assuming developers take time to re-factor their applications to fully leverage this “limitation.”
Through appropriate use of inter-app communication and data sharing, a great deal of the concerns brought on by no backgrounding can be bridged relatively easily. The key is going to be the foundational applications leveraging and creating open-source frameworks and standards that can be leveraged across multiple vendors in a collaborative environment.
The first day the iPad is released in March, all of the technology and applications are in place to enable a caregiver to view their patient’s vital monitoring waveform (Airstrip Technology), check the data against their EMR (Epic Haiku), and then send a quick message to an appropriate staff member asking them to take action on a potential event (Voalté).
While these currently reside as three separate applications, the experience provided to the end-user should not feel as such. The real power of the iPad (and even iPhone) platform is going to be a collaborative environment between the vendors that reside on the device. This collaboration will be of even greater importance with the iPad due to the greater amount of real estate the end user has to work with.
I can envision a hospital where an iPad is placed outside every hospital room displaying relevant information about the patient and their current vitals (REALLY decentralized monitoring). Clinicians grab the iPad as they enter the room, sign in with a quick series of hand gestures (or maybe take a quick picture of their ID?), and easily enter information into the open application regarding the patient’s current status. Messages and tasks can be dispatched to the right caregiver automatically from the iPad, and the clinician places the device back into the cradle once done with the patient. All of the pieces for this experience are currently in-place and ready to be tied together.
Apple has provided the revolutionary platform we could have only dreamed of 10 years ago. It is now our responsibility as application developers and IT system administrators to turn those dreams into reality and provide the end user experience our clinicians deserve.
Trey Lauderdale is vice president of innovation of Voalté of Sarasota, FL.
Interim is not Final
By Mountain Man
I don’t know about you, but my organization is asking a lot of questions about ARRA "now that it is finalized" and what we as an organization should do. Should we change our strategic plan?
With all the hype and media around this pseudo-event, we certainly have the the eyes and ears of our executive team and board members. We have somewhat of a bully pulpit. We should use the awareness created to advance our causes of bringing safety and efficiencies to healthcare delivery and financial visibility into the business. If we can tilt the spending towards an appropriate amount in order to complete our strategic plan, we should do so.
Here is the problem. “Interim” is defined by Wikipedia as “a temporary pause in a line of succession or event.” This does not sound very FINAL to me. So, Interim Final Rule really makes little sense.
Quit freaking out, people. NO ONE thinks we can hit the dates provided by the IFR. We should not reallocate all our resources to cover some part of the ARRA requirements that we left out of our strategic plans two years ago.
Most of us are working towards the general direction that the IFR is leading us. Keep doing what you are doing. Trust your plan and execute.
It is your STRATEGIC plan for a reason. Hitting an INTERIM suggested state is very TACTICAL and short-sighted.
If you are not headed in that general direction by now, then you should freak out.
They’re all Synonyms!
By Deborah Kohn
I don’t know how many times I delivered a presentation / authored a published article when I had to explain why two healthcare information technology (HIT) trade organizations (one so large that it won’t be mentioned in this article and the other, federally commissioned at taxpayer expense and no longer in existence) adopted definition differences between an electronic medical record (EMR) and an electronic health record (EHR).
This only further confused my healthcare professional audience / readership who, for years, have had a complete understanding that charts, records, patient charts, patient records, medical records, health records, etc. are synonyms! Walk into any hospital or clinician office and always one will hear an assortment of such synonyms without ever questioning the meanings.
True, in the late 20th century, synonyms of adjectives, such as computer, computerized, automated, or electronic were needed to differentiate between (what is known in the greater IT world as) analog vs. digital charts, records, patient charts, patient records, medical records, health records, etc. However, still the use of the synonyms of adjectives with the synonyms of nouns made no difference to practicing healthcare professionals, except to differentiate, when necessary, between analog, digital, or hybrid.
Thankfully, we might be getting close to ending this nonsense. Recently, one HIStalk reader correctly pointed out that NOWHERE in the 2009 American Recovery and Reinvestment Act (ARRA) with its Health Information Technology for Economic and Clinical Health (HITECH) Act is there a distinction made between an EMR and an EHR. Only the term electronic health record and acronym EHR is used — for health information exchanges, for hospitals, for physician offices. That’s probably because every healthcare industry-bred author / reader / interpreter of this legislation has a complete understanding of what is being conveyed.
On the floors or in clinic rooms, let’s continue to use whatever synonyms (adjectives and nouns) come to mind, because we’ll continue to understand what is being communicated. In addition, let’s give credit to the 2009 legislation for dealing one of the final blows to this “trade organization made up EHR/EMR” definition debate and all agree to use EHR (as used in the ARRA / HITECH legislation) as the standard terminology in presentations / published articles / vendor products, etc. Only then will we be able to move on to more important discussions.
Deborah Kohn is a principal with Dak Systems Consulting of San Mateo, CA.
Licensing of EHR Systems: Contractual Considerations
By Robert Doe, JD
As a result of the incentive payments offered under the HITECH Act for implementing certain qualifying EHR systems, many healthcare entities are evaluating the various EHR systems that are available, taking into account the certification, interoperability, and meaningful use requirements. There are a number of considerations a healthcare organization should take into account during the process of choosing and contracting with an EHR vendor.
A healthcare organization should consider including certain warranties and representations in the agreement with the EHR vendor to help ensure that the system is capable of allowing the healthcare organization to receive the incentives (and avoid future penalties) associated with the adoption of an EHR on an ongoing basis for the term of the license. As a drafter and negotiator of license agreements on behalf of healthcare organizations, while some vendors claim to do so, I have seen reluctance on the part of EHR vendors to meaningfully warranty their systems with regard to these considerations.
One argument is that the criteria for receiving the incentive payments have not been clearly defined. Future requirements, the argument goes, could conceivably require significant investment in new functionality. In addition, a vendor may argue that it has no control over how the system is actually used within the healthcare organization.
With regard to the first argument, EHR vendors are receiving significant new business as a result of the HITECH Act. If they cannot warrant the functionality which is one of the main motivating factors for licensing the particular system chosen, they are in effect transferring the entire risk to the healthcare organization, which, at a minimum, should be shared by the parties. For a significant capital expenditure of this nature, care should be taken to produce the result which justifies the expenditure. As a result, this should be one of the first discussions a healthcare organization should have with the EHR vendor during contract negotiations.
Some vendors may offer warranty language that appears to address the subject matter, but from a legal perspective, doesn’t actually provide much in the way of legal rights. Some vendors may propose that the issue be addressed as part of maintenance and support. Keep in mind that the legal remedies may be significantly less for a breach of maintenance and support as opposed to a breach of warranty. The warranty language could also be crafted to take into account the situation where significant additional investment is required for the system to conform to HITECH’s requirements, allocating an agreed upon portion of the expense to the existing customer base.
With regard to the second argument, it’s true the vendor has no control over how the system is actually used by the healthcare organization, but the warranty language can be worded to ensure the system includes the necessary functionality to allow the healthcare organization to qualify for incentive payments and avoid future penalties.
In addition, many healthcare organizations are endeavoring to provide access to their EHR systems to other unrelated healthcare organization in their communities, as part of a regional health information organization, health information exchange, or otherwise. The underlying goal of many of these arrangements is to provide EHR technology to other local healthcare facilities that may not be able to afford such systems by themselves. Such arrangements may also help to lesson the financial burden. Whatever the reason, there are legal and licensing issues to consider.
Any healthcare organization that desires to provide access to a software application to another unrelated healthcare entity or clinician must be aware of the physician self referral prohibition (Section 1877 of the Social Security Act) commonly known as the Stark law, the federal anti-kickback statute, and, depending on the data being exchanged, the Health Insurance Portability and Accountability Act, commonly known as HIPAA. In addition, significant anti-trust issues could arise if the software allows the sublicensees to share financial information. These additional legal issues must be addressed with legal counsel prior to setting up such an access arrangement.
In addition, the agreement with the EHR vendor must contain specific provisions allowing the healthcare organization to provide access to the unrelated healthcare organization. Do not assume that you can provide access by simply executing the EHR vendor’s standard form license agreement. All license agreements contain a license grant section that specifies the parties and individuals that can use the software. In most instances, it is limited to employees of the legal entity that signs the contract.
In addition, most license agreements specifically prohibit the use of the software to process information for, or use the software on the behalf of, any third party. The contractual language allowing the healthcare organization to provide access to an unrelated organization can take many forms. It may be as simple as expanding the definition of an authorized software user to include any other individuals authorized to use the software. Alternatively, the license grant may specifically state that the licensee may sublicense or provide access to the software application to a third party and set forth the conditions under which it can do so. There will also need to be an agreement between the two healthcare organizations governing access to and use of the EHR system. Careful consideration should be put into the drafting of this document. There are a number of issues that could arise if not addressed in this agreement.
The HITECH Act incentives have increased demand for EHR systems. Often times the timeframe for implementing such systems is quicker than would ordinarily be the case. It has been my experience that taking the time now to address the legal and business issues will help avoid problems in the future.
Bob Doe is a founding member of BSSD, an information technology law firm located in Minneapolis, MN.







I dont think anything will change until Dr Jayne and others take my approach of naming names, including how much…