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!!

Infographic – Practical Interoperability in Healthcare

Posted on October 22, 2018 I Written By

Colin Hung is the co-founder of the #hcldr (healthcare leadership) tweetchat one of the most popular and active healthcare social media communities on Twitter. Colin speaks, tweets and blogs regularly about healthcare, technology, marketing and leadership. He is currently an independent marketing consultant working with leading healthIT companies. Colin is a member of #TheWalkingGallery. His Twitter handle is: @Colin_Hung.

The team at HULFT sent me their new infographic that identifies the stakeholders that should be “at the table” to set your organization’s data sharing and interoperability policies.

There are a couple of things I really like about this infographic.

First, I like the mixture of disciplines and backgrounds that HULFT has identified as data stakeholders. There are people you would expect to see around the table like the CIO, CSO, Privacy Officer, COO, etc. But there are others who are a bit of a surprise: the Revenue Cycle Manager, Pharmacy Benefits Leader, Nurse Practitioner Informaticists, and Care Management Director.

The Care Management Director is an especially welcome inclusion. Without interoperability coordinating patient care is time consuming, frustrating for everyone involved and fraught with errors (medicine reconciliation anyone?). When I think about the need for interoperability, care coordination is what come springs to mind.

The second thing I like about this infographic is the consistency of the visual. The avatars seated at the miniature table at the top are the same as the enlarged versions underneath. This attention to visual detail appeals to the healthcare marketer in me.

Enjoy.

Rolling Over Mountains – An Interview with Niko Skievaski, President of Redox

Posted on October 16, 2018 I Written By

Colin Hung is the co-founder of the #hcldr (healthcare leadership) tweetchat one of the most popular and active healthcare social media communities on Twitter. Colin speaks, tweets and blogs regularly about healthcare, technology, marketing and leadership. He is currently an independent marketing consultant working with leading healthIT companies. Colin is a member of #TheWalkingGallery. His Twitter handle is: @Colin_Hung.

Over the past year I have been following the success of Redox and I have read many articles about the entrepreneurial journey of their President and Co-Founder, Niko Skievaski. I recently had the chance to sit down with him at the MGMA18 conference in Boston.

Rather than revisit the same questions that have been covered in dozens of other articles, I wanted to go in a different direction. I wanted to learn more about Skievaski- the-person rather than Skievaski-the-entrepreneur and I wanted to hear Skievaski’s opinion on the state of the healthcare as an ecosystem.

The latter is something that we have been investigating here at Healthcare Scene. For more details, see John Lynn’s recent post about MEDITECH’s app development environment (Greenfield) and my article exploring whether EHR companies are difficult to work with.

Skievaski and I had a wide-ranging conversation. I hope you enjoy it.

You and I met briefly at the Redox party at HIMSS18 earlier this year. I just want to thank you for your hospitality.

You’re welcome. We love our taco parties at Redox. I’m glad you enjoyed the fiesta.

I understand that you recently moved from Madison, WI to Boulder, Colorado. Why the move?

I lived in Madison for 10 years. I was working for EPIC during that time so it made sense to be there. But I recently decided that I needed a few more mountains in my life so I moved to Boulder.

All through college I raced mountain bikes and I wanted to get back to that. Madison does have a few rolling hills which are fun to ride down, but there’s no comparison to biking down a mountain. So I moved to Boulder for the mountain biking.

You’re from Canada right? [Yes] I was up in British Columbia for two months in the summer last year just mountain biking the trails up there. That was my first real experience being in Canada for an extended period of time. It was fun. You guys are really chill up there in Vancouver.

There are many players in the data integration space. Some have been in the business for decades. Why has Redox succeed in capturing the buzz while others haven’t?

We do things fundamentally differently than existing vendors in the integration space.

In the status quo, you implement an EHR and you need upwards of 400 interfaces to connect it to various other systems in your hospital. So you go out and hire 5-20 interface analysts to sit around all day and code the interfaces you need. You do that a few times, like we did at Epic, and you realize that you are building the same interface over and over again for different health systems. It is literally is the same interface.

