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!

Will We Need Billing Codes Once We Have Nice Structured EHR Clinical Data?

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

I had a really fascinating discussion recently with @AlexHBurgess where we discussed the role of billing codes in an EHR today and also the future of billing codes as EHR notes get much better and more granular. This is particularly interesting to me as I’m at the HealthPort HIM Summit the next couple days.

Here’s the question that started the conversation:

This was @AlexHBurgess’s response:

And then I replied:

The last question is something worth chewing on. I’ll have to ask it of a few HIM managers the next couple days. I think the simple answer is that we’ll still likely need billing codes. I don’t think that our payers are forward thinking enough or at least progressive enough to try and push forward a non-billing code reimbursement system. It’s pretty interesting to think about though.

The second reason I don’t think it’s likely to happen is that the data in the EHR will likely not be good enough. Although, if the data in the EHR (and not just the billing codes that were selected) were how you got paid, then you’d see a dramatic improvement in the quality of the EHR data. So, maybe it’s not a bad idea after all. I’m pretty sure my medical billing friends would scoff at this idea as they think about the number of times they’ve had to have doctors correct something in the paper chart to make sure the billing was ok.

Long story short, I think that you could theoretically get rid of medical billing codes and just use EHR data for reimbursement. However, in practice I don’t really see this ever becoming a reality. At least not in the short to medium term.

If EHR Had a Tech Problem We’d Blame the Vendors

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

During last week’s #KareoChat, the chat host @GabrielSPerna offered the following tweets from the @PhysiciansPract account for which he is now managing editor (Gabriel Perna was formerly @HCInformatics):

When I saw this tweet, I knew I needed some time to chew on the concept. Do we really blame our vendor when it’s a tech problem? I’m reminded of a time my EHR software ran out of control and was literally chewing up RAM and never spitting it out. I’d restart the server and we’d be fine until the EHR software had chewed up all the RAM again and then the EHR was slow as molasses. You can bet I was blaming my EHR vendor for the tech problems we were having.

However, did I blame them for our cultural challenges as well? I guess the key term there for me is “blame.” I know many practices (and have heard of others) who have switched EHR vendors 3, 4, even 5 times. They loved to blame the previous EHR vendors for their problems. However, by the 2nd or third, you can be sure there are some cultural problems there that need to be resolved. As much as they want to blame the EHR vendor they’re likely not to blame.

Another tweet from today’s #KareoChat seems to also illustrate the challenge is cultural and not technical:

I can already hear Dr. Tom in his EHR product management meetings asking why they’re building a certain feature into the software when it supports a flawed process. The developers respond that it’s what the customer wants. This highlights a major cultural problem.

Back to the original discussion. The fact that many doctors haven’t seen an ROI from their EHR, but less than 20% are dissatisfied with their EHR vendor does seem to say that most EHR vendors have not had tech issues. Instead the EHR dissatisfaction likely stems from a lot of other cultural problems in healthcare.

All of this reminds me of some old posts where I asked “Can An EMR Focus on Patient Care in the Current Reimbursement Environment?” and what would an EHR look like if it was focused on customer requests and not MU? Is the healthcare culture what has created these less than happy EHR users or is that letting the EHR vendors off the hook?

How Does Your EHR Vendor Solve Challenging Situations?

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

Today I was asked if I thought a specific EHR feature (in this case it was cloud hosted) was one area practices should consider looking at to avoid having a short sighted view of their EHR vendor. The specific feature and question are interesting, but I think it’s a short sighted way to look at an EHR vendor.

My immediate response was that when I look at an EHR vendor, I look at how they solve challenging situations and if they’re still solving those problems. I’m more interested in the EHR vendors direction and approach than I am any specific feature or function they offer today.

Let’s take them in the inverse order. Is your EHR vendor still solving your problems? This is a hard one to evaluate since meaningful use and EHR certification has hijacked the EHR development process. However, when you dig into an EHR vendor you can tell which ones are really investing in improving their platform and which ones are just doing the minimum necessary to retain their customers. It’s a totally different mindset. A forward thinking EHR vendor is trying to push the envelope, is interested in user feedback and is working towards a brighter future. An EHR vendor that’s doing the minimum necessary is just barely meeting the EHR certification and meaningful use requirements and never really responds to customer requests. Sure, they’ll do a bug fix here or there or fix anything major, but there’s no real investment in the future.

One easy way for you to start evaluating which vendors are investing in their future and which aren’t is to talk to their sales people. Does the salesperson have something new to sell you (like RCM or some other service)? If they do, it’s quite possible your EHR vendor has started focusing (and investing) on some new product and not the EHR anymore. Just remember that it’s really hard for a company to focus and invest in more than one area.

