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 HIPAA for FREE!!

Don’t Yell FHIR in a Hospital … Yet

Posted on November 30, 2016 I Written By

The following is a guest blog post by Richard Bagdonas, CTO and Chief Healthcare Architect at MI7.
richard-bagdonas
The Fast Healthcare Interoperability Resource standard, commonly referred to as FHIR (pronounced “fire”) has a lot of people in the healthcare industry hopeful for interoperability between the electronic health record (EHR) systems and external systems — enabling greater information sharing.

As we move into value-based healthcare and away from fee-for-service healthcare, one thing becomes clear: care is no longer siloed to one doctor and most certainly not to one facility. Think of the numerous locations a patient must visit when getting a knee replaced. They start at their general practitioner’s office, then go to the orthopedic surgeon, followed by the radiology center, then to the hospital, often back to the ortho’s office, and finally to one or more physical therapists.

Currently the doctor’s incentives are not aligned with the patient. If the surgery needs to be repeated, the insurance company and patient pay for it again. In the future the doctor will be judged and rewarded or penalized for their performance in what is called the patient’s “episode of care.” All of this coordination between providers requires the parties involved become intimately aware of everything happening at each step in the process.

This all took off back in 2011 when Medicare began an EHR incentive program providing $27B in incentives to doctors at the 5,700 hospitals and 235,000 medical practices to adopt EHR systems. Hospitals would receive $2M and doctors would receive $63,750 when they put in the EHR system and performed some basic functions proving they were using it under what has been termed “Meaningful Use” or MU.

EHR manufacturers made a lot of money selling systems leveraging the MU incentives. The problem most hospitals ran into is their EHR didn’t come with integrations to external systems. Integration is typically done using a 30 year old standard called Health Level 7 or HL7. The EHR can talk to outside systems using HL7, but only if the interface is turned on and both systems use the same version. EHR vendors typically charge thousands of dollars and sometimes tens of thousands to turn on each interface. This is why interface engines have been all the rage since they turn one interface into multiple.

The great part of HL7 is it is standard. The bad parts of HL7 are a) there are 11 standards, b) not all vendors use all standards, c) most EHRs are still using version 2.3 which was released in 1997, and d) each EHR vendor messes up the HL7 standard in their own unique way, causing untold headaches for integration project managers across the country. The joke in the industry is if you have seen one EHR integration, you’ve seen “just one.”

image-1
HL7 versions over the years

HL7 version 3.0 which was released in 2005 was supposed to clear up a lot of this integration mess. It used the Extensible Markup Language (XML) to make it easier for software developers to parse the healthcare messages from the EHR, and it had places to stick just about all of the data a modern healthcare system needs for care coordination. Unfortunately HL7 3.0 didn’t take off and many EHRs didn’t build support for it.

FHIR is the new instantiation of HL7 3.0 using JavaScript Object Notation (JSON), and optionally XML, to do similar things using more modern technology concepts such as Representation State Transfer (REST) with HTTP requests to GET, PUT, POST, and DELETE these resources. Developers love JSON.

FHIR is not ready for prime time and based on how HL7 versions have been rolled out over the years it will not be used in a very large percentage of the medical facilities for several years. The problem the FHIR standard created is a method by which a medical facility could port EHR data from one manufacturer to another. EHR manufacturers don’t want to let this happen so it is doubtful they will completely implement FHIR — especially since it is not a requirement of MU.

And FHIR is still not hardened. There have been fifteen versions of FHIR released over the last two years with six incompatible with earlier versions. We are a year away at best from the standard going from draft to release, so plan on there being even more changes.

image-2
15 versions of FHIR since 2014 with 6 that are incompatible with earlier versions

Another reason for questioning FHIR’s impact is the standard has several ways to transmit and receive data besides HTTP requests. One EHR may use sockets, while another uses file folder delivery, while another uses HTTP requests. This means the need for integration engines still exists and as such the value from moving to FHIR may be reduced.

Lastly, the implementation of FHIR’s query-able interface means hospitals will have to decide if they must host all of their data in a cloud-based system for outside entities to use or become a massive data center running the numerous servers it will take to allow patients with mobile devices to not take down the EHR when physicians need it for mission-critical use.

While the data geek inside me loves the idea of FHIR, my decades of experience performing healthcare integrations with EHRs tell me there is more smoke than there is FHIR right now.

