Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Adverse Event Reporting and EHRs: The MEDTECH Act’s Effects

Posted on December 18, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

Medical systems generate adverse event (AE) reports to improve service delivery and public safety.

As I described in my first blog post on Adverse Events, these reports are both a record of what went wrong and a rich source for improving workflow, process and policy. They can nail responsibility not only for bad acts, but also bad actors and can help distinguish between the two. The FDA gathers AE reports to look for important health related patterns, and if needed to trigger recalls, modifications and public alerts.

EHRs generate AEs, but the FDA doesn’t require reporting them. Reporting is only for medical devices defined by the FDA and EHRs aren’t. However, users sometimes report EHR related AEs. Now, there’s proposed legislation that would preclude EHRs as medical devices and stop any consideration of EHR reports.

MEDTECH Act’s Impact

EHRs are benign software systems that need minimal oversight. At least that’s what MEDTECH Act’s congressional sponsors, Senators Orrin Hatch (R- Utah) and Michael Bennett (D- Colorado) think. If they have their way – and much of the EHR industry hopes so – the FDA can forget regulating EHRs and tracking any EHR related AEs.

EHRs and Adverse Events

Currently, if you ask MAUD, the FDA’s device, adverse event tracking system about EHRs, you don’t get much, as you might expect. Up to October, MAUD has 320,000 AEs. Of these about 30 mention an EHR in passing. (There may be many more, but you can’t search for phrases such as “electronic health,” etc.) While the FDA hasn’t defined EHRs as a device, vendors are afraid it may. Their fear is based on this part of the FDA’s device definition standard:

[A]n instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

…[I]ntended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals…

I think this section clearly covers EHRs. They are intended for diagnostic, cure, mitigation, etc., of disease. Consistent public policy in general and a regard for protecting the public’s health, I think, augers for mandatory reporting of EHR caused AEs.

Why then aren’t EHRs devices that require AE reporting? In a word, politics. The FDA’s been under pressure from vendors who contend their products aren’t devices just software. They also don’t want their products subject to being criticized for failures, especially in instances where they have no control over the process. That may be understandable from a corporate point of view, but there are several reasons for rejecting that point of view. Consider what the FDA currently defines as a medical device.

Other Devices. The FDA captures AE reports on an incredible number of devices. A few examples:

  • Blood pressure computers
  • Crutches
  • Drug dose calculators
  • Ice bags
  • Lab gear – practically all
  • Robotic telemedicine devices, and many, many more.

ECRI on EHR Adverse Events

The respected patient safety NGO, the ECRI Institute, puts the issue squarely. Each year, it publishes its Top Ten Health Technology Hazards. Number one is inadequate alarm configuration policies and practices. Number two: “Incorrect or missing data in electronic health records and other health IT systems.” Its report says:

Many care decisions today are based on data in an electronic health record (EHR) or other IT-based system. When functioning well, these systems provide the information clinicians need for making appropriate treatment decisions. When faults or errors exist, however, incomplete, inaccurate, or out-of-date information can end up in a patient’s record, potentially leading to incorrect treatment decisions and patient harm. What makes this problem so troubling is that the integrity of the data in health IT (HIT) systems can be compromised in a number of ways, and once errors are introduced, they can be difficult to spot and correct. Examples of data integrity failures include the following:

  • Appearance of one patient’s data in another patient’s record (i.e., a patient/data mismatch)
  • Missing data or delayed data delivery (e.g., because of network limitations, configuration errors, or data entry delays)
  • Clock synchronization errors between different medical devices and systems
  • Default values being used by mistake, or fields being prepopulated with erroneous data
  • Inconsistencies in patient information when both paper and electronic records are used
  • Outdated information being copied and pasted into a new report Programs for reporting and reviewing HIT-related problems can help organizations identify and rectify breakdowns and failures.

ECRI spells out why AE reporting is so important for EHRs:

…[S]uch programs face some unique challenges. Chief among these is that the frontline caregivers and system users who report an event—as well as the staff who typically review the reports—may not understand the role that an HIT system played in an event…

The MEDTECH Act’s Effects

The move to curtail the FDA’s EHR jurisdiction is heating up. Senators Hatch and Bennett’s proposed act exempts EHRs from FDA jurisdiction by defining EHRs as passive data repositories.

Most industry chatter about the act has been its exempting EHRs and others from the ACA’s medical device tax. However, by removing FDA’s jurisdiction, it would also exempt EHRs from AE reports. Repealing a tax is always popular. Preventing AE reports may make vendors happy, but clinicians, patients and the public may not be as sanguine.

