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!

Ready For a Third-Party Market for Apps on Your EHR? athenahealth Explains How (Part 2 of 2)

Posted on July 20, 2015 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.

In part 1 of this article, I explained why EHR vendors need to attract outside developers to remain competitive, and how athenahealth’s More Disruption Please (MDP) program pursued this goal by developing open APIs. This part goes on to describe how they made their athenahealth Marketplace an actuality.

Through experimentation, API developers throughout companies and governments have found a toolbox of best practices to develop and promote their APIs. athenahealth pretty much did everything in this toolbox:

  • A prominent public announcement (in this case, coming from the CEO Jonathan Bush himself)

  • A regular set of hackathons to answer developer questions and familiarize them with the APIs,

  • An early pilot partnership that created a demonstration project and produced insights for further development, described in Part 1 of this article

  • An accelerator program that offers seed funding, free office space, mentorship, technical resources, support, and contacts with the client base

  • A commitment to support both physicians and partners, including a requirement that athenahealth developers work on API documentation

Access to the APIs is easy–for security purposes, a developer has to agree to the run-of-the-mill terms and conditions, but the process is fast and there is no charge. The athenahealth Marketplace is large and thriving, with more than 2,500 members.

Having spent a lot of money for an EHR, clinicians who are growing more tech-savvy and have come to love their mobile apps will demand more and more value for the money. Vendors are coming to realize that they can’t produce all the value-added solutions and functionality their customers want.

The SMART Platform has, for several years, championed the availability of EHR data to fuel app development by EHR users and third-party companies. The recent FHIR standard has drawn enthusiasm from vendors. A number of them, including athenahealth, have formed the Argonauts project to develop shared definitions and ensure that, in an interoperable way, they can provide the most common types of data used by US clinicians.

But as explained before, supporting an API does not automatically lead to more effective, beneficial apps or services. athenahealth has gone to the next level to attract real-time, dynamic applications to its Marketplace, and in turn is reaping the benefits.

Ready For a Third-Party Market for Apps on Your EHR? athenahealth Explains How (Part 1 of 2)

Posted on July 17, 2015 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.

A number of electronic health record vendors now grant access to EHR data to programmers at user sites through an application programming interface (API). Hospitals and ambulatory practices are making great use of APIs to extract data on patients and analyze it to improve care (or at least their bottom lines–it’s good for marketing to patients as well as protecting them from adverse medical events).

Far fewer EHRs allow totally new applications to be built by outsiders, suitable for sale or free distribution to health care providers. To find out more about how this can be jump-started, I talked recently to Chip Ach at athenahealth, whose outspoken CEO Jonathan Bush has committed to dealing with health care in new ways. (I reviewed Bush’s book, Where Does It Hurt?,in another article.) Chip Ach is senior architect for athenahealth’s More Disruption Please (MDP) program.

MDP is building an open, API-based ecosystem on athenahealth’s cloud-based platform for entrepreneurs to connect, collaborate, and scale more efficiently in health care. athenahealth allows both established and start-up health IT companies to sign up as partners, creating a large marketplace of innovative, third-party health care solutions. Applications solve such problems as scheduling, speeding up payments, and increasing engagement with patients.

The value of a third-party market
Let’s step back a minute to look at why both vendors and health care providers would want a marketplace for companies to write apps based on their EHR data. Start with the obscurity of the data itself: very few health care providers can find out from their EHRs which patients are frequent ER visitors or which surgeons have consistently better outcomes–data that could trigger critical interventions. Even fewer EHRs provide information to patients, and the patient portals that some providers have made available usually offer extremely limited views.

Second, most EHRs have poor interfaces, a gawkiness that becomes especially evident on the tablets and cell phones that are just as popular among clinicians as the general population. A healthy competition and atmosphere of experimentation among interface developers will greatly improve EHR usability.

Clinicians are just too diverse for one vendor to take into account all their needs. More often than now, clinicians report a drop in productivity after the introduction of EHRs, even after the users get acclimated. If an agile development process could create unique and customizable interfaces, doctors and nurses could go back to focusing on patients.

Finally, unanticipated uses for patient data can emerge from an open marketplace. The use of analytics and clinical decision support could skyrocket.

athenahealth management decided several years ago that the health care system needs a radical change toward generating and accepting new solutions to its pain points. Calling this a “Health Care Internet,” they see it as a place for health care providers to compare and “shop” for nearly any product or service they might want or need, whether it be data management, digital check-in, self-pay, mobile charge capture, or transcription. MDP and the athenahealth Marketplace are their contributions to change.