My best advice when it comes to FHIR is to keep using the technologies you have today and if you are not retired by the time FHIR hits its adoption curve, look at it with fresh eyes at that time. I will be eagerly awaiting its arrival, someday.

About Richard Bagdonas
Richard Bagdonas has over 12 years integrating software with more than 40 electronic health record system brands. He is an expert witness on HL7 and EDI-based medical billing. Richard served as a technical consultant to the US Air Force and Pentagon in the mid-1990’s and authored 4 books on telecom/data network design and engineering. Richard is currently the CTO and Chief Healthcare Architect at MI7, a healthcare integration software company based in Austin, TX.

Time To Treat Telemedicine as Just “Medicine”

Posted on October 25, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Over the last year or two, hospitals and clinics have shown a steadily growing interest in offering telemedicine services. Certainly, this is in part due to the fact that health plans are beginning to pay for telehealth consults, offering a new revenue stream that providers want to capture, but there’s more to consider here.

Until recently, much of the discussion around telehealth centered on how to get health insurance companies to pay for it. But now, as value-based purchasing becomes more the norm, providers will need to look at telemedicine as a key tool for managing patient health more effectively.

Evidence increasingly suggests that making providers available via telemedicine channels can help better manage chronic conditions and avert needless hospitalizations, both of which, under value-based payments, are more important than getting a few extra dollars for a consult.

Looked at another way, the days of telehealth being a boutique service for more-sophisticated consumers are ending. “It’s time to treat telemedicine as just ‘medicine,’” one physician consultant told me. “It’s no different than any other form of medicine.”

As reasons for treating telehealth as a core clinical service increase, barriers to sharing video and other telemedical records are falling, the consultant says. Telemedicine providers can already push the content of a video visit or other telehealth consult into an EMR using HL7, and soon information sharing should go both ways, he notes.

What’s more, breaking down another wall, major EMR vendors are offering providers the ability to conduct a telehealth visit using their platform. For example, Epic is offering telemedicine services to providers via its MyChart portal and Hyperspace platform, in collaboration with telehealth video provider Vidyo. Cerner, which operates some tele-ICUs, has gone even further, with senior exec John Glaser recently arguing that telehealth needs to be a central part of its population health strategy.

Admittedly, even if providers develop a high level of comfort delivering care through telehealth platforms, it’s probably too soon to rely on this medium as an agent of change. If nothing else, the industry must face up to the fact that telemedicine demand isn’t huge among their patients at present, though consumer plays like AmWell and DoctoronDemand are building awareness.

Also, while scheduling and conducting telemedicine consults need not be profoundly different than holding a face-to-face visit — other than offering both patient and doctor more flexibility — working in time to manage and document these cases can still pose a workflow challenge. Practical issues such as how, physically, a doctor documents a telehealth visit while staring at the screen must be resolved, issues of scheduling addressed and even questions of how to store and retrieve such visit records must be thought through.

However, I think it’s fair to say that we’re past wondering whether telemedicine should be part of the healthcare process, and whether it makes financial sense for hospitals and clinics to offer it. Now we just have to figure out where and when.

Apple’s Healthcare Data Plans Become Clearer

Posted on October 3, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Though it’s not without competitors, I’d argue that Apple’s HealthKit has stood out since its inception, in part because it was relatively early to the game (mining patient-centered data) and partly because Apple products have a sexy reputation. That being said, it hasn’t exactly transformed the health IT industry either.

Now, though, with the acquisition of Gliimpse, a startup which pulls data from disparate EMRs into a central database, it’s become clearer what Apple’s big-picture goals are for the healthcare market – and if its business model works out they could indeed change health data industry.

According to a nifty analysis by Bloomberg’s Alex Webb, which quotes an Apple Health engineer, the technology giant hopes to see the health data business evolve along the lines of Apple’s music business, in which Apple started with a data management tool (the iPod) then built a big-bucks music platform on the device. And that sounds like an approach that could steal a move from many a competitor indeed.

Apple’s HealthKit splash
Apple made a big splash with the summer 2014 launch of HealthKit, a healthcare data integration platform whose features include connecting patient generated health data with traditional systems like the Epic EMR. It also attracted prominent partners like Cedars-Sinai Medical Center and Ochsner Health System within a year or so of its kickoff.