The act’s first two sections declare that any software whose main purpose is administrative or financial won’t come under device reporting.

Subsection (c) is the heart of the act, which exempts:

Electronic patient records created, stored, transferred, or reviewed by health care professionals or individuals working under supervision of such professionals that functionally represent a medical chart, including patient history records,

Subsection (d) says that software that conveys lab or other test results are exempt.

Subsection (e) exempts any software that makes recommendations for patient care.

There are several problems with this language. The first is that while it goes to lengths to say what is not a device, it is silent about what is. Where is the line drawn? If an EHR includes workflow, as all do, is it exempt because it also has a chart function? The bill doesn’t say

Subsection (d) on lab gear is also distressing. Currently, most lab gear are FDA devices. Now, if your blood chemistry report is fouled by the lab’s equipment ends up harming you, it’s reportable. Under MEDTECH, it may not be.

Then there’s the question of who’s going to decide what’s in and what’s out? Is it the FDA or ONC, or both? Who knows Most important, the bill’s negative approach fails to account for those AEs, as ECRI puts it when: “Default values being used by mistake, or fields being prepopulated with erroneous data.”

Contradictory Terms

The act has a fascinating proviso in subsection (c):

…[P]rovided that software designed for use in maintaining such patient records is validated prior to marketing, consistent with the standards for software validation relied upon by the Secretary in reviewing premarket submissions for devices.

This language refers to information that device manufacturers file with HHS prior to marketing. Oddly, it implies that EHRs are medical devices under the FDA’s strictest purview, though the rest of the act says they are not. Go figure.

What’s It Mean?

The loud applause for the MEDTECH act coming from the EHR industry, is due to its letting vendors off the medical device hook. I think the industry should be careful about what it’s wishing for. Without effective reporting, adverse events will still occur, but without corrective action. In that case, everything will seem to go swimmingly. Vendors will be happy. Congress can claim to being responsive. All will be well.

However, this legislative penny in the fuse box will prove that keeping the lights on, regardless of consequences, isn’t the best policy. When something goes terribly wrong, but isn’t reported then, patients will pay a heavy price. Don’t be surprised when some member of Congress demands to know why the FDA didn’t catch it.

Communities Help Open Source Electronic Health Records Thrive (Part 3 of 3: Project Round-up)

Posted on December 16, 2014 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://radar.oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

This series examines the importance of community and what steps are being taken by open source projects in health IT to create communities around their projects. My previous posting covered VistA and its custodial organization, OSEHRA. The last article in this series covers some important projects in open source with very different approaches to building community.

In addition to VistA, the electronic health record with the most success in building community is OpenMRS, using a unique approach. The project has an unusual genesis. They didn’t come out of a technology center such as Silicon Valley, or a center of health research such as my own Boston. Instead, they were inspired by the Regenstrief Institute at Indiana University.

Getting only a small amount of attention in the United States, OpenMRS proved quite valuable in the developing regions of Africa, especially Rwanda. The U.S. developers realized right away that, for their software to be useful in cultures so far from Indiana, it would have to be understood and fully embraced by local experts.

Indeed, a number of accomplished software developers can be found in Rwanda and surrounding countries. The challenge to OpenMRS was to attract them to the goal of improving health care and to make work on OpenMRS easy.

OpenMRS not only trained developers in African countries to understand and adapt their software to local conditions, but mentored them into becoming trainers for other developers. The initial project to train Rwandan developers thus evolved, the local developers becoming competent to train others in neighboring countries.

In this way, the OpenMRS developers back in the U.S. opened up the project in a unique way to people on other continents. To be sure, the developers had a practical end: they knew they could not provide support to every site that wanted to install OpenMRS, or adapt it to local needs. But they ultimately created a new, intensely committed, international community around OpenMRS. Regular conferences bring together OpenMRS developers from far-flung regions.

The SMART platform is not an EHR itself, but an application programming interface (API) that its developers are asking EHR vendors to adopt. The pay-off for adoption will be that all compliant EHRs can interoperate, and a software developer can write a single app that runs on all of them. SMART was developed at Harvard Medical School with support from ONC. It now runs on top of FHIR, an HL7 project to provide a modern API giving access to all EHR data.

EHRs are not by any means the only community-building efforts in open source health IT. Another significant player is Open Health Tools, which came into being in recognition of the creative work being done by research firms, university professors, and others in various health IT areas.

OHT brings together a wide range of developers to build software for research, clinical work, and other health-related projects. It’s remarkably diverse, providing a meeting place for all projects interested in making health care technology work better. Although they have had problems finding financial support, they now solicit dues from interested projects and seem poised to grow.