Steps toward athenahealth’s Marketplace
It takes a special program like MDP to draw developers to a platform, particularly in health care where so many developers are deterred by the field’s complexity and issues of liability. In keeping with the company vision to straighten out the operation of the health care system, athenahealth embraced an open platform, adhering to industry standards such as HL7 and investigating the publication of open APIs.

At the same time, their programmers were modularizing a rather monolithic code to reap the productivity benefits that this would offer. Modularization facilitated the design of APIs to connect one module with another. After announcing a few open APIs and seeing the program catch on, the MDP team asked itself: why not make all their modules available to outside programmers, including those that were previously considered internal?

Early in the program, they found a company eager to develop an appointment scheduling application, and worked closely with them to make it possible. Ach’s team promised to get the API working in three months, which was quite a tight deadline. None of the team had prior experience doing an open API for a market, and they needed to face a lot of new requirements that openness created–for instance, adding an authentication layer, deciding how to deliver documentation on the APIs, and offering the opportunity for developers to get a feel for using the APIs. They now have a developer’s portal open to those who sign their modest terms and conditions. There is no fee or vetting process.

To speed up delivery of an API, athenahealth developers sought out a management service and chose Mashery to do the job. In the end, after a lot of long workdays, they met their three-month deadline. The partner was so sure they’d miss the deadline that it wasn’t ready to use the API–but it caught up and successfully released the app. Along the way, the MDP team learned some of the range of data that needed to be exposed by their APIs.

Eventually, athenahealth dedicated itself to rigorously modularizing their code with well-defined interfaces between all components–like Amazon.com–and to exposing as many interfaces as they could to partners. Naturally, this was potentially frightening; both managers and programmers have to take a leap of faith. What would design decisions made years ago look like when put out in the light of day? How many changes would they have to make?

According to Ach, developers were not resistant for ego reasons (they didn’t mind showing the architecture to outsiders), but worried about their ability to seamlessly upgrade the API in the future. A lot of decisions had to be made quickly before opening the APIs to third-party developers, who would come to depend on them and assume they would remain unchanged. Ach says the teams have been happy with their choices, although early on, in the effort to keep the process moving forward, they didn’t create all their naming standards and left that to be done later.

So the process went smoothly on the inside–but how did it fare externally? That’s the subject of part 2 of this article.

Crazy ICD-10 Codes? Let’s Put Them In Perspective

Posted on July 16, 2015 I Written By

The following is a guest blog post by Jennifer Della’Zanna, medical writer and online instructor for Education2Go.
Jen HIM Trainer
Exhibit A: W55.21XA Bitten by a cow, initial encounter

Exhibit B: Y92.241 Hurt at the library

Exhibit C: Y93.D1 Accident while knitting or crocheting

Exhibit D: W56.22 Struck by Orca, initial encounter

These are the kinds of codes trotted out to “prove” how ridiculous moving the ICD-10 coding system is. What do we need these codes for? Everybody seems to be asking this question, from congressmen to physician bloggers to—now—regular people who have never before even known what a medical code was.

