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!

Is The ONC Still Relevant?

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

Today, I read an article in Healthcare IT News reporting on the latest word from the ONC. Apparently, during a recent press call, National Coordinator Donald Rucker, MD, gave an update on agency activities without sharing a single new idea.

Now, if I were the head of the ONC, I might do the same. I’m sure it played well with the wire services and daily newspapers reporters, most of whom don’t dig in to tech issues like interoperability too deeply.

But if I were wiseacre health IT blogger (and I am, of course) I’d react a bit differently. By which I mean that I would wonder aloud, very seriously, if the ONC is even relevant anymore. To be fair, I can’t judge the agency’s current efforts by what it said at a press conference, but I’m not going to ignore what was said, either.

According to HIN, the ONC sees developing a clear definition of interoperability, improving EMR usability and getting a better understanding of information blocking as key objectives.

To address some of these issues, Dr. Rucker apparently suggested that using open APIs, notably RESTful APIs like JSON, would be important to future EMR interoperability efforts. Reportedly, he’s also impressed with the FHIR standard, because it’s a modern API and because large vendors have very get some work with the SMART project.

To put it kindly, I doubt any of this was news to the health IT press.

Now, I’m not saying that Dr. Rucker got anything wrong, exactly. It’s hard to argue that we’re far behind when it comes to EMR usability, embarrassingly so. In fact, if we address that issue many of EMR-related efforts aren’t worth much. That being said, much of the rest strikes me as, well, lacking originality and/or substance.

Addressing interoperability by using open APIs? I’m pretty sure someone the health IT business has thought that through before. If Dr. Rucker knows this, why would he present this as a novel idea (as seems to be the case)? And if he doesn’t, is the agency really that far behind the curve?

Establishing full interoperability with FHIR? Maybe, someday. But at least as of a year ago, FHIR product director Grahame Grieve argued that people are “[making] wildly inflated claims about what is possible, [willfully] misunderstanding the limits of the technology and evangelizing the technology for all sorts of ill-judged applications.”  If Grieve thinks people are exaggerating FHIR’s capabilities, does ONC bring anything useful to the table by endorsing it?

Understanding information blocking?  Well, perhaps, but I think we already know what’s going on. At its core, this is a straightforward business use: EMR vendors and many of their customers have an incentive to make health data sharing tough. Until they have a stronger incentive share data, they won’t play ball voluntarily. And studying a much-studied problem probably won’t help things much.

To be clear, I’m relying on HIN as a source of facts here. Also, I realize that Dr. Rucker may have been simplifying things in an effort to address a general audience.

But if my overall impression is right, the news from this press conference isn’t encouraging. I would have hoped that by 2017, ONC would be advancing the ball further, and telling us something we truly didn’t know already. If it’s not sharing new ideas by this point, what good can it do? Maybe that’s why the rumors of HHS budget cuts could hit ONC really hard.

Epic Launches FHIR-Based App Platform

Posted on March 2, 2017 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.

It looks like Epic is getting on the FHIR train. According to an article in Modern Healthcare, Epic is launching a new program – serving physician practices and hospitals – to help them build customized apps. The program, App Orchard, will also support independent mobile app developers who target providers and patients.

The launch follows on the heels of a similar move by Cerner, which set up its own sandbox for developers interested in linking to its EMR using FHIR. The Cerner Open Developer Experience (code_), which launched in early 2016, is working with firms creating SMART on FHIR apps.

App Orchard, for its part, lets developers use a FHIR-based API to access an Epic development sandbox. This will allow the developers to address issues in connecting their apps to the Epic EMR. Previously, Epic wouldn’t let mobile app developers connect to its EMR until a customer requested permission on their behalf.

In addition to providing the API, App Orchard will also serve as an online marketplace along the lines of Google Play or the Apple app store. However, end users won’t be able to download the app for their own use — only software developers and vendors will be able to do that. The idea is that these developers will create the apps on contract to customers.