For a while, OHT had grand visions of recruiting their members to contribute to a unified “framework” on which other software developers could build applications. This proved to be a bit too big a bite to chew, given the wide range of activities that go on in health IT. But OHT still encourages members to find common ground and make use of each other’s advances.

Aaron Seib, CEO of Open Health Tools, listed the main goals OHT has for its member developers: making communities discoverable, making their licensing intelligible, and addressing the intellectual property barriers that can constrain a project’s adoption. OHT also helps establish trust and connect the dots among the community members to multiply effects across member communities. Roger Maduro of Open Health News writes that OHT has played a critical role in building the open health ecosystem, including the VistA community.

Many other institutions also sense a need for community. A few years ago I spoke with John Speakman, who was working for the National Cancer Institute at the time. They had developed some software that was very popular among developers, but no one made any contributions back to the common software base, and the NCI wanted the users of the software to start taking responsibility for the tools on which they depended. He took on the task of building community, but left when he realized it was not going to take hold.

Among the problems was the well-known dependence of government agencies such as the NCI on contractors. Speakman points to an organizational and cultural gap between “the big Beltway Bandit companies (who will never use the code themselves to do biomedical science) over academic groups engaged in biomedicine.” He also thinks the NCI intervened too much in community activities, instead of letting community members work out disagreements on their own. “If the government is going to invest in the seeding of open source communities,” he says, “it has to (a) focus on releasing the data and see what folks do with it, and (b) use as light a hold as possible on how the communities run themselves.”

Athenahealth stands out among EHR vendors with its More Disruption Please program. There it is building an ecoystem of third-party tools that its customers can use as part of its cloud-based service. This goal is similar to that of the open source SMART platform, which is trying to get EHR vendors and other data stores to adopt a common API and thus make themselves more open to software developers.

Openness and community go together. Although the health IT field is slow to adopt both practices, some projects could be entering into a virtuous cycle where open source developers learn to appreciate the value of their communities, which in turn reward the most open projects with greater success.

Open Source Electronic Health Records: Will They Support Clinical Data Needs of the Future? (Part 2 of 2)

Posted on November 18, 2014 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://radar.oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The first part of this article provided a view of the current data needs in health care and asked whether open source electronic health records could solve those needs. I’ll pick up here with a look at how some open source products deal with the two main requirements I identified: interoperability and analytics.

Interoperability, in health care as in other areas of software, is supported better by open source products than by proprietary ones. The problem with interoperability is that it takes two to tango, and as long as standards remain in a fuzzy state, no one can promise in isolation to be interoperable.

The established standard for exchanging data is the C-CDA, but a careful examination of real-life C-CDA documents showed numerous incompatibilities, some left open by the ambiguous definition of the standard and others introduced by flawed implementations. Blue Button, invented by the Department of Veterans Affairs, is a simpler standard with much promise, but is also imperfectly specified.

Deanne Clark, vxVistA Program Manager at DSS, Inc., told me that VistA supports the C-CDA. The open source Mirth HIE software, which I have covered before, is used by vxVistA, OpenVista (the MedSphere VistA offering), and Tolven. Proprietary health exchange products are also used by many VistA customers.

Things may get better if vendors adopt an emerging HL7 standard called FHIR, as I suggested in an earlier article, which may also enable the incorporation of patient-generated data into EHRs. OpenMRS is one open source EHR that has started work on FHIR support.

Tolven illustrates how open source enables interoperability. According to lead developer Tom Jones, Tolven was always designed around care coordination, which is not the focus of proprietary EHRs. He sees no distinction between electronic health records and health information exchange (HIE), which most of the health IT field views as separate functions and products.

From its very start in 2006, Tolven was designed around helping to form a caring community. This proved useful four years later with the release of Meaningful Use requirements, which featured interoperability. APIs allow the easy development of third-party applications. Tovlen was also designed with the rights of the patient to control information flow in mind, although not all implementations respect this decision by putting data directly in the hands of the patient.

In addition to formats that other EHRs can recognize, data exchange is necessary for interoperability. One solution is an API such as FHIR. Another is a protocol for sending and receiving documents. Direct is the leading standard, and has been embraced by open source projects such as OpenEMR.

The second requirement I looked at, support for analytics, is best met by opening a platform to third parties. This assumes interoperability. To combine analytics from different organizations, a program must be able to access data through application programming interfaces (APIs). The open API is the natural complement of open source, handing power over data to outsiders who write programs accessing that data. (Normal access precautions can still be preserved through security keys.)