Still, the tech giant has been relatively quiet about its big-picture vision for healthcare, leaving observers like yours truly wondering what was up. After all, many of Apple’s health data moves have been incremental. For example, a few months ago I noted that Apple had begun allowing users to store their EMR data directly in its Health app, using the HL7 CCD standard. While interesting, this isn’t exactly an earth-shattering advance.

But in his analysis — which makes a great deal of sense to me – Bloomberg’s Webb argues that Apple’s next act is to take the data it’s been exchanging with wearables and put it to better use. Apple’s long-awaited big idea is to turn Apple’s HealthKit into a system that can improve diagnoses, sources told Bloomberg.

Also, Apple intends to integrate health records as closely with its proprietary devices as possible, offering not only data collection but suggestions for better health in a manner that can’t be easily duplicated on Android platforms. As Webb rightly points out, such a move could undermine Google’s larger healthcare plans, by locking consumers into Apple technology and discouraging a switch to the Google Fit health tracking software.

Big vision, big questions
As we know, even a company with the reputation, cash and proprietary user base enjoyed by Apple is far from a shoo-in for consumer health data dominance. (Consider the fate of Microsoft HealthVault and Google Health.) Its previous successes have come, as noted, by creating a channel then dominating that channel, but there’s no guarantee it can pull off such a trick this time.

For one thing, the wearables market is highly fragmented, and Apple is far from being the leader. (According to one set of stats, Fitbit had 25.4% of the global wearables market as of Q2 ’16, Xiaomi 14%, and Apple just 7%.) That doesn’t bode well for starting a health tracker-based revolution.

On the other hand, though, Apple did manage to create and dominate a channel in the music business, which is also quite resistant to change and dominated by extremely entrenched powers that be. If any upstart healthcare player could make this happen, it’s probably Apple. It will be interesting to see whether Apple can work its magic once again.

Schlag and Froth: Argonauts Navigate Between Heavy-weight and Light-weight Standardization (Part 2 of 2)

Posted on August 26, 2016 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 previous section of this article laid out the context for HL7 FHIR standard and the Argonaut project; now we can look at the current status.

The fruits of Argonaut are to be implementation guides that they will encourage all EHR vendors to work from. These guides, covering a common clinical data set that has been defined by the ONC (and hopefully will not change soon), are designed to help vendors achieve certification so they can sell their products with the assurance that doctors using them will meet ONC regulations, which require a consumer-facing API. The ONC will also find certification easier if most vendors claim adherance to a single unambiguous standard.

The Argonaut implementation guides, according to Tripathi, will be complete in late September. Because FHIR is expected to be passed in September 2017, the Argonaut project will continue to refine and test the guides. One guide already completed by the project covers security authorization using OpenID and OAuth. FHIR left the question of security up to those standards, because they are well-established and already exist in thousands of implementations around the Web.

Achieving rough consensus

Tripathi portrays the Argonaut process as radically different from HL7 norms. HL7 has established its leading role in health standards by following the rules of the American National Standards Institute (ANSI) in the US, and similar bodies set up in other countries where HL7 operates. These come from the pre-Internet era and emphasize ponderous, procedure-laden formalities. Meetings must be held, drafts circulated, comments explicitly reconciled, ballots taken. Historically this has ensured that large industries play fair and hear through all objections, but the process is slow and frustrates smaller actors who may have good ideas but lack the resources to participate.

In contrast, FHIR brings together engineers and other interested persons in loose forums that self-organize around issues of interest. The process still tried to consider every observation and objection, and therefore, as we have seen, has taken a long time. But decision-making takes place at Internet speed and there is no jockeying for advantage in the marketplace. Only when a milestone is reached does the formal HL7 process kick in.

The Argonaut project works similarly. Tripathi reports that the vendors have gotten along very well. Epic and Cerner, the behemoths of the EHR field, are among the most engaged. Company managers don’t interfere with engineer’s opinions. And new vendors with limited resources are very active.

Those with a background in computers can recognize, in these modes of collaboration, the model set up by the Internet Engineering Task Force (IETF) decades ago. Like HL7, the IETF essentially pre-dated the Internet as we know it, which they helped to design. (The birth of the Internet is usually ascribed to 1969, and the IETF started in 1986, at an early stage of the Internet. FTP was the canonical method of exchanging their plain-text documents with ASCII art, and standards were distributed as Requests for Comments or RFCs.) The famous criteria cited by the IETF for approving standards is “rough consensus and running code.” FHIR and the Argonauts produce no running code, but they seem to operate through rough consensus, and the Argonauts could add a third criterion, “Get the most important 90% done and don’t let the rest hold you up.”