Meanwhile, according to the magazine, Epic will screen and pick an initial group of developers to the program. Brett Gann, who leads the Epic-based team developing App Orchard, told Modern Healthcare that factors which will distinguish one developer from the other include app safety, security, privacy, reliability, system integrity, data integrity and scalability.

As part of their participation, developers will get documentation listing these criteria and what they mean to Epic. The Epic team will expect the developers to commit to following these guidelines and explain how they’ll do so, Gann said.

While Epic hasn’t made any predictions about what types of apps developers will pursue, recent research offers a clue. According to new research by SMART and KLAS, providers are especially interested in apps that help with patient engagement, EMR data viewing, diagnostics, clinical decision support and documentation tasks.

One thing to watch is how Epic decides to handle licensing, ownership, and charges for participation in their Orchard Program. If they have a true open API, then this will be a good move for the industry. If instead they choose to take ownership of everything that’s created, put restrictive licenses on developers, and/or charge huge sums to participate, then it’s unlikely to see much true innovation that’s possible with an open API. We’ll see how that plays out.

Meanwhile, in other Epic news, Becker’s Hospital Review notes that the vendor is planning to develop two additional versions of its EMR. Adam Whitlatch, a lead developer there, told the site that the new versions will include a mid-range EMR with fewer modules (dubbed “utility”), and a slimmer version with fewer modules and advanced features, to be called “Sonnet.”

Whitlatch said the new versions will target physician practices and smaller hospitals, which might prefer a lower-cost EMR that can be implemented more quickly than the standard Epic product. It’s also worth noting that the two new EMR versions will be interoperable with the traditional Epic EMR (known as “all-terrain”).

All told, these are intriguing developments which could have an impact on the EMR industry as a whole.

On the one hand, not only is Epic supporting the movement towards interchangeable apps based on FHIR, it appears that the vendor has decided to give in to the inevitable and started to open up its platform (something it hasn’t done willingly in the past).  Over time, this could affect providers’ overall Epic development plans if Epic executes it well and enables innovation on Orchard and doesn’t restrict it.

Also, the new versions of the Epic could make it available to a much wider audience, particularly if the stripped-down versions are significantly cheaper than its signature EMR. In fact, an affordable Epic EMR could trigger a big shakeup in the ambulatory EMR market.

Let’s see if more large EMR vendors decide to offer an open API. If access to EMR APIs became common, it would represent a major shift in the whole health IT ecosystem.

Big Hairy Audacious Goals for Healthcare IT (and some small ones too) – #HITsm Chat Recap and Commentary

Posted on January 17, 2017 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.

As we’ve been doing the past few weeks, we’re excited to do a bit of a recap and commentary on last week’s #HITsm chat. For those who missed it, we talked about 2017 Goals for Healthcare IT. We started off with the famous Big Hairy Audacious Goals (BHAG) idea which made for some interesting conversation. You can find the full #HITsm tanscript for this chat on Symplur.

There was a wide ranging discussion over the hour, but a certain emphasis on more empowered patients. Here’s a look at some of the interesting ideas and our own commentary on what they tweeted.


It’s sad that this is a BHAG, but it certainly is a challenging goal given the disconnected nature of our healthcare system. Not to mention perverse incentives which make sharing healthcare data difficult to achieve.


The last line of this tweet really captured me. It certainly feels like much of healthcare is more beholden to the CFO than to the patient. That’s brutal for me to even type and is far too close to reality. Does anyone see this changing in the near future?


I’m not sure if these classify as BHAGs or not. They sure feel like they won’t happen despite a lot of people interested in them becoming a reality.


Make healthcare easier? Fascinating to think about. I wonder what cost we pay because healthcare is so hard.


This is a definite BHAG. What’s extraordinary is to start thinking about the innovation that could occur if this was a reality.


I’d like to dig into this one more. Greg certainly knows a lot more about CCDA and FHIR than I do. This is a sad sign for the potential of FHIR going forward.