Redox is based on the premise that you only should have to build the interface once for all healthcare systems. Once it’s built, others can leverage that work too. For example, we connect Brigham and Women’s ADT feed to Redox. We mapped it. We know where all the fields are. And we’ve done the same with hundreds of other health systems. So if there is any reason that Brigham wants to share their info with any of those other health systems we can facilitate it very easily.

Legacy players didn’t grow up in the cloud so they don’t think like we do. They come from a world of on-premise integration and at a time when healthcare organizations wanted to do all the interface work themselves. It’s a different world now.

I guess you can say that we’re getting the attention because we are solving the problem so differently than everyone else.

One of the interesting things about Redox is that you don’t sell to healthcare organizations. Instead you focus exclusively on HealthIT vendors. Why is that?

We started by working with HealthIT startups that knew how to build in the cloud but didn’t know anything about HL7 and didn’t want to. Yet these companies needed to connect to their customers’ EHR systems.

Without that integration, healthcare organizations wouldn’t buy these amazing cloud apps because of the lack of easy connectivity to their existing systems. In that equation, the incentive lies with the HealthIT company. They are the ones that want to solve the issue of connectivity more than the healthcare organization does. So we target companies that need this help and we go to their customers, get connected to the data and make It easy for the new company to focus on what they do best – which isn’t data integration.

The first project we do with a health system is very much like a standard integration project. The second project is where things get excited because we use that exact same interface we built the first time. There’s really no work to be done by the organization. That’s how we scale.

Is there an ideal type of HealthIT company that Redox likes to work with?

With certain vendors who have the right multi-tenant architecture, like PointClickCare, we can just connect with them once and they can then provision to their customers with a flip of a switch. Any PointClickCare location that wants integration, they can just click and make it happen. Together we make it very easy for a PointClickCare customer to connect with HIEs and the healthcare organizations that they work with.

Basically any HealthIT vendor that is truly cloud-based and that has embraced the concept of having a single platform for everyone is an ideal fit for Redox. Of course, we’re willing to talk to anyone to try and find a solution, but if you are cloud-based HealthIT vendor we should really be talking.

Can you give me an example of an advantage Redox enjoys because you are cloud-based?

By being in the cloud we essentially become the cloud interface for health systems to connect to cloud apps. Vendors come to us because we make it easy for them to get the data they need. Healthcare organizations push cloud vendors they want to work with to us because they won’t have to do any work to connect that new app if that vendor signs on with Redox.

Where things get really interesting, and exciting for Redox, is when we can use our cloud platform to facilitate conversations between vendors and their common customers without the need to go all the way back to that customer’s EHR as the focal point of integration.

For example, say there is a cloud-based scheduling app that allows patients to see and book appointments online. Let’s say they are a Redox customer. Now let’s say there is a telemedicine app that allows healthcare organizations to offer telehealth visits and it reads/writes appointment data directly into the organization’s EHR. Say this telemedicine company is a Redox customer too. So if the healthcare org wants to offer Telemedicine appointments through that scheduling app, the two companies can just integrate through Redox rather than use the EHR as the point of integration because we have all the necessary information running through our platform. This would speed up the transaction and make the patient experience more seamless.

This level of integration is just not possible without being in the cloud.

One of the topics we have explored recently at Healthcare Scene is how difficult it is (or isn’t) to work with EHR companies like Epic, Cerner and Allscripts. What are your thoughts on this? Are EHR companies hard to work with?

I would say, in general, EHR companies get a bad rap. I worked at Epic and I have to say that being inside Epic you don’t realize that people outside think you are difficult to work with. We worked hard to give our customers good service. Epic supports their customers, which are health systems. If a system wants to integrate with an application, then Epic people are more than happy to make it happen. They will put together a project team to support that initiative.

I think that as long as the health system is driving the conversation, EHR companies can be easy to work with.