Here are a few things you should know about these codes. Some of you actually should know this already, but I’ll review for those who have been sucked into the maelstrom of ridicule swirling about the new code set.

  1. You’ll notice that all those crazy code examples start with the letters V, W, X and Y. These are all “external cause codes,” found in just one of ICD-10’s 21 chapters (Chapter 20). In my version of the manual, that encompasses 76 pages. Out of 848.

    External cause codes are the only ones ever trotted out as ridiculous. Do the math. They make up 9% of the codes. They are used mainly to encode inciting factors and other details about trauma/accident situations. There are some other uses, but not many. Do most people use them in everyday coding? No. That’s not going to change with the new system. If you’re a coder who is not already using external cause coding on a day to day basis, you will likely not have to start now. Most people never look in this chapter—ever.

  2. The reason there are such funny codes is the system allows you to “build” a code using pieces, which is what makes the book so easily expandable in all the right places (which is the point of the entire code change—the external cause codes just came along for the ride). Let’s look at Exhibit A: Bitten by a cow, initial encounter:
    The first three characters of the code indicate the category. Each additional character adds some detail.W55 is the category “Contact with other mammals”The 4th character 2 indicates contact specifically a cow (although included in this code is also a bull). You can change the animal to a cat by using 0 or a horse by using 1. You get the idea, right?

    The 5th character 1 indicates that the injury is a bite. A 2 would mean the patient was struck, not bitten.

    The 6th character X is a placeholder because this code requires a 7th character extension to indicate what encounter this visit was.

    The 7th character A indicates that this was an initial encounter. You could change this to a D if the patient has returned for subsequent visits or an S if the patient ends up with another problem later that could be attributed to this original cow—or bull—bite.

  3. We can code most of those same ridiculous codes with ICD-9, although most times not quite to the same specificity. I’ll match the ones below to the exhibits we have at the top:
    Exhibit A: E906.3 Bite of other animal except arthropod

    This is what we would currently have to use for “bitten by a cow.” There is no way in the current code set to indicate whether this is an initial encounter or a follow-up encounter for this accident, however. Since the code is so vague, this code could actually also be used to mean “bitten by a platypus” or “bitten by a pink fairy armadillo,” so yes, you can still code that in ICD-9, but not as well.

    Exhibit B: E849.6 Accidents occurring in public building

    Do you consider a library a public building? I do. Yep, you can code that with ICD-9, but not as well.

    Exhibit C: E012.0 Activities involving knitting and crocheting

    This is what we call a one-to-one mapping. A specific code for this already exists in ICD-9 with exactly the same description. Next.

    Exhibit D: E906.8 Other specified injury caused by animal

    This is the code we would have to use to indicate an attack by an Orca. Again, no indication of what encounter it is, but this time there is actually no reason to even use this code because, really, what information is it giving you? The patient was injured by an animal. We have no idea what kind of injury or what animal caused it. I’m all for going to a useful code for those rare occurrences of attacks by Orcas (which, as we all know, do occur from time to time!).

The real point is not what kinds of crazy things are now able to be coded, it’s what critical things can be coded with ICD-10 that could not be coded with ICD-9. The most newsworthy one is Ebola. In ICD-9, we have to use 065.8 Other specified arthropod-borne hemorrhagic fever. In ICD-10, we have A98.4 Ebola virus disease. But there are other reasons to go to the new system. There are new concepts in ICD-10 that didn’t exist in ICD-9, like laterality. We now have the ability to indicate which side of the body an injury or other condition occurs. This inclusion is one of the biggest reasons for the book’s code expansion. Each limb and digit has its own code (but, again, it’s the changing of one number in the overall code that indicates left or right, and which digit is affected). With all the complaints about the increased documentation required for the new code set, one would hope that most physicians already document which hand or arm or leg or ear or eye or finger is affected. As I mentioned above with the seventh-character extension, there is the ability to indicate the encounter and, more importantly, to link a prior condition with a current one with the use of the S character that indicates “sequela.”

There’s much evidence that the ICD-10-CM will help make patient records more accurate and reporting of conditions more precise. This will lead to improved research abilities and a healthier worldwide population. And the ridiculing of ICD-10 codes, which I’m sure will continue long after this blog post has disappeared from your newsfeed? Well, they always say that laughter is the best medicine!

About Jennifer Della’Zanna
Jennifer Della’Zanna, MFA, CHDS, CPC, CGSC, CEHRS has worked in the allied health care industry for 20 years. Currently, she writes and edits courses and study guides on medical coding and the use of technology in health care, as well as feature articles for online and print publications.  You can find her at www.facebook.com/HIMTrainer and on Twitter @HIMTrainer.

Can We Now Officially Say that ICD-10 Is Going to Happen?

Posted on July 15, 2015 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.

With the announcement that came a little over a week ago about CMS and AMA working together on ICD-10, does that mean that we can officially say that ICD-10 is going to happen? The ICD-10 Watch blog has a good summary of what CMS committed to do in the announcement:

  • CMS is creating an ICD-10 Ombudsman to deal with healthcare providers’ ICD-10 problems. More on how this will work later.
  • Without using the words “safe harbor” or “grace period,” CMS promises that Medicare will not deny any medical claims “based solely on the specificity of the ICD-10 diagnosis code as long as the physician/practitioner used a valid code from the right family.”
  • Quality reporting programs such as Physician Quality Reporting System (PQRS), Value Based Modifier (VBM), or Meaningful Use 2 (MU) will suspend penalties that may result because of lack of specificity.
  • There will be advance payments available if the Medicare system has problems.