Topic 2 was about smaller goals that healthcare IT could achieve. I like this one from Max. It highlights a real challenge with how most EHR software programs were implemented. They were done in such a rush that most people were just training for competence. Is it any wonder that many EHR users are unsatisfied? I wonder if training them with quality in mind would change their views of EHRs.


I shouldn’t be shocked, but I’m always surprised by how valuable improving communication can be. I think that’s true in every industry and many parts of life. However, Steve’s suggestion for healthcare is a good one and would likely provide tremendous benefit.


I wonder if this goal should have been under the BHAG section of the chat and not the “simple” goals section. The problem with this idea is that in many cases HIT has been part of the problem. We need to fix that and ensure that HIT is a solution for the majority of people who use it.


I don’t see this changing, but I think it’s part of the problem. I’m always torn when I see this big party and ribbon cutting at the opening of a new hospital. Shouldn’t we be sad that they needed more beds? Shouldn’t we be celebrating when health is so improved that hospitals needed to shut down because they didn’t have enough business?


This relates to the tweet above it. We want lower costs, but who wants to get paid less?


This is very true. And I think heatlhcare IT vendors could do more than they’re doing today. Many are just coasting. Plus, all of them have been distracted by so many government regulations. Is it time to just leave health IT vendors alone for a bit to let them innovate?


Should be a fun chat. Always good to get new perspectives on learning and engagement. See you at next week’s #HITsm chat.

A Circular Chat On Healthcare Interoperability

Posted on September 6, 2016 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.

About a week ago, a press release on health data interoperability came into my inbox. I read it over and shook my head. Then I pinged a health tech buddy for some help. This guy has seen it all, and I felt pretty confident that he would know whether there was any real news there.

And this is how our chat went.

—-

“So you got another interoperability pitch from one of those groups. Is this the one that Cerner kicked off to spite Epic?” he asked me.

“No, this is the one that Epic and its buddies kicked off to spite Cerner,” I told him. “You know, health data exchange that can work for anyone that gets involved.”

“Do you mean a set of technical specs? Maybe that one that everyone seems to think is the next big hope for application-based data sharing? The one ONC seems to like.” he observed. “Or at least it did during the DeSalvo administration.”

“No, I mean the group working on a common technical approach to sharing health data securely,” I said. “You know, the one that lets doctors send data straight to another provider without digging into an EMR.”

“You mean that technology that supports underground currency trading? That one seems a little bit too raw to support health data trading,” he said.

“Maybe so. But I was talking about data-sharing standards adopted by an industry group trying to get everyone together under one roof,” I said. “It’s led by vendors but it claims to be serving the entire health IT world. Like a charity, though not very much.”

“Oh, I get it. You must be talking about the industry group that throws that humungous trade show each year.” he told me. “A friend wore through two pairs of wingtips on the trade show floor last year. And he hardly left his booth!”

“Actually, I was talking about a different industry group. You know, one that a few top vendors have created to promote their approach to interoperability.” I said. “Big footprint. Big hopes. Big claims about the future.”

“Oh yeah. You’re talking about that group Epic created to steal a move from Cerner.” he said.

“Um, sure. That must have been it,” I told him. “I’m sure that’s what I meant.”

—-

OK, I made most of this up. You’ve got me. But it is a pretty accurate representation of how most conversations go when I try to figure out who has a chance of actually making interoperability happen. (Of course, I added some snark for laughs, but not much, believe it or not.)

Does this exchange sound familiar to anyone else?

And if it does, is it any wonder we don’t have interoperability in healthcare?

What Do Med Students Need To Know About EMRs?

Posted on August 16, 2016 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.

Recently, I was asked to write an introduction to EMRs, focusing on what medical students needed to know in preparation for their future careers. This actually turned out to be a very interesting exercise, as it called for balancing history with the future, challenges with benefits and predictable future developments with some very interesting possibilities. Put another way, the exercise reminded me that any attempt to “explain” EMR technology calls for some fancy dancing.