The challenging part is when there is no customer in between. Say you are a HealthIT vendor and you want to go strike up a deal with an EHR company, like Epic. You have to realize that it’s nearly impossible for that EHR company to assess you as HealthIT vendor. They can’t tell if you are a good vendor or a bad one. If you are an established player or someone with an idea on the back of a napkin. The only way they can tell is if they go ask their customers – the health systems. Because of this, their traditional response has been: “Yes, happy to work with you, but we need to have one of our customers on board to prove this will work.” This can be perceived as being difficult to work with.

When we started Redox we didn’t go immediately knocking on Epic’s door and asking our friends to partner with us. Instead we went out and found a mutual customer to work with so that we would have a proof point when we did approach them.

I actually think it is easier to work with large EHR companies versus smaller ones. The larger companies have more invested in each of their customers and are more apt to work on projects that their customers want to do. Smaller EHR companies are constrained by resources and often don’t have the infrastructure to support integration projects in a timely manner. The good news is that things are changing. We’re seeing a lot more of the small EHR companies come out with developer programs, APIs and partner exchanges. I think they understand the need for their systems to be open.

Is the lack of interoperability a technological issue or is it simply an unwillingness to collaborate?

Neither. It’s a business model problem.

There is no business model that drives healthcare organizations to share their data. No one bats an eye about the lack of interoperability in the consumer world. Walmart doesn’t share their customer data with Target even though there are many people buy from both retailers. If they did share data, they would just be stealing each other’s customers. Healthcare organizations are in competition with each other so they aren’t really incentivized to share data with each other, but give them a useful app in between and all of a sudden they will open up their data.

Interoperability is the right thing to do, but it’s a hard thing to do.

What do you wish you could do with an EHR company that you cannot do today?

The user interface (UI) of EHRs are locked down. I wish EHR companies were more open to change workflow or add buttons to their UIs to make things a more seamless.

I totally understand why they don’t allow it. The workflow in an EHR has an impact on patient safety as well as on outcomes, so you wouldn’t want just any vendor to be able to make UI changes on a whim. But it would be great if there was a way to do something with the UI to make it easier for the end user.

For example, if you are doing something in the workflow, it would be fantastic if you could add a button to the UI that launched a 3rd party app from within the EHR. Say a clinician is doing a chart review and they want to be able to see the latest data from a remote patient monitoring tool. Imagine if that clinician could click a button and launch the actual monitoring app rather than that app having to ship its data to the EHR and have it stored/rendered in a poor format – like a table of numbers or a rudimentary chart. Why not let the native app show the data in all it’s glory using an interface designed specifically for it?

What’s next for Redox?

We want to push the healthcare industry to a point where we don’t even think about integration anymore. We want to see an end to integration projects. Think about all the time and resources that would be saved if you don’t have to use a custom interface each time. If we can do that we can drive down the cost of healthcare for everyone. To do that we just have to keep growing the nodes on our network and be a good partner to everyone.

 

This may sound like a tall order, but maybe not for someone who rolls over mountains on a bike for fun.

[Update: Niko Skievaski’s title which was incorrectly reported as CEO. Skievaski is Redox’s President and Co-Founder]

Is FHIR Adoption At A Turning Point, Or Is This Just More Hype?

Posted on October 8, 2018 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 few years, healthcare industry players have continued to experiment with the use of HL7 FHIR to solve key interoperability problems.

Perhaps the most recent efforts to do so is the Da Vinci Project, which brings together a group of payers, health IT vendors, and providers dedicated to fostering value-based care with FHIR. The group has begun work on two test cases, one addressing 30-day medication reconciliation and the other coverage requirements discovery.

This wasn’t big news, as it doesn’t seem to be doing anything that new. In fact, few if any of these projects — of which there have been many — have come close to establishing FHIR firmly established as a standard, much less fostering major change in the healthcare industry.

Now, a new analysis by the ONC suggests that we may finally be on the verge of a FHIR breakthrough.

According to ONC’s research, which looked at how health IT developers used FHIR to meet 2015 Edition certification requirements, roughly 32% of the health IT developers certified are using FHIR Release 2, and nearly 51% of health IT developers seem to be using a version of FHIR combined with OAuth 2.0.