Tripathi reports that EHR vendors are now collaborating in this same non-rivalrous manner in other areas, including the Precision Medicine initiative, the Health Services Platform Consortium (HSPC), and the SMART on FHIR initiative.

What Next?

The dream of interoperability has long included the dream of a marketplace for apps, so that we’re not stuck with the universally hated EHR interfaces that clinicians struggle with daily, or awkwardly designed web sites for consumers. Tripathi notes that SMART offers an app gallery with applications that ought to work on any EHR that conforms to the open SMART platform. Cerner and athenahealth also have app stores protected by a formal approval process. (Health apps present more risk than the typical apps in the Apple App Store or Google Play, so they call more more careful, professional vetting.) Tripathi is certain that other vendors will follow in the lead of these projects, and that cross-vendor stores like SMART’s App Gallery will emerge in a few years along with something like a Good Housekeeping seal for apps.

The Argonaut guides will have to evolve. It’s already clear that EHR vendors are doing things that aren’t covered by the Argonaut FHIR guide, so there will be a few incompatible endpoints in their APIs. Consequently, the Argonaut project has a big decision to make: how to provide continuity? The project was deliberately pitched to vendors as a one-time, lightweight initiative. It is not a legal entity, and it does not have a long-term plan for stewardship of the outcomes.

The conversation over continuity is ongoing. One obvious option is to turn over everything to HL7 and let the guides fall under its traditional process. A new organization could also be set up. HL7 itself has set up the FHIR Foundation under a looser charter than HL7, probably (in my opinion) because HL7 realizes it is not nimble and responsive enough for the FHIR community.

Industries reach a standard in many different ways. In health care, even though the field is narrow, standards present tough challenges because of legacy issues, concerns over safety, and the complexity of human disease. It seems in this case that a blend of standardization processes has nudged forward a difficult process. Over the upcoming year, we should know how well it worked.

Schlag and Froth: Argonauts Navigate Between Heavy-weight and Light-weight Standardization (Part 1 of 2)

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

You generally have to dwell in deep Nerdville to get up much excitement about technical standards. But one standard has been eagerly followed by thousands since it first reached the public eye in 2012: Fast Healthcare Interoperability Resources (FHIR). To health care reformers, FHIR embodies all the values and technical approaches they have found missing in health care for years. And the development process for FHIR is as unusual in health care as the role the standard is hoped to play.

Reform From an Unusual Corner

FHIR started not as an industry initiative but as a pet project of Australian Grahame Grieve and a few developers gathered around him. From this unusual genesis it got taken up by HL7 and an initial draft was released in March 2012. Everybody in health care reform rallied around FHIR, recognizing it as a viable solution to the long-stated need for application programming interfaces (APIs). The magic of APIs, in turn, is their potential to make data exchange easy and create a platform for innovative health care applications that need access to patient data.

So, as a solution to the interoperability problems for which EHR vendors had been dunned by users and the US government, FHIR won immediate accolades. But these vendors knew they couldn’t trust normal software adoption processes to use FHIR interoperably–those processes had already failed on earlier standards.

HL7 version 2 had duly undergone a long approval process and had been implemented as an output document format by numerous EHR vendors, who would show off their work annually at an Interoperability Showcase in a central hall of the HIMSS conference. Yet all that time, out in the field, innumerable problems were reported. These failures are not just technical glitches, but contribute to serious setbacks in health care reform. For instance, complaints from Accountable Care Organizations are perennial.

Congress’s recent MACRA bill, follow-up HHS regulations, and pronouncements from government leaders make it clear that hospitals and their suppliers won’t be off the hook till they solve this problem of data exchange, which was licked decades ago by most other industries. It was by dire necessity, therefore, that an impressive array of well-known EHR vendors announced the maverick Argonaut project in December 2014. (I don’t suppose its name bears any relation to the release a few months before of a highly-publicized report from a short-lived committee called JASON.)

Argonaut include major EHR vendors, health care providers such as Partners Healthcare, Mayo, Intermountain, and Beth Israel Deaconess, and other interested parties such as Surescripts, The Advisory Board, and Accenture. Government agencies, especially the ONC, and app developers have come on board as testers.