The second and fourth items have gotten all the buzz. Most have interpreted that the second one means that CMS won’t deny ICD-10 claims that weren’t done correctly. That’s an overstatement, but it does decrease the number of denied claims that will occur with the switch to ICD-10. The fourth item listed above was a major concern that I raised, but it applied to all payers and not just CMS. So, it’s nice that CMS has addressed the cash flow challenges that slow claims processing of ICD-10 claims will cause, but that still leaves all the other payers.

With the “peace treaty” signed between AMA and CMS, can we finally say that ICD-10 will not be delayed again? One person suggested to me that it just leaves the AHA as a possible opponent that could stop it. However, I also heard it suggested that they weren’t looking for a delay.

While usually avoiding trying to predict the unpredictable Washington, I’m going to say that we can safely assume that ICD-10 will not be delayed again. We might see an overture or two still that tries to delay it, but if I were putting my money down in Vegas I’d put it all on No ICD-10 Delay in 2015. Are you putting your organization’s “bet” in the same place?

I Have Seen The Portal, And It Is Handy

Posted on July 14, 2015 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.

After writing about EMRs/EHRs and portals for many years, I’ve finally begun using an enterprise-class portal to guide my own care. Here’s some of my impressions as an “inside” (EMR researcher) and “outside” (not employed as a provider) user of this tool. My conclusion is that it’s pretty handy, though it’s still rather difficult to leverage what I’ve learned despite being relatively sophisticated.

First, some background. I get most of my care from northern Virginia-based Inova Health System, including inpatient, primary care, imaging and specialist care. Inova has invested in a honking Epic installation which links the majority of these sites together (though I’ve been informed that its imaging facilities still aren’t hooked up to core medical record. D’oh!) After my last visit with an Inova doctor, I decided to register and use its Epic portal.

Epic’s MyChart has a robust, seemingly quite secure process for registering and accessing information, requiring the use of a long alphanumeric code along with unique personal data to establish an account. When I had trouble reading the code and couldn’t register, telephone-based tech support solved the problem quickly.  (Getting nearsighted as I move from middle- to old-aged!)

Using MyChart, I found it easy to access lab results, my drug list and an overview of health issues. In a plus for both me and the health system, it also includes access to a more organized record of charges and balances due than I’ve been able to put together in many years.

When I looked into extracting and sharing the records, I found myself connected to Lucy, an Epic PHR module. In case you’ve never heard of it (I hadn’t) here’s Epic’s description:

Lucy is a PHR that is not connected to any facility’s electronic medical record system. It stays with patients wherever they receive care and allows them to organize their medical information in one place that is readily accessible. Patients can enter health data directly into Lucy, pull in MyChart data or upload standards-compliant Continuity of Care Documents from other facilities.

As great as the possibility of integrating outside records sounds, that’s where I ran into my first snag. When I attempted to hook up with the portal for DC-based Sibley Memorial Hospital — a Johns Hopkins facility — and integrate the records from its Epic system into the Inova’s Lucy PHR, I was unable to do so since I hadn’t connected within 48 hours of a recent discharge. When I tried to remedy the situation, an employee from the hospital’s Health Information Management department gave me an unhelpful kiss-off, telling me that there was no way to issue a second security code. I was told she had to speak to her office manager; I told her access to my medical record was not up for a vote, and irritated, terminated the call.

Another snag came when I tried to respond to information I’d found in my chart summary. When I noted that one of my tests fell outside the standard range provided by the lab, I called the medical group to ask why I’d been told all tests were normal. After a long wait, I was put on the line with a physician who knew nothing about my case and promptly brushed off my concerns. I appreciate that the group found somebody to talk to me, but if I wasn’t a persistent lady, I’d be reluctant to speak up in the future given this level of disinterest.

All told, using the portal is a big step up from my previous experiences interacting with my providers, and I know it will be empowering for someone like myself. That being said, it seems clear that even in this day and age, even a sophisticated integrated health system isn’t geared to respond to the questions patients may have about their data.

For one thing, even if the Lucy portal delivers as promised, it’s clear that integrating data from varied institutions isn’t a task for the faint of heart. HIM departments still seem to house many staffers who are trained to be clerks, not supporters of digital health. That will have to change.

Also, hospitals and medical practices must train employees to enthusiastically, cheerfully support patients who want to leverage their health record data. They may also want to create a central call center, staffed by clinicians, to engage with patients who are raising questions related to their health data. Otherwise, it seems unlikely that they’ll bother to use it.