While this may not sound very impressive (and at first glance, it didn’t to me), the certified products issued by the top 10 certified health IT developers serve about 82% of hospitals and 64% of clinicians.

Not only that, big tech companies staking out an expanded position in healthcare are leveraging FHIR 2, the ONC notes. For example, Apple is using a FHIR-based client app as part of its healthcare deployment.  Amazon, Alphabet, and Microsoft are working to establish themselves in the healthcare industry as well, and it seems likely that FHIR-based interoperability will come to play a part in their efforts.

In addition, CMS has shown faith in FHIR as well, investing in FHIR through its Blue Button 2.0,  a standards-based API allowing Medicare beneficiaries to connect their claims data to applications, services, and research programs.

That being said, after citing this progress, the agency concedes that FHIR still has a way to go, from standards development implementation, before it becomes the lingua franca of the industry. In other words, ONC’s definition of “turning point” may be a little different than yours or mine. Have I missed something here?

Look, I don’t like being “that guy,” but how encouraging is this really? By my standards at least, FHIR uptake is relatively modest for such a hot idea. For example, compare FHIR adoption of AI technology or blockchain. In some ways, interoperability may be a harder “get” than blockchain or AI in some ways, but one would think it would be further along if it were completely practical. Maybe I’m just a cynic.

Will Medical Device Makers Get Interoperability Done?

Posted on September 20, 2017 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.

Most of the time, when I think about interoperability, I visualize communication between various database-driven applications, such as EMRs, laboratory information systems and claims records. The truth is, however, that this is a rather narrow definition of interoperability. It’s time we take medical device data into account, the FDA reminds us.

In early September, the FDA released its final guidance on how healthcare organizations can share data between medical devices and other information systems. In the guidance, the agency asserts that the time has come to foster data sharing between medical devices, as well as data exchange between devices and information systems like the ones I’ve listed above.

Specifically, the agency is offering guidelines to medical device manufacturers, recommending that they:

  • Design devices with interoperability in mind
  • Conduct appropriate verification, validation and risk management to ensure interoperability
  • Make sure users clearly understand the device’s relevant functional, performance and interface characteristics

Though these recommendations are interesting, I don’t have much context on their importance. Luckily, Bakul Patel has come to the rescue. Patel, who is associate director for digital health the FDA‘s Center for Devices and Radiological Health, offered more background on medical device interoperability in a recent blog entry.

As the article points out, the stakes here are high. “Errors and inadequate interoperability, such as differences in units of measure (e.g., pounds vs. kilograms) can occur in devices connected to a data exchange system,” Patel writes. Put another way, in non-agency-speak, incompatibilities between devices and information systems can hurt or even kill patients.

Unfortunately, device-makers seem to be doing their own thing when it comes to data sharing. While some consensus standards exist to support interoperability, specifying things like data formats and interoperability architecture design, manufacturers aren’t obligated to choose any particular standard, Patel notes.

Honestly, the idea of varied medical devices using multiple data formats sounds alarming to me. But Patel seems comfortable with the idea. He contends that if device manufacturers explain carefully how the standards work and what the interface requires, all will be well.

All told, If I’m understanding all this correctly, the FDA is fairly optimistic that the healthcare industry can network medical devices on the IoT with traditional information systems.

I’m glad that the agency believes we can work this out, but I’d argue that such optimism may be premature. Patel’s assurances raise a bunch of questions for me, including:

  • Do we really need another set of competing data exchange standards to resolve, this time for medical device interoperability?
  • If so, how do we lend the consensus medical device standards with consensus information system standards?
  • Do we need to insist that manufacturers provide more-consistent software upgrades for the devices before interoperability efforts make sense?

Hey, I’m sure medical device manufacturers want to make device-to-device and device-to-database data sharing as simple and efficient as possible. That’s what their customers want, after all.

Unfortunately, though, the industry doesn’t have a great track record even for maintaining their devices’ operating systems or patching industrial-grade security holes. Designing devices that handle interoperability skillfully may be possible, but will device-makers step up and get it done anytime soon?