VistA appears to be the EHR with the most support for analytics, at least in the open source space. Edmund Billings, MD, CMO of MedSphere, pointed out that VistA’s internal interfaces (known as remote procedure calls, a slightly old-fashioned but common computer term for distributed programming) are totally exposed to other developers because the code is open source. VistA’s remote procedure calls are the basis for numerous current projects to create APIs for various languages. Some are RESTful, which supports the most popular current form of distributed programming, while others support older standards widely known as service-oriented architectures (SOA).

An example of the innovation provided by this software evolution is the mobile apps being built by Agilex on VistA. Seong K. Mun, President and CEO of OSEHRA, says that it now supports hundreds of mobile apps.

MedSphere builds commercial applications that plug into its version of Vista. These include multidisciplinary treatment planning tools, flow sheets, and mobile rounding tools so doctor can access information on the floor. MedSphere is also working with analytic groups to access both structured and unstructured information from the EHR.

DSS also adds value to VistA. Clark said that VistA’s native tools are useful for basic statistics, such as how many progress notes have not been signed in a timely fashion. An SQL interface has been in VistA for a long time, DSS’s enhancements include a graphical interface, a hook for Jaspersoft, which is an open source business intelligence tool, and a real-time search tool that spiders through text data throughout all elements of a patient’s chart and brings to the surface conditions that might otherwise be overlooked.

MedSphere and DSS also joined the historical OSEHRA effort to unify the code base across all VistA offerings, from both Veterans Affairs and commercial vendors. MedSphere has added major contributions to Fileman, a central part of VistA. DSS has contributed all its VistA changes to OSEHRA, including the search tool mentioned earlier.

OpenMRS contributor Suranga Kasthurirathne told me that an OpenMRS module exposes its data to DHIS 2, an open source analytics tool supporting visualizations and other powerful features.

I would suggest to the developers of open source health tools that they increase their emphasis on the information tools that industry observers predict are going to be central to healthcare. An open architecture can make it easy to solicit community contributions, and the advances made in these areas can be selling points along with the low cost and easy customizability of the software.

Open Standards Advance in Health Care Through the Appeal of FHIR and SMART

Posted on October 13, 2014 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://radar.oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The poor state of interoperability between EHRs–target of fulminations and curses from health care activists over the years–is starting to grind its way forward. Dr. Kenneth Mandl, a leader of the SMART Platform and professor at the Boston Children’s Hospital Informatics Program, found that out when his team, including lead architect Josh Mandel, went to HIMSS this year to support Cerner’s implementation of his standard, and discovered three other vendors running it.

That’s the beauty of open source and standards. Put them out there and anyone can use them without a by-your-leave. Standards can diffuse in ways the original developers never anticipated.

A bit of background. The SMART platform, which I covered a few years ago, was developed by Mandl’s team at Harvard Medical School and Children’s Hospital to solve the festering problem of inaccessibility in EHRs and other health care software. SMART fulfilled the long-time vision of open source advocates to provide a common platform for every vendor that chose to support it, and that would allow third-party developers to create useful applications.

Without a standard, third-party developers were in limbo. They had to write special code to support each EHR they want to run on. Worse still, they may have to ask the EHR vendor for permission to connect. This has been stunting the market for apps expanding the use of patient data by clinicians as well as the patients themselves.

SMART’s prospects have been energized by the creation of a modern interoperability resource called FHIR. It breaks with the traditional health care standards by being lean, extendible in controllable ways, and in tune with modern development standards such as REST and JSON.

It helps that SMART was supported by funds from the ONC, and that FHIR was adopted by the leading health care standards group, HL7. HL7’s backing of FHIR in particular lent these standards authority among the vendor and health care provider community. Now the chocolate and peanut butter favored by health IT advocates have come together in the SMART on FHIR project, which I wrote about earlier this year.

Mandl explains that SMART allows innovators to get access to the point of care. As more organizations and products adopt the SMART on FHIR, API, a SMART app written once will run anywhere.

Vendors have been coming to FHIR meetings and expressing approval in the abstract for these standards. But it was still a pleasant surprise for Mandl to hear of SMART implementations demo’d at HIMSS by Intermountain, Hewlett-Packard, and Harris as well as Cerner.

The SMART project has just released guidlines for health care providers who want to issue RFPs soliciting vendors for SMART implementations. This will help ensure that providers get what they ask and pay for: an API that reliably runs any app written for SMART.