Here’s some of the questions I tackled:

  • Do future doctors need to know more about how EMRs function today, or how they should probably function to support increasingly important patient management approaches like population health?
  • Do med students need to understand major technical discussions – such as the benefits of FHIR or how to wrangle Big Data – to perform as doctors? If so, how much detail is helpful?
  • How important is it to prepare med students to understand the role of data generated outside of traditional patient care settings, such as wearables data, remote monitoring and telemedicine consults? What do they need to know to prepare for the gradual integration of such data?
  • What skills, attitudes and practices will help physician trainees make the best use of EMRs and ancillary systems? And how should they obtain that knowledge?

These questions are thornier than they may appear at first glance, in part because there no hard-and-fast standards in place as to how doctors who’ve never run a practice on paper charts should conduct themselves. While there have been endless discussions about how to help doctors adopt an EMR for the first time, or switch from one to the other, I’m not aware of a mature set of best practices available to med students on how next-gen, health IT-assisted practices should function.

Certainly, offering med school trainees a look at the history of EMRs makes sense, as understanding the reasons early innovators developed the first systems offers some interesting insights. And introducing soon-to-be physicians to the benefits of wearable or remote monitoring data makes sense. Physicians will almost certainly improve the care they deliver by understanding EMRs then, now and their near-term evolution as data sources.

On the other hand, I’m not sure it makes sense to indoctrinate med students in today’s take on evolving topics like population health management or interoperability via FHIR. These paradigms are evolving so rapidly that pinning down a set of teachable ideas may be a disservice to these students.

Morever, telling students how to think about EMRs, or articulating what skills are needed to manage them, might actually be a bad idea. I’m optimistic enough to think that now that the initial adoption frenzy funded by HITECH is over, EMRs will become far more usable and physician-shapeable over the next few years, allowing new docs to adapt the tool to them rather than adapt to the tool.

All that being said, educating med students on EMRs and health IT ancillary tools is a great idea. I just hope that such training encourages them to keep learning well after the training is over.

New ONC Scorecard Tool Grades C-CDA Documents

Posted on August 2, 2016 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.

The ONC has released a new scorecard tool which helps providers and developers find and resolve interoperability problems with C-CDA documents. According to HealthDataManagement, C-CDA docs that score well are coded with appropriate structure and semantics under HL7, and so have a better chance of being parseable by different systems.

The scorecard tool, which can be found here, actually offers two different types of scores for C-CDA documents, which must be uploaded to the site to be analyzed. One score diagnoses whether the document meets the requirements of the 2015 Edition Health IT Certification for Transitions of Care, granting a pass/fail grade. The other score, which is awarded as a letter grade ranging from A+ to D, is based on a set of enhanced interoperability rules developed by HL7.

The C-CDA scorecard takes advantage of the work done to develop SMART (Substitutable Medical Apps Resusable Technologies). SMART leverages FHIR, which is intended to make it simpler for app developers to access data and for EMR vendors to develop an API for this purpose. The scorecard, which leverages open-source technology, focuses on C-CDA 2.1 documents.

The SMART C-CDA scorecard was designed to promote best practices in C-CDA implementation by helping creators figure out how well and how often they follow best practices. The idea is also to highlight improvements that can be made right away (a welcome approach in a world where improvement can be elusive and even hard to define).

As SMART backers note, existing C-CDA validation tools like the Transport Testing Tool provided by NIST and Mode-Driven Health Tools, offer a comprehensive analysis of syntactic conformance to C-CDA specs, but don’t promote higher-level best practices. The new scorecard is intended to close this gap.

In case developers and providers have HIPAA concerns, the ONC makes a point of letting users know that the scorecard tool doesn’t retain submitted C-CDA files, and actually deletes them from the server after the files have been processed. That being said, ONC leaders still suggest that submitters not include any PHI or personally-identifiable information in the scorecards they have analyzed.