Wellpepper and SimplifiMed Meet the Patients Where They Are Through Modern Interaction Techniques

Posted on August 9, 2017 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.

Over the past few weeks I found two companies seeking out natural and streamlined ways to connect patients with their doctors. Many of us have started using web portals for messaging–a stodgy communication method that involves logins and lots of clicking, often just for an outcome such as message “Test submitted. No further information available.” Web portals are better than unnecessary office visits or days of playing phone tag, and so are the various secure messaging apps (incompatible with one another, unfortunately) found in the online app stores. But Wellpepper and SimplifiMed are trying to bring us a bit further into the twenty-first century, through voice interfaces and natural language processing.

Wellpepper’s Sugarpod

Wellpepper recently ascended to finalist status in the Alexa Diabetes Challenge, which encourages research into the use of Amazon.com’s popular voice-activated device, Alexa, to improve the lives of people with Type 2 Diabetes. For this challenge, Wellpepper enhanced its existing service to deliver messages over Amazon Echo and interview patients. Wellpepper’s entry in the competition is an integrated care plan called Sugarpod.

The Wellpepper platform is organized around a care plan, and covers the entire cycle of treatment, such as delivering information to patients, managing their medications and food diaries, recording information from patients in the health care provider’s EHR, helping them prepare for surgery, and more. Messages adapt to the patient’s condition, attempting to present the right tone for adherent versus non-adherent patients. The data collected can be used for analytics benefitting both the provider and the patient–valuable alerts, for instance.

It must be emphasized at the outset that Wellpepper’s current support for Alexa is just a proof of concept. It cannot be rolled out to the public until Alexa itself is HIPAA-compliant.

I interviewed Anne Weiler, founder and CEO of Wellpepper. She explained that using Alexa would be helpful for people who have mobility problems or difficulties using their hands. The prototype proved quite popular, and people seem willing to open up to the machine. Alexa has some modest affective computing features; for instance, if the patient reports feeling pain, the device will may respond with “Ouch!”

Wellpepper is clinically validated. A study of patients with Parkinson’s showed that those using Wellpepper showed 9 percent improvement in mobility, whereas those without it showed a 12% decline. Wellpepper patients adhered to treatment plans 81% of the time.

I’ll end this section by mentioning that integration EHRs offer limited information of value to Wellpepper. Most EHRs don’t yet accept patient data, for instance. And how can you tell whether a patient was admitted to a hospital? It should be in the EHR, but Sugarpod has found the information to be unavailable. It’s especially hidden if the patient is admitted to a different health care providers; interoperability is a myth. Weiler said that Sugarpod doesn’t depend on the EHR for much information, using a much more reliable source of information instead: it asks the patient!

SimplifiMed

SimplifiMed is a chatbot service that helps clinics automate routine tasks such as appointments, refills, and other aspects of treatment. CEO Chinmay A. Singh emphasized to me that it is not an app, but a natural language processing tool that operates over standard SMS messaging. They enable a doctor’s landline phone to communicate via text messages and route patients’ messages to a chatbot capable of understanding natural language and partial sentences. The bot interacts with the patients to understand their needs, and helps them accomplish the task quickly. The result is round-the-clock access to the service with no waiting on the phone a huge convenience to busy patients.

SimplifiMed also collects insurance information when the patient signs up, and the patient can use the interface to change the information. Eventually, they expect the service to analyze patient’s symptom in light of data from the EHR and help the patient make the decision about whether to come in to the doctor.

SMS is not secure, but HIPAA does not get violated because the patient can choose what to send to the doctor, and the chatbot’s responses contain no personally identifiable information. Between the doctor and the SimplifiMed service, data is sent in encrypted form. Singh said that the company built its own natural language processing engine, because it didn’t want to share sensitive patient data with an outside service.

Due to complexity of care, insurance requirements, and regulations, a doctor today needs support from multiple staff members: front desk, MA, biller, etc. MACRA and value-based care will increase the burden on staff without providing the income to hire more. Automating routine activities adds value to clinics without breaking the bank.

