Buy a package from a vendor to display clinical data on the iPhone.
Build a Web-based or native iPhone application.
The first option is the most common approach. Benefit: no development costs. Disadvantage: limited ability to customize the application to an organization's specific needs.
Sign on with four-digit PIN using large numeric virtual keypad (see image) versus entering username and password on the iPhone virtual keyboard.
Lab data displayed as three most recent values in a simple table (see image). Lab tests grouped using common categories.
Select and play a radiology dictation when viewing a patient's record.
Rounding list defined and built to physician specification. Physicians can add and delete physicians in their group using the iPhone.
Length-of-stay information from our Case Management and Bed Tracking application, also written in-house.
It's the subtle features that make the difference in user acceptance of software. This is especially true in healthcare for reasons too numerous to list here.
For example, physicians don't like entering their username and password on the iPhone's virtual keyboard, an approach many vendors use. Using the virtual keyboard takes a certain touch that is difficult for some physicians to master. We built a security feature that ties a specific iPhone to a specific physician to a specific PIN they choose. The PIN is only valid on the physician's iPhone and is entered using a large, virtual numeric keypad that mimics an ATM. Users need only enter their four-digit PIN to log in.
The ability to ask physicians, "How would you like it to work?" versus "This is how it works" makes the difference between good software and software that physicians accept. This can best be accomplished by building the front end custom to your needs. While building software is harder and more difficult (for IT personnel) than buying vendor software, the ability to build initiative, easy-to-use software makes training, implementation, and support much easier. And the extra effort makes it much easier for the user to incorporate into their work.
It really is that simple. And why "generic" software requires much more training and process redesign than custom software. Another advantage of build versus buy is we can continue to deliver applications without being dependent on available capital dollars.
Future plans include using the iPhone with the Web app to record dictations and use of the iPhone for eMAR.
Mark Moffitt is director of information systems at Good Shepherd Medical Center of Longview, TX, proof that you don't have to live in a big city to innovate in healthcare IT.
I thank the members of the Health Information Technology Policy Committee and, in particular, the members of the Meaningful Use Work Group for their time and effort. I would like to provide my own comments upon the draft presentation of Meaningful Use.
I think that it will be very difficult for all ambulatory and acute care provider organizations to implement an EHR by 2011 simply because of ramp-up time and change management considerations. It takes time for an organization not only to put together an implementation team, but to ensure that the appropriate governance structure is in place. The organization must also formulate a clear focus of where it wants to go, a plan for how it's going to get there, and how it can assess its progress in getting there.
The organization must identity the members of the implementation team. Often, the organization must recruit additional personnel or retain consultants. In addition, there is training to take into consideration. Equipment must be ordered. Appropriate telecommunications must be in place. Interfaces must be implemented. In addition, simultaneous implementations of ambulatory and acute applications by a delivery system can be onerous, yet a certain amount of collaboration is necessary to promote maximum utility.
Vendors will have constraints as well. Many vendors are running very lean implementation organizations today; this minimizes the number of implementations that any one vendor can support at a time. It's no different than any other manufacturing environment; there are capacity limitations. Moreover, any rapid implementation cycle provided by a vendor should be carefully evaluated to ensure that the needs of various provider and patient populations are being adequately met.
It's one thing to provide content satisfying a general med/surg model, quite another to meet the needs of a pediatric BMT program. Rapid provider adoption of workflows and clinical documentation applications will be effected if provider needs are considered during the initial build of content and workflows. Workflows should be designed to meet the particular needs of the provider, e.g., a diabetes clinic or a nephrology clinic. Such consideration can minimize costly re-engineering at a later point and contribute to the success of an implementation.
Reflect the maturity of any particular implementation, for instance, if evidence-based order sets comes two years after CPOE implementation, then the criterion should reflect the stage of a particular implementation and not simply a calendar year.
CDS at the point-of-care is somewhat ambiguous and restrictive. Are we referring only to those kinds of CDS that present during CPOE or are we also considering alerts which reflect changes in patient conditions and availability of new data to alert a provider and inform a decision?
Meaningful Use calls for the capture of clinical data that can be queried and trended. I can appreciate the issue of data capture with which the Work Group has contended; however, I feel that the objectives have minimized the value of these data and other data for data warehousing and analysis as well as for interoperability through such mechanisms as ELINCS. Hence, such data should utilize standard classification systems such as LOINC, SNOMED, and ICD-10CM to support data warehousing and analysis. Such requirements should be clearly called out so that provider organizations and vendors will incorporate this into their project plans.Such classifications are essential and often mandatory for reporting to quality, epidemiological and public health agencies and to various registries. Meaningful Use should clearly call this out.
Moreover, there is far more information within a patient chart that could be subject to further structure and encoding. The use of standard classification systems or languages should be implemented so there is a consensual, meaningful and useful framework which governments, providers and consumers can use as a common language.Internationally endorsed classifications facilitate the storage, retrieval, analysis, and interpretation of data. They also permit the comparison of data within populations over time and between populations at the same point in time as well as the compilation of nationally consistent data. (http://www.who.int/classifications/en/) It appears to me that CCHIT and vendor organizations have avoided the issue of incorporating standard classifications or the usage of common classification languages.
Our goal should be to maximize the value we obtain by automating CPOE, clinical documentation, and result reporting.
Order sets are often viewed as provider productivity tools and are conducive to provider adoption of CPOE. Considerable effort is entailed in adopting and implementing evidenced-based order sets. The effort to implement an organization's existing order sets only to be followed within two years by the adoption of evidenced based order sets is considerable.Perhaps such adoption should be moved up in the timetable.Reimbursements and grants should reflect the licensing cost of evidenced-based order sets. Available evidenced-based order sets tend to focus on medications; however, standard classifications would encourage incorporation of evidenced-based data for other procedures such as radiology and laboratory.
Multi-media support capabilities are existent in many commercially available EHRs. Perhaps this objective could be moved to an earlier year.
The Meaningful Use Matrix calls for the use of bar coding in medication administration, yet it does not call for the bar coding in the administration of blood products or for positive identification of patients on whom procedures are to be performed, e.g., specimen collection. While CCHIT addresses medication administration in its category Decision Support for Medication, Immunization, and Blood Products Administration requirements, there is no mention of similar functionality for blood product administration, etc. It's important that Meaningful Use expand beyond current CCHIT requirements and vendor offerings.
CDS for administration of immunizations and blood products and positive patient identification as mentioned previously.
Reduction of labor costs in collecting specimens and increasing patient satisfaction by reducing needle sticks when a central line is available.
Improved patient satisfaction when the provider has the patient's information at the right time and place.
Improved transfer of information between providers.
I apologize if any of my comments have been redundant or because of my failure to notice their having been addressed elsewhere.
Arlen Dominek is practice director at Peer Consulting of Mercer Island, WA.
Regarding the SubroShare(R) press release, Mr. HIStalk was understandably a little off in his assessment; this is not about a policyholder suing the healthcare provider. It is all about personal injury claims.
Subrogation is a legal remedy that enables an insurance company to recover amounts it paid for the care of its customer (the injured patient) in situations where the patient also receives payment covering the same services from a third party (the one that caused the injury to the patient and was sued by the patient).
The key here is the third party. There must be some other party that caused the injury to the patient and from which there is the possibility of payment resulting from a lawsuit (damages) or settlement of that lawsuit.
I will go out on a limb and state that I cannot imagine any health insurance policy not having a subrogation clause. Whether or not attorneys have an obligation to inform the insurance carrier of secondary (duplicate) payments is irrelevant, because where there is a subrogation clause, there is also the obligation for the insured patient to inform the insurance company that the patient's injuries were caused by a third party, thereby raising the flag for the insurance company.
That said, unfortunately there are those patients that do not, and processes are not always what they should be and some claims "fall through the cracks" and are not identified properly up front. Consequently insurance companies are left to hunt down reimbursement in these situations.
What I believe SubroShare(R) offers is a method to assist insurance companies in identifying situations where they may recover, through subrogation, some payments made on a patient's behalf. The trigger seems to be the request for the patient's records by an attorney, which might mean third party involvement in the patient's injury, and consequently might mean the possibility of payment to the patient directly for services already paid by the patient's insurance company.
William O'Toole is founder of O'Toole Law Group, Duxbury, MA.
I watched with sardonic amusement as a whopping 19% of readers voted that healthcare providers are sandbagging on IT to keep the public from seeing how profitable healthcare delivery is. Really? 19% of people who read this site think that patient care plays second fiddle to profitability when it comes to EHRs?
Do you believe that profitability (here defined as free market economics) enhances or threatens the quality of healthcare received by the general public?
Do you believe that healthcare providers are have a vested interest in keeping the public from seeing how profitable healthcare delivery is?
There are lots of trick questions like these, but the answer is always both 'yes' and 'no'.
The simple truth is that a dying person will usually give their last dime for a shot at one more day. Healthcare in these circumstance is every man for himself. If you are sick or dying, you're not going to mind that the person in the bed next to you is subsidizing your stay at a rate of $100 per tablet for over the counter drugs or 33% year in income taxes. Profitability can be created by reducing costs as easily as by increasing sales, but in these circumstances, money doesn't mean much.
Do you really think that there aren't people profiting in healthcare from deals that they'd rather the public not know about? (Thank god we have people like Mr H to keep us up to date on the salaries of major 'non-profit' executives). But why stop there? What about those doctors with lucrative research deals with pharmaceutical companies, or pharmaceutical companies who perk doctors who use their products?
Now I have no idea if such profiteers are going to be exposed by EHRs. Indeed, it seems EHRs can be their own unique breed of profiteering. But let's be honest, we all know people who profit from healthcare, and no matter what happens next, single payer, socialized medicine, co-ops, EHRs, RHIOs, status quo, bankruptcy of Medicare, etc., there will always be people profiting from healthcare.
The real question is: is it fair? And it is this question, no matter how simply stated, that we can't possibly come to agreement on. So we'll let the market decide for us. I bid 10% of my salary. And rising.
iPhone app credit for software design and development goes to Kevin Hornberger and Chris Reed at GSMC; Ron Short for being our bridge to physicians; and Ed Banos for supporting the team.
Mark, if you can give out this info, how much did it cost and how long did it take to develop the iPhone app?
Mark: Thank you for the description of your iPhone experience. Your 4-number pin entry is simple and effective (10-factorial?), and I love hearing such software success stories. In-house design and development can work well, and you've certainly proved it.
What an irony that vendor pre-packaged software initally came about because of huge cost savings and perceived expert support. I do believe this formula inverted long ago.
Mark, any chance you guys would open source the code to that iPhone software?
To answer that question I need to provide a little more detail on the EMR infrastructure we are using.
We use Meditech Magic. We've had it for years and it does a good job as a "transaction processor" such as billing, medication management, reporting, etc. The user interface is very old technology.
We also use Meditech as a data store and do not duplicate data outside of Meditech unless required, usually due to performance issues. So we built web services as our plumbing to get data from Meditech when required, such as patient demographics, meds, etc.
The iPhone web app for rounding list, meds, radiology dictation, PIN sign-on took about 3 months. Adding lab took another 3 months. That includes building the web services. All of these features where developed, tested, "piloted" with a small group of physicians, and then rolled-out into production in about 6 months. We continue to add features and functionality. We are reusing the web services plumbing and lab data store to build a desktop web app. That effort will take about 2 months (in progress).
Two developers working full time for 6 months was the main cost, plus some hardware and interface tools. However, we avoided the cost of purchasing software from a vendor plus annual maintenance fees. And we continue to add new features based on feedback from physicians.
* Spend less money on vendor solutions means more hardware and tools in the hands of users – iPhone, iPod/touch, tablets, notebooks, etc.
To avoid confusion I will use my name versus my alter ego: Unfrozen Caveman CIO. Sorry about that!
Long and hard deliberation allowed me to conclude that your authentication meets two-factor authentication requirements. I was curious about the lab data since its presentation is always problematic; your additional edification was helpful. How is data encryption or security addressed between server and iPhone?
Anyone running the iPhone 3GS? Very, very fast!