It’s wise to be cautious and very specific when soliciting products based on standards. The notion of “openness” is often misunderstood and taken to places it wasn’t meant to go. In health care, one major vendor can trumpet its “openness” while picking and choosing which vendors to allow use of its API, and charging money for every document transferred.

The slipperiness of the “open” concept is not limited to health IT. For years, Microsoft promulgated an “open source” initiative while keeping to the old proprietary practices of exerting patent rights and restricting who had access to code. Currently they have made great progress and are a major contributor to Linux and other projects, including tools used with their HealthVault PHR.

Google, too, although a major supporter of open source projects, plays games with its Android platform. The code is nominally under an open license–and is being exploited by numerous embedded systems developers that way–but is developed in anything but an open manner at Google, and is hedged by so many requirements that it’s hard to release a product with the Android moniker unless one partners closely with Google.

After talking to Mandl, I had a phone interview with Stan Huff, Chief Informatics Officer for Intermountain. Huff is an expert in interoperability and active in HL7. About a year ago he led an effort at Intermountain to improve interoperability. The motivation was not some ethereal vision of openness but the realization that Intermountain couldn’t do everything it needed to be competitive on its own–it would have to seek out the contributions of outsiders.

When Intermountain partnered with Cerner, senior management had by that time received a good education in the value of a standard API. Cerner was also committed to it, luckily, and the two companies collaborated on FHIR and SMART. Cerner’s task was to wrap their services in a FHIR-compliant API and to make sure to use standard technology, such as in codes for lab data.

Intermountain also participated in launching a not-for-profit corporation, the Healthcare Services Platform Consortium, that promotes SMART-on-FHIR and other standards. A lot of vendors have joined up, and Huff encourages other vendors to give up their fears that standardization is a catheter siphoning away business and to try the consortium out.

Intermountain currently is offering several applications that run in web browsers (and therefore should be widely usable on different platforms). Although currently in the prototype stage, the applications should be available later this year. Besides an application developed by Intermountain to monitor hemolytic disease among neonates and suggest paths for doctors to take, they support several demonstration apps produced by the SMART project, including a growth chart app, a blood pressure management app, and a cardiovascular app.

Huff reports that apps are easy to build on SMART. In at least one case, it took just two weeks for the coding.

Attendees at HIMSS were very excited about Intermountain’s support for SMART. The health care providers want more flexible and innovative software with good user interfaces, and see SMART providing that. Many vendors look to replicate what Intermountain has done (although some hold back). Understanding that progress is possible can empower doctors and advocates to call for more.

What Happens When You Forget Your Laptop?

Posted on September 22, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Many people have long talked about the day when desktops and laptops will no longer exist. When you think about it, there is really nothing that couldn’t be done on your cell phone that can be done on a desktop or laptop.

Sure there are some applications that haven’t yet been made available on a cell phone (I mean natively. Of course a remote desktop environment can run anything) yet. However, every application could be made available on a cell phone if desired. The cell phone is powerful enough. Especially when attached to a powerful server. Yes, I know that many of the mobile apps aren’t as great as their desktop counterparts, but they could and will be.

If we could just use our cell phone for these applications, why don’t we? It admins would happily get rid of desktops and laptops in order to have a much smaller device footprint that they have to manage. It would take some time to make the switch, but it would happen.

The biggest reason I think we have yet to go all in with cell phones as our primary device is the value of peripherals. I think we seriously underestimate the value of a decent keyboard and extra screen real estate.

I’m amazed at how well you can type on a cell phone keyboard, but it still pales in comparison to a quality keyboard. Voice recognition might help in some situations, but it can’t be used everywhere a keyboard can be used. I don’t see us ever beating a physical keyboard at least until it starts typing our thoughts.

Screen real estate is an even bigger issue. As much as you shrink the internals of a cell phone you’re still bound by the size of the screen. Just look at Apple’s choice to release an iPhone with a larger screen. We love as much screen space as we can get. If you’ve never had the delight of using dual monitors on your desktop, you have no idea the efficiencies you’re missing out on. I can do everything on my laptop that I can do on my desktop, but dual monitors makes doing so much more effecient. I even bought a second monitor I could plug into the USB on my laptop. It’s that valuable.

I think the clear solution to this problem is to be able to easily connect your cell phone to external “monitors” and other peripherals like keyboards. Soon these connections will all be available wirelessly. I put “monitors” in quotes since I think we’ll have electronic viewing areas on everything from windows to tables and everything in between. That’s an exciting future to consider (we’ll leave the security issues for another post).

Unfortunately, we’re not there yet, but I think it’s where we’re headed. Eventually we’ll sit down at our desk where our cell phone will wirelessly connect to the monitors and peripherals on your desk. Until then we do this awkward dance between cell phone, laptop and desktop.