One of the leading Argonauts is Micky Tripathi, CEO of the Massachusetts eHealth Collaborative. Tripathi has been involved in health care reform and technical problems such as data exchange long before these achieved notable public attention with the 2009 HITECH act. I had a chance to talk to him this week about the Argonauts’ progress.

Reaching a Milestone

FHIR is large and far-reaching but deliberately open-ended. Many details are expected to vary from country to country and industry to industry, and thus are left up to extensions that various players will design later. It is precisely in the extensions that the risk lurks of reproducing the Tower of Babel that exists in other health care standards.

The reason the industry have good hopes for success this time is the unusual way in which the Argonaut project was limited in both time and scope. It was not supposed to cover the entire health field, as standards such as the International Classification of Diseases (ICD) try to do. It would instead harmonize the 90% of cases seen most often in the US. For instance, instead of specifying a standard of 10,000 codes, it might pick out the 500 that the doctor is most likely to see. Instead of covering all the ways to take a patient’s blood pressure (sitting, standing, etc.), it recommends a single way. And it sticks closely to clinical needs, although it may well be extended for other uses such as pharma or Precision Medicine.

Finally instead of staying around forever to keep chopping off more tasks to solve, the Argonaut project would go away when it was done. In fact, it was supposed to be completed one year ago. But FHIR has taken longer than expected to coalesce, and in the meantime, the Argonaut project has been recognized as a fertile organization by the vendors. So they have extended it to deal with some extra tasks, such as an implementation guide for provider directories, and testing sprints.

That’s some history; the next section of this article will talk about the fruits of the Argonaut project and their plans for the future.

ONC Announces Winners Of FHIR App Challenge

Posted on August 3, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

The ONC has announced the first wave of winners of two app challenges, both of which called for competitors to use FHIR standards and open APIs.

As I’ve noted previously, I’m skeptical that market forces can solve our industry’s broad interoperability problems, even if they’re supported and channeled by a neutral intermediary like ONC. But there’s little doubt that FHIR has the potential to provide some of the benefits of interoperability, as we’ll see below.

Winners of Phase 1 of the agency’s Consumer Health Data Aggregator Challenge, each of whom will receive a $15,000 award, included the following:

  • Green Circle Health’s platform is designed to provide a comprehensive family health dashboard covering the Common Clinical Data Set, using FHIR to transfer patient information. This app will also integrate patient-generated health data from connected devices such as wearables and sensors.
  • The Prevvy Family Health Assistant by HealthCentrix offers tools for managing a family’s health and wellness, as well as targeted data exchange. Prevvy uses both FHIR and Direct messaging with EMRs certified for Meaningful Use Stage 2.
  • Medyear’s mobile app uses FHIR to merge patient records from multiple sources, making them accessible through a single interface. It displays real-time EMR updates via a social media-style feed, as well as functions intended to make it simple to message or call clinicians.
  • The Locket app by MetroStar Systems pulls patient data from different EMRs together onto a single mobile device. Other Locket capabilities include paper-free check in and appointment scheduling and reminders.

ONC also announced winners of the Provider User Experience Challenge, each of whom will also get a $15,000 award. This part of the contest was dedicated to promoting the use of FHIR as well, but participants were asked to show how they could enhance providers’ EMR experience, specifically by making clinical workflows more intuitive, specific to clinical specialty and actionable, by making data accessible to apps through APIs. Winners include the following:

  • The Herald platform by Herald Health uses FHIR to highlight patient information most needed by clinicians. By integrating FHIT, Herald will offer alerts based on real-time EMR data.
  • PHRASE (Population Health Risk Assessment Support Engine) Health is creating a clinical decision support platform designed to better manage emerging illnesses, integrating more external data sources into the process of identifying at-risk patients and enabling the two-way exchange of information between providers and public health entities.
  • A partnership between the University of Utah Health Care, Intermountain Healthcare and Duke Health System is providing clinical decision support for timely diagnosis and management of newborn bilirubin according to evidence-based practice. The partners will integrate the app across each member’s EMR.
  • WellSheet has created a web application using machine learning and natural language processing to prioritize important information during a patient visit. Its algorithm simplifies workflows incorporating multiple data sources, including those enabled by FHIR. It then presents information in a single screen.