Sadly, I think many EHR users know that their EHR vendor has stopped innovating their product. They know this based on the release cycles of the EHR vendor. When was the last time your EHR vendor put out something that made your life as a clinician or a practice easier and it didn’t have to do with MU?

Related to the above is something that’s even more telling when it comes to the future of your EHR. Ask yourself the question, how does my EHR vendor approach solving challenging situations? If you talk to a lot of EHR vendors like I do, you can pretty quickly tell how an EHR vendor approaches problems. Unfortunately, many of them do the minimum work possible to solve the problem. The best EHR vendors dive deeply into the problem and not only solve the problem, but try to think of a better way to optimize everything surrounding the problem.

I still remember sitting down with an EHR vendor for breakfast one day. As they described their ePrescribing solution, they described how they could have implemented ePrescribing really quickly. However, they didn’t just want to have ePrescribing. They wanted to take the time to really understand ePrescribing and ensure that the doctor could ePrescribe with as few clicks as possible. They wanted to make sure that the process was efficient and accurate. It wasn’t enough to just be able to ePrescribe, but they wanted their doctors to be efficient while doing it too.

Reminds me of many of the ICD-10 implementations I’ve seen. I’d describe EHR vendor implementations as ok, better, and best. The “ok” implementation is that they have a search box which can search by word or code. Theoretically, this works. It just means you’re going to have a big book next to you or an app on your phone which lets you really find the code and then all you’re doing is entering the code. Not good!

The “better” implementation is the vendors that group codes so that when you search you can choose the group of codes and then essentially drill down into the group and find the code you need. In most cases, I’ve seen this type of implementation done by integrating a third party vendor. The EHR vendor often passes that third party cost on to the end user (imagine that). I’ll admit that a third party vendor integration for this feels kine of lazy. I’m all for third party integrations, but your EHR vendor won’t ever be able to take coding to the next level if they’re working with a third party. This kind of “grouping” approach is better, but it’s not the best.

The best type of ICD-10 implementation I’ve seen is one that integrates deeply into the EHR documentation. The documentation essentially narrows down the ICD-10 code list for you as you document the visit. Then, when it’s time to do your assessment, the hard work of identifying the right codes is already done for you. Sure, you’ll need to verify that the machine approach to ICD-10 identification is right, but it’s the best approach I’ve seen to ICD-10.

Hopefully this ICD-10 example gives you a view into what I mean when I say that you have to evaluate how an EHR vendor works to solve a problem. Are they just trying to get by or do they take their solution to the next level of automation? I feel sorry for the doctors who are stuck on EHR software that’s no longer investing in their EHR and just take the minimal necessary approach to EHR development.

Going back to the person’s initial question about cloud hosted EHR, it’s easy today to say that every EHR vendor should be on the cloud. The cloud has won in every industry and it will eventually win in healthcare as well. However, cloud or not is not what concerns me. I’d be more interested in hearing an EHR vendors reason for going cloud or not. Not to mention their reasons for moving to cloud or not. That will tell you how an EHR solves a problem and how an EHR works with new technology. Their direction and approach to those challenges is much more important than the specific choice they make.

Are We Short Sighted in Ambulatory?

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

I was recently having a conversation with Susan Clark from eHealthcare Consulting and we were talking about the ambulatory world and what makes it unique. I commented to her that many in ambulatory are just trying to survive and so they want the simplest, cheapest solution possible. She then commented that many of them make very short sighted decisions.

I thought the comment was fascinating since I’ve seen this happen over and over again in the ambulatory world. There are some exceptions, but for the most part I’ve seen many in the ambulatory environment want the quick, dirty, easy solution as opposed to making a long term decision that will pay long term benefits.

Since I live in the EHR world, that’s where I’ve seen it most. In fact, I think it’s why we’re heading into the next generation of EHR switching. Many doctors chose the cheap and easy way out with their EHR (which wasn’t always that cheap) and now they’re paying the price as they have to switch EHR vendors.

The sad part is that many of them actually spent a lot more on their EHR thinking that it was a great long term investment when in fact the great long term investment would have been to spend more time evaluating, planning, and implementing the right EHR in the right way. Instead they just threw money at the most expensive EHR with the idea that if it costs more it must be better. Sadly, many of the high end EHR brands haven’t lived up to their high end price tag. In fact, many doctors would have been much happier to go with the less expensive mid-tier EHR vendor that worked better with their practice and their workflow.

This brings up a key point in an ambulatory practices decision making. Long term decision making doesn’t mean that you always have to pay more money for something up front. However, it almost always means you have to spend more time and energy up front evaluating the decision. That extra time and energy has a cost, but it pays big dividends long term. However, I think Susan Clark’s right that there’s far too many ambulatory practices who are short sighted and don’t want to make that kind of investment.

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.

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?