In fact, I just boarded a flight with my laptop charging at home instead of being in my laptop bag. Now I get to see first hand the difference between my laptop and cell phone on a work trip. If only the seat back was a monitor and the tray table a keyboard I could connect to my cell phone. Then, I’d been in business and wouldn’t even need my laptop. One day!

Afterthought: This is definitely a first world problems” post. Also, excuse any typoes, because I wrote this post in air on my cell phone keyboard. Certainly the lack of keyboard and monitor didn’t stop me from doing this post, but I could have probably done it twice as fast. Although, it’s a bit ironic that this post wouldn’t exist if the tech was already available. If you’ll be at the Insite Build conference in Fargo, ND, we’ll see you there. Just don’t be surprised if I ask to borrow your laptop.

Another EHR Glass Implementation

Posted on July 18, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

HealthTech has a really terrible write up of the latest EHR vendor to put out a Google Glass EHR implementation. The iPatientCare EHR application is called miGlass. However, the article states that it’s the first wearable EHR App for glass, but we’ve already written about one from DrChrono and Kareo’s Google Glass implementation was probably the first one that I saw. Plus, there are a number of hospital based EHR implementations that have happened as well. Maybe iPatientCare was the first and they just didn’t get any coverage until now.

Timing aside, the article lists the technology available on this new Google Glass EHR application, miGlass:

  • Web browser based EHR and PM System
  • Microsoft .net Technology
  • Services Oriented Architecture
  • HL7 CCD and ASTM CCR for Interoperability
  • HL7 Integration with leading Lab
  • Information Systems
  • SureScripts/RxHUB Certified ePrescribing
  • Reporting & Analytics using Cognos and Business Objects
  • Available on iPhone and iPad

Maybe the article just made a mistake (I make them all the time as you know), but that list seems like a list of EHR technology and not Google Glass application functionality. iPatientCare also has a video that’s not even worth linking to since it doesn’t say anything about what the Google Glass application really does.

While I love to see EHR vendors experimenting and testing the integration of Google Glass into their EHR, I still haven’t seen the killer use case in action. Although, there are a few hospital EHR Google Glass implementations that I’d like to see in action. I do love the potential of Google Glass. There’s something beautiful about an always on, always connected application that’s sitting there waiting for you when it’s needed. Plus, as the camera recognition technology gets better, the workflow will get better as well.

Imagine walking into an exam room and as you do it, your Google Glass scans a QR code on the door and pulls up the patient waiting for you in the room. Hopefully that’s the naive and simplistic view of where the technology is going to be taken. As more EHR vendors tinker with the technology it will be really interesting to see what becomes a reality.

Hospital CIOs Cutting Back on Non-Essential Projects

Posted on July 10, 2014 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Generally speaking, cutting back on IT projects and spending is a tricky thing. In some cases spending can be postponed, but other times, slicing a budget can have serious consequences.

One area  where cutting budgets can cause major problems is in preparing to roll out EMRs, especially cuts to training, which can lead to problems with rollouts, resentment, medical mistakes, system downtime due to mistakes and more.  Also, skimping on training can lead to a domino effect which results in the exit of CEOs and other senior leaders, which has happened several times (that we know of) over the past couple of years.

That being said, sometimes budgetary constraints force CIOs to make cuts anyway, reports FierceHealthIT Increasingly projects other than EMRs are falling in priority.

A recent survey of hospital technology leaders representing 650 hospitals nationwide published by HIMSS underscores this trend. Respondents told HIMSS said that despite increases in IT budgets, they still struggled to complete IT projects due to financial limitations. In fact, 25 percent said that financial survival was their top priority.

What that comes down to, it seems, is that promising initiatives fall by the roadside if they don’t contribute to EMR success.  For example, providers are stepping back from HIE participation because they feel they can’t afford to be involved, according to a HIMSS Analytics survey published last fall.

Instead, hospitals are taking steps to enhance and build on their EMR investment. For example, as FierceHealthIT notes, Partners HealthCare recently chose to pull together all of its EMR efforts under a single vendor.  In the past, Partners had used a combo of homegrown systems and vendor products, but IT leaders there  felt that this arrangement was too expensive to continue, according to Becker’s Hospital Review.

This laser focus on EMRs may be necessary at present, as the EMR is arguably the most mission-critical software hospitals have in place at the  moment. The question, as I see it, is whether this will cripple hospitals in the future. Eventually, I’d argue, mobile health will become a priority for hospitals and medical practices, as will some form of  HIE participation, just to name the first two technologies that come to mind. In three to five years, if they don’t fund initiatives in these areas, hospitals may look  up and find that they’re hopelessly behind .