Adapting Hospital Records to the Needs of Transgender People

Posted on July 13, 2015 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.

More than just about any other institution, hospitals and clinics have to deal with the unexpected. People with the most unusual characteristics and problems drop in all the time. But electronic records, being formal documentation, like regularity. The clash between diversity and computerization explodes into view when a transgender or gender-queer person walks in.

I have written about the strains that transgender people put on an EHR earlier as part of my family’s encounter with the medical system. Recently I got a chance to talk with a leader who has taken some of the necessary steps to fix systems: Scott MacDonald, MD, working in the health system of University of California at Davis.

A thrust to improve UC Davis’s handling of LGBT clients preceded Dr. MacDonald’s arrival. A group of staff and clinicians interested in providing better care to LGBT people decided to take steps to address the needs in that area. The institution made an ethical commitment to reducing disparities in care. The group recognized that the information in the record was deficient–they often didn’t even know who identified as LGBT.

The first step in this information gathering is training health providers to ask for the information in ways that are sensitive to patients’ feelings, and to become comfortable with it. The next step is deciding what to do with that information, and the third is figuring out how to store it in a structured way.

As MacDonald says, “The first priority is to train providers to understand why this data collection is important, explaining that they cannot care for a person whose life situation they don’t understand. Research (especially for reducing disparities) is a close second priority. An electronic means to capture the data needs to be created along with these efforts. Once the data is available in a formal, structured way, we can encourage and train clinicians to ask the pertinent questions and respond to the information sensitively.”

When MacDonald joined the organization, he brought technical expertise with working on disparities in ethnicity and language. He started two surveys: one of the patient population and another of the staff.

The patient survey showed that for the most part, patients were glad to be asked about their sexual orientation (which is different from sexual behavior, although related). They were particularly open to the question if their primary care provider was the one holding the discussion. Naturally, some expressed privacy concerns and wondered who might have access to the information once it was recorded.

Health care providers also showed a willingness to learn more about LGBT issues and be listed in the UC Davis registry as an LGBT-welcoming provider. Over time, without an explicit mandate from leadership, the information collected on the sexual preference of patients increased. UC Davis also provided resources for training in LGBT issues via a web site.

Before starting, UC Davis interviewed the clients of a local clinic specializing in gender issues, in order to flesh out their understanding of patient needs and sensitivities.

Now we get to the heart of the IT issues. Any record system used by a health care institution needs at least the following to handle transgender and gender non-conforming patients:

  • A way to list their preferred name and gender, along with the name and gender that appear on their insurance cards and other official documents. Transitions can take years, and patients often have insurance with the old name and gender long after they have made the determination to be known in a new way. Gender can also be a fluid and evolving concept for some patients.

  • Ways to record the factors that affect gender, such as what surgeries they have had for gender dysphoria and what hormones they are taking. Someone who identifies as male may still need to have a regular Pap smear. A male-to-female transgender person may have a very different normal range on a blood test from someone born female (cis-female).

UC Davis had licensed an Epic EHR, but at that time Epic had only a few suggestions to offer. For instance, they suggested adding a special flag for transgender patients, but this would be too limited a way of handling the range of gender issues encountered, and would not provide adequate clinical information. UC Davis thus launched into a series of customizations, which Epic in turn compiled into an implementation guide that has been used by other customers.

The goal at UC Davis was to make it easy for patients to enter data at in the privacy of their homes through Epic’s patient portal. The interviews at the partner clinic had showed that many were comfortable providing information this way that many were comfortable providing information this way. Besides asking for assigned sex at birth, click-buttons in the portal’s web page offer common choices for current gender identity and sexual orientation. The patient could also enter free-text comments if the predefined choices didn’t capture their identity.

The same information could be entered by clinicians as well. People viewing the record could not tell whether the gender information was entered by a clinician or directly by the patient (although on the back-end, the system preserves the provenance of the information). MacDonald said that the source of the information was ultimately the patient, so it doesn’t really matter who entered it.

What’s important is that the gender-related information, formerly stuffed into free-form text somewhere in the record, was now stored in a structured format. This allows UC Davis to fulfill its mandate to track how it is addressing disparities in care. In the future, such information may also feed into clinical decision support tools.

The gender information is not displayed prominently, but is available to all staff who have access to patient records and seek it our for purposes of patientcare. It is protected by the usual information security measures in place at UC Davis. The information is of greatest use to the primary care provider, but is also used by in-patient nurses and special departments dealing with transgender issues.

