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!

The Power of Saying “I Don’t Know”

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

Somewhere in our culture we decided that you were incompetent if you said “I Don’t Know.” It’s unfortunate, because it’s created a society that often fakes it when they shouldn’t. That can lead to dire consequences. There’s a real power in saying “I Don’t Know” and we should embrace it. This is true for everyone, but particularly doctors. Here’s an excerpt from an article that talked about this phrase:

As physicians, we aim for perfection. We want to have all the answers. All the time. Especially standing at the front of a room full of more junior learners. But that’s not real life. Every day, we see patients that give us cause to look up something or consult a colleague. This uncertainty and life-long learning needs to be built into, and even explicitly role-modelled in teaching. Not only is it not feasible nor realistic to be prepared for every clinical teaching session, it frankly looks pretty fake when it’s attempted. Sure, every medical resident should have the management of common life threatening problems like seizures and hyperkalemia at their fingertips (which no chief resident would need to prepare in advance), but the diagnostic criteria for rare diseases can (and should) be looked-up rather than portrayed as something that people should just know.

Often, one of the most powerful teaching points that can be made during clinical teaching is to say, “I don’t know.” Not only will it make people appreciate you for your honesty; but it also permits the more junior learner to feel less anxious and less alone.

I still remember my first real job out of college. I was hired to essentially be a backup to everything that my boss did. They wanted her to be able to take a vacation and so I needed to be able to do anything that she could do (sounds a bit like what doctors are required to do when they enter the field). On one of my first days someone came in with a major problem and I had no idea how to solve it. I turned to my boss and asked her how to solve it. I was a bit stressed and worried about getting it fixed. She calmly told me, “John, I don’t know how to fix it…but we’ll figure it out.”

That one moment taught me a great lesson in life. You don’t have to know everything. It’s ok to say I don’t know and you can work to find a solution to the problem.

We should have this expectation from our doctors. They may not know the answer right off the top of their head. We should be ok with that and ok with them making sure they give us the best answer possible. I remember a doctor once telling me that the body of medical knowledge is so big that it’s impossible for the human mind to know it all. What does that mean? It means that there are plenty of cases where the doctor should say that they don’t know and we should be ok with that. It also means that we should leverage technology to help doctors find the answers to those challenging questions.

As the article states, being able to say “I Don’t Know” shouldn’t let doctors (or us in our own lives) not know how to handle common problems. We need a baseline of understanding and not knowing some things is incompetence and you can’t shield yourself from incompetence with the phrase “I Don’t Know.” If you do, that will definitely catch up to you.

It’s a powerful thing to say “I don’t know, but I’ll figure it out.”

What Are You Doing To Protect Your Organization Against Your Biggest Security Threat? People

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


This was a great tweet coming out of the HIM Summit that’s run by HealthPort. I agree with the comment 100%. Sure, we see lots of large HIPAA breaches that make all the news. However, I bet if we looked at the total number of breaches (as opposed to patient records breached), the top problem would likely be due to the people in an organization. Plus, they’re the breaches that are often hardest to track.

What’s the key to solving the people risk when it comes to privacy and security in your organization? I’d start with making security a priority in your organization. Many healthcare organizations I’ve seen only pay lip service to privacy and security. I call it the “just enough” approach to HIPAA compliance. The antithesis of that is a healthcare organization that’s create a culture of compliance and security.

Once you have this desire for security and privacy in your organization, you then need to promote that culture across every member of your organization. It’s not enough to put that on your chief security officer, chief privacy officer, or HIPAA compliance officer. Certainly those people should be advocating for strong security and privacy policies and procedures, but one voice can’t be a culture of compliance and security. Everyone needs to participate in making sure that healthcare data is protected. You’re only as strong as your weakest link.

One of the attendees at the session commented that she’d emailed her chief security officer about some possible security and compliance issues and the chief security officer replied with a polite request about why this HIM manager cared and that the HIM manager should just let her do her job. Obviously I’m summarizing, but this response is not a surprise. People are often protective of their job and afraid of comments that might be considered as a black mark on the work they’re doing. While understandable, this illustrates an organization that hasn’t created a culture of security and compliance across their organization.

The better response to these questions would be for the chief security officer to reply with what they’ve done and to outline ways that they could do better or the reasons that their organization doesn’t have the ability to do more. The HIM manager should be thanked for taking an interest in security and compliance as opposed to being shot down when the questions are raised. It takes everyone on board to ensure compliance and security in a healthcare organization. Burning bridges with people who take an interest in the topic is a great way to poison the culture.

Those are a few suggestions about where to start. It’s not easy work. Changing a culture never is, but it’s a worthwhile endeavor. Plus, this work is a lot better than dealing with the damaged reputation after a security breach.

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.

Medical Tourism Infographic

Posted on July 24, 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 wonder how many healthcare organizations are thinking about medical tourism. I know there’s quite a bit of discussion about it in Las Vegas where I live. I know some practices that make a killing off of medical tourism. As you can imagine, the biggest medical tourism in Las Vegas is around your appearance (plastics, bariatrics, spas, etc). Vegas happens to be a great thing for all of those with some of the leading experts. It doesn’t hurt that it has cheap flights from everywhere and great hotels to stay in while you recover.

The medical tourism topic is unique to each locale. However, what does apply everywhere is that patients are seeking out the best and cheapest care they can find. That often includes travel out of state or out of country.

With this in mind, I was intrigued by this Medical Tourism Infographic put together by PreTaxHealth. It offers some interesting insights into the medical tourism industry.
Medical Tourism and the Cost of Healthcare Technology

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.

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.