Allscripts And Team Battle Epic and IBM for DoD Contract

Posted on June 27, 2014 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Earlier this month,we shared the news that Epic and IBM had gotten together to fight for the DoD’s massive Healthcare Management Systems  Modernization project. The project is to replace the current Military Health System, which should serve some 9.7 million beneficiaries.  The winning team should make about $11 billion to do the work.

So it’s little wonder that another group of health IT giants have stepped up to fight for such a juicy prize.  A group lead by Computer Sciences Corp., whose partners include Allscripts and HP, has announced that it intends to compete for the contract.

The HMSM project is extremely ambitious. It’s intended to connect varied healthcare systems across the globe, located at Army hospitals, on Naval vessels, in battlefield clinics and more, into a single open, interoperable platform serving not only active-duty members, but also reservists and civilian contractors.

Before you burst out laughing at the idea that any EMR vendor could pull this off, it’s worth considering that perhaps their partners can.  It’s hard to argue that CSC has a long track record in both government and private sector health IT work, and HP has 50 years with of experience in developing IT projects military health and VA projects.

That being said, one has to wonder whether Allscripts — which is boasting of bringing an open architecture to the project — can really put his money where its mouth is. (One could say the same of Epic, which frequently describes its platform as interoperable but has a reputation of being interoperable only from one Epic installation to the other.)

To be fair, both project groups have about as much integration firepower as anyone on earth. Maybe, if the winner manages to create an interoperable platform for the military, they’ll bring that to private industry and will see some real information sharing there.

That being said, I remain skeptical that the DoD is going to get what it’s paying for; as far as I know, there is no massively interoperable platform in existence that meets the specs this project has.  That’s not an absolute dealbreaker, but it should raise some eyebrows.

Bottom line, the DoD seems determined to give it a try, regardless of the shaky state of interoperability in the industry overall. And its goals seem to be the right ones. After all, who  wouldn’t want an open platform that lends itself to future change and development?  Sadly, however, I think it’s more likely that will be shaking our heads over the collapse of the project some years from now.

Will Outsourcing VA Care Monkey Wrench VistA?

Posted on June 16, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

The mess over the VA’s waiting times, with luck, will sort itself out with a revised management team and, perhaps, enough money to hire long needed staff.

One solution that’s pending in Congress is to let vets go outside the VA for care. From what I’ve read, most vets like the VA’s care and don’t want to change the main program, just fix it. However, that’s going to take time. The scandal has been around for a long time, at least since 2005 according to the VA’s Inspector General:

The issues identified in current allegations are not new. Since 2005, the VA Office of Inspector General (OIG) has issued 18 reports that identified, at both the national and local levels, deficiencies in scheduling resulting in lengthy waiting times and the negative impact on patient care. As required by the Inspector General Act of 1978, each of the reports listed was issued to the VA Secretary and the Congress and is publicly available on the VA OIG website.

Given the VA’s size and complexity as well as the need to recruit new staff and implement new procedures, permitting vets to use other resources has much appeal that crosses party lines. Two politically apart Senators, Bernie Sanders (I-VT) and John McCain (R-AZ)  started the change with their bill to allow outside care and more:

The Sanders-McCain legislation addresses the short-term problem of access to care by authorizing a two-year trial program that would allow veterans to seek private health care if they reside more than 40 miles from a VA facility or have been waiting more than 30 days for treatment. Long-term, the legislation authorizes the construction of 26 medical facilities in 18 states, and directs $500 million in unspent funds to hire more doctors and other health-care providers.

The House voted for outside providers, but killed any funding changes. The Senate passed the Sanders-McCain bill by a 93 to 2 vote. The next step is uncertain. One house could simply accept the other’s version, which is unlikely. The other alternative is a conference committee, which can draft its own version for both houses to vote on. Given the urgency, though, it’s probable that something will pass before long.

Wither VistA?

The fix, however, may unfix one of the VA’s strengths. It could create a medical record continuity problem separating vets from their records leaving VistA EHR, which tracks veterans healthcare, in the lurch.

How will vets’ records follow them to outside docs? Vets could download their records with Blue Button, but would local docs know what to do with them? When a vet’s encounter is over, how will the information get back to VistA, if at all.

Vets have a single, relatively well functioning medical record system. Here’s hoping the price of needed care doesn’t foul up what’s been working right.

Reply to Dr. Jacob Reider on NIST Dissects Workflow: Is Anyone Biting?