As I see it, the two contests don’t necessarily need to be run on separate tracks. After all, providers need aggregate data and consumers need prioritized, easy-to-navigate platforms. But either way, this effort seems to have been productive. I’m eager to see the winners of the next phase.

FHIR Product Director Speaks Out On FHIR Hype

Posted on June 6, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

To date, all signs suggest that the FHIR standard set has tremendous promise, and that FHIR adoption is growing by leaps and bounds. In fact, one well-connected developer I spoke with recently argues that FHIR will be integrated into ONC’s EHR certification standards by 2017, when MACRA demands its much ballyhooed “widespread interoperability.”

However, like any other new technology or standard, FHIR is susceptible to being over-hyped. And when the one suggesting that FHIR fandom is getting out of control is Grahame Grieve, FHIR product director, his arguments definitely deserve a listen.

In a recent blog post, Grieve notes that the Gartner hype cycle predicts that a new technology will keep generating enthusiasm until it hits the peak of inflated expectations. Only after falling into te trough of disillusionment and climbing the slope of enlightenment does it reach the plateau of productivity, the Gartner model suggests.

Now, a guy who’s driving FHIR’s development could be forgiven for sucking up the praise and excitement around the emerging standard and enjoying the moment. Instead, though, it seems that Grieve thinks people are getting ahead of themselves.

To his way of thinking, the rate of hype speech around FHIR continues to expand. As he sees it, people are “[making] wildly inflated claims about what is possible, (wilfully) misunderstanding the limitations of the technology, and evangelizing the technology for all sorts of ill judged applications.”

As Grieve sees it, the biggest cloud of smoke around FHIR is that it will “solve interoperability.” And, he flatly states, it’s not going to do that, and can’t:

FHIR is two things: a technology, and a culture. I’m proud of both of those things…But people who think that [interoperability] will be solved anytime soon don’t understand the constraints we work under…We have severely limited ability to standardise the practice of healthcare or medicine. We just have to accept them as they are. So we can’t provide prescriptive information models. We can’t force vendors or institutions to do things the same way. We can’t force them to share particular kinds of information at particular times. All we can do is describe a common way to do it, if people want to do it.

The reality is that while FHIR works as a means of sharing information out of an EHR, it can’t force different stakeholders (such as departments, vendors or governments) to cooperate successfully on sharing data, he notes. So while the FHIR culture can help get things done, the FHIR standard — like other standards efforts — is just a tool.

To be sure, FHIR seems to have legs, and efforts like the Argonaut Project — which is working to develop a first-generation FHIR-based API and Core Data Services specification — are likely to keep moving full steam ahead.

But as Grieve sees it, it’s important to keep the pace of FHIR work deliberate and keep fundamentals like solid processes and well-tested specifications in mind: “If we can get that right — and it’s a work in process — then the trough of despair won’t be as deep as it might.”

The Downside of Interoperability

Posted on May 2, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

It’s hard to argue that achieving health data interoperability is not important — but it comes with risks. And I’ve seen little discussion of the fact that interoperability may actually increase the chance that a major attack could hit a wide swath of healthcare providers. It might be extreme to suggest that we put off such efforts until we step up the industry’s security status, but the problem shouldn’t be ignored either.

Sure, data interoperability is a critical goal for healthcare providers of all stripes. While there’s room to argue about how it should be accomplished, particularly over whether providers or patients should drive health data management, there’s no question it needs to get done. There’s little doubt that most efforts to coordinate care will fall flat if providers are operating with incomplete information.

And what’s more, with the demand for interoperability baked into MACRA, we pretty much have no choice but to make it happen anyway. To my knowledge, HHS has proposed neither carrot nor stick to convince providers to come on board – nor has it defined “widespread” interoperability to my knowledge — but the agency has to achieve something by 2018, and that means change will come.

That being said, I’m struck by how little industry concern there seems to be about the extent to which interoperability can multiply the possibility of a breach occurring. Unfortunately, security is only as good is the weakest link in the chain, and data sharing increases the length of the chain exponentially. Of course, the risk varies a great deal depending on who or what the data-sharing intermediary is, but the fact remains that a connected network is a connected network.

The problem only gets worse if interoperability is achieved by integrating applications. I’m no software engineer, but I’m pretty sure that the more integrated providers’ infrastructure is, the more vulnerabilities they share. To be fair, hospitals theoretically vet their partners, but that defeats the purpose of universal data sharing, doesn’t it?