The patient’s preferred name was easier to handle. Epic already allows records to distinguish between the official name–used for legal and insurance purposes–and the preferred name. The record offers several descriptors that explain what the preferred name is, such as a nickname or alias. To this list of descriptors, UC Davis added an option applicable to transgender patients.

The remaining missing information is the status of a patient during and after transition. A record can’t yet record birth sex in a separate field from gender identity. It can capture sex as cis-male or trans-man, but that doesn’t gracefully account for the combinatorics of birth sex, gender identity, legal sex, and so on. Transition-specific surgeries and hormone therapy can be captured as a part of surgical history and the medication list, but there is no standard way to record organ inventory. Those things are still listed in free-form text.

However, Epic is looking at ways to adapt its software at the deep level to show this diversity of status. This is something all vendors need to do, because more and more people of all ages are identifying as transgender or non-conformaing as the public gets used to the idea that this kind of identity is within the range of normal. The needs of the population are complex and urgent, so the faster we fix the records, the better will be the care we provide.

Providers Still Have Hope For HIEs

Posted on July 10, 2015 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.

Sometimes, interoperability alone doesn’t cut it.  Increasingly, providers are expecting HIEs to go beyond linking up different organizations to delivering “actionable” data, according to a new report from NORC at the University of Chicago. The intriguing follow-on to the researchers’ conclusions is that HIEs aren’t obsolete, though their obsolescence seemed all but certain in the past.

The study, which was written up by Healthcare Informatics, conducted a series of site visits and 37 discussions with providers in Iowa, Mississippi, New Hampshire, Vermont, Utah and Wyoming. The researchers, who conducted their study in early 2014, hoped to understand how providers looked at HIEs generally and their state HIE program specifically. (The research was funded by ONC.)

One major lesson for the health IT types reading this article is that providers want data sharing models to reflect new care realities.  With Meaningful Use requirements and changes in payment models bearing down on providers, and triggering changes in how care is delivered, health IT-enabled data exchange needs to support new models of care.

According to the study, providers are intent on having HIEs deliver admission, discharge, and transfer alerts, interstate data exchange and data services that assist in coordinating care. While I don’t have comprehensive HIE services research to hand, maybe you do, readers. Are HIEs typically meeting these criteria? I doubt it, though I could be wrong.

That being said, providers seem to be willing to pay for HIE services if the vendor can meet their more stringent criteria.  While this may be tough to swallow for existing HIE technology sellers, it’s good news for the HIE model generally, as getting providers to pay for any form of community data exchange has been somewhat difficult historically.

Some of the biggest challenges in managing HIE connectivity identified by the study include getting good support from both HIE and EMR vendors, as well as a lack of internal staff qualified to manage data exchange, competing priorities and problems managing multiple funding streams. But vendors can work to overcome at least some of these problems.

As I noted previously, hospitals in particular have had many beliefs which have discouraged them from participating in HIEs. As one HIE leader quoted in my previous post noted, many have assumed that HIE connection costs would be in the same range as EMR adoption expenses; they’re been afraid that HIEs would not put strong enough data security in place to meet HIPAA obligations; and they assumed that HIE participation wasn’t that important.

Today, given the growing importance of sophisticated data management has come to the forefront, and most providers know that they need to have the big picture widespread data sharing can provide. Without the comprehensive data set cutting across the patient care environment — something few organizations are integrated enough to develop on their own — they’re unlikely to mount a successful population health management initiative or control costs sufficiently. So it’s interesting to see providers see a future for HIEs.

About That Doctor – Patient-EHR Relationship

Posted on July 9, 2015 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.

My friend Joe is a retired astrophysicist turned web geek. Joe’s had his health problems, but he’s still an avid bicycle rider as well as one of the most well read persons I’ve ever known. He doesn’t miss much, and always has his own – often original – take on politics, the economy, the net and a lot else.

There is one topic where his take echoes many others. He never fails to send me posts about how EHRs interfere in the doctor – patient relationship. He just loathes it when his doc spends time keying away rather than making eye contact.

Joe knows I get pretty wound up on EHR usability and interop problems, but that just makes me an even better target for his disgruntlement. He, of course, has a point as do so many others who’ve lamented that what was once a two way conversation has become a three way with the patient the loser.