Posted on March 31, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

One comment on my latest post, NIST Dissects Workflow: Is Anyone Biting?, deserves a more than casual reply.

Here’s the comment from Jacob Reider (Note: Dr. Reider is ONC’s Acting Principle Deputy National Coordinator and Chief Medical Officer. He has made major contributions to the HIT field and is one of its significant advocates.)

Carl, ONC’s UCD requirement references ISO 9241–11, ISO 13407, ISO 16982, NISTIR 7741, ISO/IEC 62366 and ISO 9241–210 as appropriate UCD processes.

We also require summative testing as defined in NISTIR 7742.

Might “Refuses to incorporate NIST recommendations” be a bit of an overstatement?

We solicited public comment in our proposed rule for 2015 certification and would welcome specific suggestions for how we can/should improve user experience of health IT products for efficiency and safety.

Dr. Reider, thank you for your comment – it certainly falls into the category of you never know who’s reading.

Let’stake a look at your last comment first, “Might ‘Refuses to incorporate NIST recommendations’ be a bit of an overstatement?”

Obviously, I don’t think so, but I am not alone.

I based my comment on ONC’s statement in its rule making that refers to NIST’s usability protocols. It says:

While valid and reliable usability measurements exist, including those specified in NISTIR 7804 “Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,” (21) we are concerned that it would be inappropriate at this juncture for ONC to seek to measure EHR technology in this way.

Sounds like a rejection to me, however, don’t take my word. Here’s the AMA’s response to this decision. First, they demur and quote ONC:

We disagree with ONC’s assertion in the Version 2014 final rule that, “[w]hile valid and reliable usability measurements exist, including those specified in NISTIR 7804 ‘‘Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,’’ we expressed that it would be inappropriate for ONC to seek to measure EHR technology in this way.”

It then says:

To the contrary, we believe that it is incumbent upon ONC to include more robust usability criteria in the certification process.  The incentive program has certainly spurred aggressive EHR uptake but has done so through an artificial and non-traditional marketplace.  As a consumer, the physician’s choice of products is limited not only by those EHRs that are certified but also by the constraint that all of these products are driven by federal criteria.  The AMA made several detailed recommendations for improving Version 2014 certification in our Stage 2 comment letter, which were not adopted, but still hold true, and we recommend ONC consider them for the next version.  Testimony of AMA’s Health IT Policy Committee’s Workgroups on Certification/Adoption and Implementation, July 23, 2013, pp. 5-6

I recognize that ONC says that it may consider the protocols in the future. Nevertheless, I think the plain English term rejected fits.

In the first part of his statement, Dr. Reider cites several ISO standards. With the exception of the Summative Testing, all of these have been referred to, but none have been adopted. Reference to a standard is not sufficient for its inclusion under the operation of the federal Administrative Procedure Act, which governs all federal agency rulemaking. In other words, these standards are important, but ONC simply calls them out for attention, nothing more.

I think two factors are at work in ONC’s reluctance to include the NIST usability protocols. The first is that the vendors are adamantly opposed to having them mandated. However, I believe there is a way around that objection.

As I have argued before, ONC could tell vendors that their products will be subject to a TURF based review of their product for compliance and that the results would be made public. That would give users a way to judge a product for suitability to their purpose on a uniform basis. Thus, users looking at the results could determine for themselves whether or not one or more non compliance was important to them, but at least they would have a common way to look at candidate EHRs, something they cannot do now , nor under ONC’s proposed approach.

The other factor is more complex and goes to the nature of ONC’s mission. ONC is both the advocate and the standards maker for HIT. In that, it is similar to the FAA, which is vested with both promoting and regulating US aviation.

It’s well established that the FAA’s dual role is a major problem. It’s hard to be a cheerleader for an industry and make it toe the line.

With the FAA, its dual mandate is exacerbated when the highly respected NTSB investigates an incident and makes recommendations. The FAA, acting as industry friend, often defers NTSB’s authoritative and reasonable recommendations to the public’s determent.

I believe that something similar is going on with ONC. NIST’s relationship to ONC is roughly analogous to that of the NTSB’s to the FAA.

NIST is not an investigative agency, but it is the federal government’s standards and operations authority. It isn’t infallible. However, ONC dismissing NIST’s usability protocols, in one word, inappropriate. It did this without explanation or analysis (at least none that they’ve shared). In my view, that’s really inappropriate.

ONC has a problem. It’s operating the way it was intended, but that’s not what patients and practioners need. To continue the aviation analogy, ONC needs to straighten up and fly right.