Checking up on C-CDA validity is becoming increasingly important, as this format is being used far more often than one might expect. For example, according to a story appearing last year in Modern Healthcare:

  • Epic customers shared 10.2 million C-CDA documents in March 2015, including 1.3 million outside the Epic ecosystem (non-Epic EMRs, HIEs and the health systems for the Defense and Veterans Affairs Departments)
  • Cerner customers sent 7.3 million C-CDA docs that month, more than half of which were consumed by non-Cerner systems.
  • Athenahealth customers sent about 117,000 C-CDA documents directly to other doctors during the first quarter of 2015.

Critics note that it’s still not clear how useful C-CDA information is to care, nor how often these documents are shared relative to the absolute number of patient visits. Still, even if the jury is still out on their benefits, it certainly makes sense to get C-CDA docs right if they’re going to be transmitted this often.

No, The Market Can’t Solve Health Data Interoperability Problems

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

I seldom disagree with John Halamka, whose commentary on HIT generally strikes me as measured, sensible and well-grounded. But this time, Dr. Halamka, I’m afraid we’ll have to agree to disagree.

Dr. Halamka, chief information officer of Beth Israel Deaconess Medical Center and co-chair of the ONC’s Health IT Standards Committee, recently told Healthcare IT News that it’s time for ONC and other federal regulators to stop trying to regulate health data interoperability into existence.

“It’s time to return the agenda to the private sector in the clinician’s guide vendors reduce the products and services they want,” Halamka said. “We’re on the cusp of real breakthroughs in EHR usability and interoperability based on the new incentives for outcomes suggested by MACRA and MIPS. {T}he worst thing we could do it this time is to co-opt the private sector agenda more prescriptive regulations but EHR functionality, usability and quality measurement.”

Government regs could backfire

Don’t get me wrong — I certainly appreciate the sentiment. Government regulation of a dynamic goal like interoperability could certainly backfire spectacularly, if for no other reason than that technology evolves far more quickly than policy. Regulations could easily set approaches to interoperability in stone that become outmoded far too quickly.

Not only that, I sympathize with Halamka’s desire to let independent clinical organizations come together to figure out what their priorities are for health data sharing. Even if regulators hire the best, most insightful clinicians on the planet, they still won’t have quite the same perspective as those still working on the front lines every day. Hospitals and medical professionals are in a much better position to identify what data should be shared, how it should be shared and most importantly what they can accomplish with this data.

Nonetheless, it’s worth asking what the “private sector agenda” that Halamka cites is, actually. Is he referring to the goals of health IT vendors? Hospitals? Medical practices? Health plans? The dozens of standards and interoperability organization that exist, ranging from HL7 and FHIR to the CommonWell Health Alliance? CHIME? HIMSS? HIEs? To me, it looks like the private sector agenda is to avoid having one. At best, we might achieve the United Nations version of unity as an industry, but like that body it would be interesting but toothless.

Patients ready to snap

After many years of thought, I have come to believe that healthcare interoperability is far too important to leave to the undisciplined forces of the market. As things stand, patients like me are deeply affected by the inefficiencies and mistakes bred by the healthcare industry’ lack of interoperability — and we’re getting pretty tired of it. And readers, I guarantee that anyone who taps the healthcare system as frequently as I do feels the same way. We are on the verge of rebellion. Every time someone tells me they can’t get my records from a sister facility, we’re ready to snap.

So do I believe that government regulation is a wonderful thing? Certainly not. But after watching the HIT industry for about 20 years on health data sharing, I think it’s time for some central body to impose order on this chaos. And in such a fractured market as ours, no voluntary organization is going to have the clout to do so.

Sure, I’d love to think that providers could pressure vendors into coming up with solutions to this problem, but if they haven’t been able to do so yet, after spending a small nation’s GNP on EMRs, I doubt it’s going to happen. Rather than fighting it, let’s work together with the government and regulatory agencies to create a minimal data interoperability set everyone can live with. Any other way leads to madness.