Earlier this year I wrote about another company, HealthTap, that had added Alexa integration. This trend toward natural voice interfaces, which the Alexa Diabetes Challenge finalists are also pursuing, along with the natural language processing that they and SimplifiMed are implementing, could put health care on track to a new era of meeting patients where they are now. The potential improvements to care are considerable, because patients are more likely to share information, take educational interventions seriously, and become active participants in their own treatment.

Study Offers Snapshot Of Provider App Preferences

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

A recent study backed by HIT industry researchers and an ONC-backed health tech project offers an interesting window into how healthcare organizations see freestanding health apps. The research, by KLAS and the SMART Health IT Project, suggests that providers are developing an increasingly clear of what apps they’d like to see and how they’d use them.

Readers of this blog won’t be surprised to hear that it’s still early in the game for healthcare app use. In fact, the study notes, about half of healthcare organizations don’t formally use apps at the point of care. Also, most existing apps offer basic EMR data access, rather than advanced use cases.

The apps offering EMR data access are typically provided by vendors, and only allow users to view such data (as opposed to documenting care), according to the study report. But providers want to roll out apps which allow inputting of clinical data, as this function would streamline clinicians’ ability to make an initial patient assessment, the report notes.

But there are other important app categories which have gained an audience, including diagnostic apps used to support patient assessment, medical reference apps and patient engagement apps.  Other popular app types include clinical decision support tools, documentation tools and secure messaging apps, according to researchers.

It’s worth noting, though, that there seems to be a gap between what providers are willing to use and what they are willing to buy or develop on their own. For example, the report notes that nearly all respondents would be willing to buy or build a patient engagement app, as well as clinical decision support tools and documentation apps. The patient engagement apps researchers had in would manage chronic conditions like diabetes or heart disease, both very important population health challenges.

Hospital leaders, meanwhile, expressed interest in using sophisticated patient portal apps which go beyond simply allowing patients to view their data. “What I would like a patient app to do for us is to keep patients informed all throughout their two- to four-hours ED stay,” one CMO told researchers. “For instance, the app could inform them that their CBC has come back okay and that their physician is waiting on the read. That way patients would stay updated.”

When it came to selecting apps, respondents placed a top priority on usability, followed by the app’s cost, clinical impact, capacity for integration, functionality, app credibility, peer recommendations and security. (This is interesting, given many providers seem to give usability short shrift when evaluating other health IT platforms, most notably EMRs.)

To determine whether an app will work, respondents placed the most faith in conducting a pilot or other trial. Other popular approaches included vendor demos and peer recommendations. Few favored vendor websites or videos as a means of learning about apps, and even fewer placed working with app endorsement organizations or discovering them at conferences.

But providers still have a few persistent worries about third-party apps, including privacy and security, app credibility, the level of ongoing maintenance needed, the extent of integration and data aggregation required to support apps and issues regarding data ownership. Given that worrisome privacy and security concerns are probably justified, it seems likely that they’ll be a significant drag on app adoption going forward.

E-Patient Update: Patients Need Better Care Management Workflows

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

Now and then, I get a little discouraged by the state of my health data. Like providers, I’m frustrated as heck by the number of independent data sources I must access to get a full picture of my medications, care and health status. These include:

* The medication tracker on my retail pharmacy’s site
* My primary care group’s portal
* My hospital’s Epic MyChart portal
* A medication management app to track my compliance with my regimen
* A health tracker app in which I track my blood pressure
* My Google calendar, to keep up with my health appointments
* Email clients to exchange messages with some providers

That’s not all – I’m sure I could think of other tools, interfaces and apps – but it offers a good idea of what I face. And I’m pretty sure I’m not unusual in this regard, so we’re talking about a big issue here.

By the way, bear in mind I’m not just talking about hyperportalotus – a fun term for the state of having too many portals to manage – but rather, a larger problem of data coordination. Even if all of my providers came together and worked through a shared single portal, I’d still have to juggle many tools for tracking and documenting my care.