The point, I think, only goes so far. What’s going on in these encounters is more than the introduction of an attention sucking PC. It’s simply wrong to assume that medical encounters were all done the same warm and fuzzy way until EHRs came along. To understand EHRs’ effect from a patient’s perspective, I think we need to ask ourselves several questions about our EHR involved medical appointments.

  • Whose Appointment Is It? Are you there alone, with an elderly parent, your spouse or your child, etc.?
  • Appointment’s Purpose. Why are you there? Is it for a physical, is it due to bad cold, a routine follow up or is it for a perplexing question? Is it with a specialist, pre or post op?
  • Your Relationship. How long and how well have you know this doctor? How many doctors have you had in the past few years?
  • How Long Has It Been? When was the last time you saw your doctor, days, weeks, years? How much catching up is there to do?
  • Doc’s Actions. What’s your doc doing on the EHR, looking for labs, going over your meds, writing notes, writing prescriptions, ordering tests, checking drug interactions? How many of these would have been impossible or difficult on paper?
  • Money. How much time does your doc take trying to save you money finding generics, looking at what your insurance covers, etc.?

Many EHRs have usability problems and many have been implemented poorly. As with all technological innovations in professional settings though, they often create longing for the good old days, which may never had existed. We need to remember that medical records could not continue to exist as paper records written more as reminders than searchable, definitive records.

EHRs have changed provider’s roles. They have to create records not just for themselves, their partners, etc., but also for other providers and analysts they may never meet. As patients, we also need to understand that EHRs, like word processing, cell phones, and the internet itself are far from perfect. Banishing them may allow more personal time for you, but what will it mean for your care, your doctor or for the next patient?

Survey: Physician EHR Satisfaction and EHR Productivity

Posted on July 8, 2015 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.

Chip Hart from Pediatric EHR Solutions sent me the results of the Physicians’ Alliance of America EHR survey results. The chart that’s most interesting to me is this one that shows Productivity Levle with an EHR:
EHR Productivity Chart

If you look at this chart, it clearly illustrates that most doctors see EHR as damaging to their productivity level. No doubt, this chart has a strong connection with why many doctors dislike EHR. However, it’s worth also noting that this chart shows a doctors’ perceived productivity. Many times people think it’s more, but we aren’t great at actually measuring how much time it takes to do something. Plus, most doctors quickly write off the time they spent chasing down charts and other time savings that should also be associated with their productivity. Instead, they just focus on the time spent charting in paper against the time spent charting in an EHR. Unfortunately, there isn’t a really easy way to measure how the actual productivity level changed.

Regardless of whether EHR has really killed productivity level or not, perception is reality and so perception is very important. What’s even more interesting about this chart is that despite the perception that EHR hurts their productivity, 80% of those surveyed said they prefer electronic to paper. This figure seems at odds with the graph above.

I think this illustrates the reality of the future of EHR. It’s not going anywhere. Doctors aren’t leaving EHR to go back to paper. So, now we’re faced with the reality that we need to optimize our current EHR implementations so that they can be a productivity benefit to a practice in both perception and reality. Can we do that with meaningful use stage 3 continuing to kill EHR innovation?

Will Meaningful Use Stage 3 Continue to Kill EHR Innovation?

Posted on July 7, 2015 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.

In my recent post on EMR and HIPAA titled “The Current EHR Reality,” L Parada, a product manager at an EHR vendor, offered this insightful and scary comment:

Looking at the 137 proposed certification requirements for MU3, I again see all innovation in 2016 slipping through the fingers of all specialty EHR companies. That stings.

I’ve occasionally mentioned that we’re finally at a more stable place with meaningful use that EHR vendors might be able to have some breathing room to innovate. Is that time frame for innovation going to be limited to 2015? Will meaningful use stage 3 ruin EHR innovation in 2016? I also don’t think that it just applies to specialty EHR companies either. That many government requirements is going to kill innovation at every EHR company of every size.

This would make me really sad. I’m tired of writing blog posts about the lack of EHR innovation. Can we just let the 300 EHR vendors get to work on listening to their customers and doing some creative solutions to really improve the efficiency of healthcare and improve doctors’ outcomes?

I think we all might feel different if we thought that the meaningful use stage 3 requirements were innovative and really pushing forward amazing initiatives that were going to transform healthcare. I don’t know anyone who really feels that way. At best they see it as a good step forward towards some noble goals. Should we kill innovation in the entire EHR industry for that?

With meaningful use stage 3 around the corner, it’s starting to feel a lot like meaningful use groundhog day. Does it feel that way to anyone else?