How Open mHealth Designed a Popular Standard (Part 3 of 3)

Posted on December 3, 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://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The first section of this article introduced the common schemas for mobile health designed by Open mHealth, and the second section covered the first two design principles driving their schemas. We’ll finish off the design principles in this section.

Balancing permissiveness and constraints

Here, the ideal is to get accurate measurements to the precision needed by users and researchers. But many devices are known to give fuzzy results, or results that are internally consistent but out of line with absolute measurements.

The goal adopted by Open mHealth is to firm up the things that are simple to get right and also critical to accuracy, such as units of measurement discussed earlier. They also require care in reporting the time interval that a measurement covers: day, week, month. There’s no excuse if you add up the walks recorded for the day and the sum doesn’t match the total steps that the device reports for that day.

Some participants suggested putting in checks, such as whether the BMI is wildly out of range. The problem (in terms of public health as well as technology) is that there are often outlier cases in health care, and the range of what’s a “normal” BMI can change. The concept of a maximum BMI is therefore too strict and ultimately unhelpful.

Designing for data liquidity

Provenance is the big challenge here: where does data come from, how was it collected, and what algorithm was used to manipulate it? Open mHealth expects data to go far and wide among researchers and solution providers, so the schema must keep a trail of all the things done to it from its origin.

Dr. Sim said the ecosystem is not yet ready to ensure quality. For instance, a small error introduced at each step of data collection and processing can add up to a yawning gap between the reported measure and the truth. This can make a difference not only to researchers, but to the device’s consumers. Think, for instance, of a payer basing the consumer’s insurance premium on analytics performed on data from the device over time.

Alignment with clinical data standards

Electronic health records are starting to accept medical device data. Eventually, all EHRs will need to do this so that monitoring and connected health can become mainstream. Open mHealth adopted widespread medical ontologies such as SNOMED, which may seem like an obvious choice but is not at all what the devices do. Luckily, Open mHealth’s schemas come pre-labelled with appropriate terminology codes, so device developers don’t need to get into the painful weeds of medical coding.

Modeling of Time

A seemingly simple matter, time is quite challenging. The Open mHealth schema can represent both points in time and time intervals. There are still subtleties that must be handled properly, as when a measurement for one day is reported on the next day because the device was offline. These concerns feed into provenance, discussed under “Designing for data liquidity.”

Preliminary adoption is looking good. The schema will certainly evolve, hopefully allowing for diversity while not splintering into incompatible standards. This is the same balance that FHIR must strike under much more difficult circumstances. From a distance, it appears like Open mHealth, by keeping a clear eye on the goal and a firm hand on the development process, have avoided some of the pitfalls that the FHIR team has encountered.

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://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.

The Tower of EMR Babel

Posted on May 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.

It’s the sad state of interoperability. This week when I was teaching an EHR workshop I asked for those attending to define what an Electronic Health Record was in their own words. I’d say 90% of them said something about making the healthcare data available to be shared or some variation on that idea. This wasn’t surprising for me since I’ve heard hundreds and possibly thousands of doctors say the same thing. EHR is suppose to make it so we can share data.

While people pay lip service to this idea and just assume that somehow EHR would make data sharing possible, that’s far from the reality today. This is true even in some organizations where they own both the hospital and the ambulatory provider. How sad is this? Extremely sad in my book.

I’ve often wondered what would change the tide. I’ve been long hopeful that ACOs and value based care would help to push the data sharing forward, but that’s going to be a long process. The private HIEs are working the best of any HIEs I’ve seen, so maybe the trend of hospitals acquiring small practices and hospital systems acquiring hospital systems will get us to EHR data sharing nirvana. Although, I don’t think it’s going to make it there in most communities. Instead it’s just going to have a number of large organizations not wanting to share data as opposed to some large and some small ones.

Do people really have much hope for true EHR data sharing? Does FHIR give you this hope? I’m personally not all that optimistic. We all know it’s the right thing to do, but there are some powerful forces fighting against us.