The bottom line is that given the obstacles I face, my self-care process is very inefficient. And while we spend a lot of time talking about clinician workflow (which, of course, is quite important) we seldom talk about patient/consumer health workflow. But it’s time that we did.

Building a patient workflow

A good initial step in addressing this problem might be to create a patient self-care workflow builder and make it accessible website. Using such a tool, I could list all of the steps I need to take to manage my conditions, and the tool would help me develop a process for doing so effectively.

For example, I could “tell” the software that I need to check the status of my prescriptions once a week, visit certain doctors once a month, check in about future clinical visits on specific days and enter my data in my medication management app twice a day. As I did this, I would enter links to related sites, which would display in turn as needed.

This tool could also display critical web data, such as the site compiling the blood sugar readings from my husband’s connected blood glucose monitor, giving patients like me the ability to review trends at a glance.

I haven’t invented the wheel here, of course. We’re just talking about an alternate approach to a patient portal. Still, even this relatively crude approach – displaying various web-based sources under one “roof” along with an integrated process – could be quite helpful.

Eventually, health IT wizards could build much more sophisticated tools, complete with APIs to major data sources, which would integrate pretty much everything patients need first-hand. This next-gen data wrangler would be able to create charts and graphs and even issue recommendations if the engine behind it was sophisticated enough.

Just get started

All that being said, I may be overstating how easy it would be to make such a solution work. In particular, I’m aware that integrating a tool with such disparate data sources is far, far easier said than done. But why not get started?

After all, it’s hard to overestimate how much such an approach would help patients, at least those who are comfortable working with digital health solutions. Having a coordinated, integrated tool in place to help me manage my care needs would certainly save me a great deal of time, and probably improve my health as well.

I urge providers to consider this approach, which seems like a crying need to me. The truth is, most of the development money is going towards enabling the professionals to coordinate and manage care. And while that’s not a bad thing, don’t forget us!

The Case For Accidental Interoperability

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

Many of us who follow #HITsm on Twitter have encountered the estimable standards guru Keith Boone (known there as @motorcycle_guy). Keith always has something interesting to share, and his recent article, on “accidental” interoperability, is no exception.

In his article, he describes an aha moment: “I had a recent experience where I saw a feature one team was demonstrating in which I could actually integrate one of my interop components to supply additional functionality,” he writes. “When you build interop components right, this kind of accidental interop shows up all the time.”

In his piece, he goes on to argue that this should happen a lot more often, because by doing so, “you can create lot of value through it with very little engineering investment.”

In an ideal world, such unplanned instances of interoperability would happen often, allowing developers and engineers to connect solutions with far less trouble and effort. And the more often that happened, the more resources everyone involved would have to invest in solving other types of problems.

But in his experience, it can be tough to get dev teams into the “component-based” mindset that would allow for accidental interoperability. “All too often I’ve been told those more generalized solutions are ‘scope expansions,’ because they don’t fit the use case,” and any talk of future concerns is dropped, he says.

While focusing on a particular use case can save time, as it allows developers to take shortcuts which optimize their work for that use case, this approach also limits the value of their work, he argues. Unfortunately, this intense focus prevents developers from creating more general solutions that might have broader use.

Instead of focusing solely on their short-term goals, he suggests, health IT leaders may want to look at the bigger picture. “My own experience tells me that the value I get out of more general solutions is well worth the additional engineering attention,” he writes. “It may not help THIS use case, but when I can supply the same solution to the next use case that comes along, then I’ve got a clear win.”

Keith’s article points up an obstacle to interoperability that we don’t think much about right now. While most of what I read about interoperability options — including on this blog — focus on creating inter-arching standards that can tie all providers together, we seldom discussed the smaller, day-to-day decisions that stand in the way of health data sharing.

If he’s right (and I have little doubt that he is) health IT interoperability will become a lot more feasible, a lot more quickly, if health organizations take a look at the bigger purposes an individual development project can meet. Otherwise, the next project may just be another silo in the making.

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.”