And even if every provider in the universal data sharing network practices good security hygiene, they can still get attacked. So it’s not a matter of requiring participants to comply with some network security standard, or meet some certification criteria. Given the massive incentives these have to steal health data (and lock it up with ransomware), nobody can hold out forever.

The bottom line is that I believe we should discuss the matter of security in a fully-connected health data sharing network more often.

Yes, we almost certainly need to press ahead and simply find a way to contain the risks. We simply can’t afford our fragmented healthcare system, and data interoperability offers perhaps the best possible chance of pulling it back together.

But before we plunge into the fray, it only makes sense to stop and consider all of the risks involved and how they should be addressed. After all, universal interconnection exposes a virtually infinite number of potential points of failure to cybercrooks. Let’s put some solutions on the table before it’s too late.

HL7 Backs Effort To Boost Patient Data Exchange

Posted on December 8, 2014 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Standards group Health Level Seven has kicked off a new project intended to increase the adoption of tech standards designed to improve electronic patient data exchange. The initiative, the Argonaut Project, includes just five EMR vendors and four provider organizations, but it seems to have some interesting and substantial goals.

Participating vendors include Athenahealth, Cerner, Epic, McKesson and MEDITECH, while providers include Beth Israel Deaconess Medical Center, Intermoutain  Healthcare, Mayo Clinic and Partners HealthCare. In an interesting twist, the group also includes SMART, Boston Children’s Hospital Informatics Program’s federally-funded mobile app development project. (How often does mobile get a seat at the table when interoperability is being discussed?) And consulting firm the Advisory Board Company is also involved.

Unlike the activity around the much-bruited CommonWell Alliance, which still feels like vaporware to industry watchers like myself, this project seems to have a solid technical footing. On the recommendation of a group of science advisors known as JASON, the group is working at creating a public API to advance EMR interoperability.

The springboard for its efforts is HL7’s Fast Healthcare Interoperability Resources. HL7’s FHir is a RESTful API, an approach which, the standards group notes, makes it easier to share data not only across traditional networks and EMR-sharing modular components, but also to mobile devices, web-based applications and cloud communications.

According to JASON’s David McCallie, Cerner’s president of medical informatics, the group has an intriguing goal. Members’ intent is to develop a health IT operating system such as those used by Apple and Android mobile devices. Once that was created, providers could then use both built-in apps resident in the OS and others created by independent developers. While the devices a “health IT OS” would have to embrace would be far more diverse than those run by Android or iOS, the concept is still a fascinating one.

It’s also neat to hear that the collective has committed itself to a fairly aggressive timeline, promising to accelerate current FHIT development to provide hands-on FHIR profiles and implementation guides to the healthcare world by spring of next year.

Lest I seem too critical of CommonWell, which has been soldiering along for quite some time now, it’s onlyt fair to note that its goals are, if anything, even more ambitious than the Argonauts’. CommonWell hopes to accomplish nothing less than managing a single identity for every person/patient, locating the person’s records in the network and managing consent. And CommonWell member Cerner recently announced that it would provide CommonWell services to its clients for free until Jan. 1, 2018.

But as things stand, I’d wager that the Argonauts (I love that name!) will get more done, more quickly. I’m truly eager to see what emerges from their efforts.

High Costs of Health IT, ePrescribing, and HIE — #HITsm Chat Highlights

Posted on June 29, 2013 I Written By

Katie Clark is originally from Colorado and currently lives in Utah with her husband and son. She writes primarily for Smart Phone Health Care, but contributes to several Health Care Scene blogs, including EMR Thoughts, EMR and EHR, and EMR and HIPAA. She enjoys learning about Health IT and mHealth, and finding ways to improve her own health along the way.

The following is our regularly scheduled roundup of tweets from yesterday’s #HITsm chat. You can also check out John’s blog post on yesterdays #HITsm topics.

Topic One: Costs vs benefits. Will high costs always be the #1 barrier cited to #healthIT adoption?

 

Topic Two: Why does ePrescribing have such widespread acceptance while #telehealth adoption is so low?

 

Topic Three: #HIE as a noun or a verb? Does negative press for HIE organization$ hinder health data exchange as a whole?

#HITsm T4: Is #CommonWell just a bully in a fairy godmother costume?

 

Topic Five: Open forum: What #HealthIT topic had your attention this week?