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

Email Address:

We never sell or give out your contact information.
We respect our readers' privacy.

It was encouraging to see that the ONC hosted a tweetchat to share information and solicit feedback and questions from interested parties. After a little bit of a rough start and clarification of the objectives of the chat, the pace of interactions increased and some good information and ideas were exchanged. In addition, some questions were raised; some of which were answered by Steven Posnak and some of which were not addressed.

What’s This All About?

This post summarizes all of the tweets from the #ISAchat. I’ve organized the tweets as best as I could and I’ve excluded re-tweets and most ‘salutatory’ and ‘thank you’ tweets.

Note: The @hitechanswers account shared a partial summary of the #ISAchat on 8/31/16 but it included less than half of the tweets shared in this post. So you’re getting the complete scoop here.

Topic 1: Tell us about the ISA (Interoperability Standards Advisory)

Account

Tweet

Time

@gratefull080504

Question: What is the objective of #ISAchat?

12:04:35

@onc_healthit

To spread the word and help people better understand what the ISA is about

About Steve SiskoSteve Sisko has over 20 years of experience in the healthcare industry and is a consultant focused on healthcare data, technology and services – mainly for health plans, payers and risk-bearing providers. Steve is known as @ShimCode on Twitter and runs a blog at www.shimcode.com. You can learn more about Steve at his LinkedIn page and he can be contacted at shimcode@gmail.com.

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.

Before HIMSS, I posted about my work to understand FHIR. There’s some great information in that post as I progress in my understanding of FHIR, how it’s different than other standards, where it’s at in its evolution, and whether FHIR is going to really change healthcare or not. What’s clear to me is that many are on board with FHIR and we’ll hear a lot more about it in the future. Many at HIMSS were trying to figure it out like me.

What isn’t as clear to me is whether FHIR is really all that better. Based on many of my discussions, FHIR really feels like the next iteration of what we’ve been doing forever. Sure, the foundation is more flexible and is a better standard than what we’ve had with CCDA and any version of HL7. However, I feel like it’s still just an evolution of the same.

I’m working on a future post that will look at the data for each of the healthcare standards and how they’ve evolved. I’m hopeful that it will illustrate well how the data has (or has not) evolved over time. More on that to come in the future.

One vendor even touted how their FHIR expert has been working on these standards for decades (I can’t remember the exact number of years). While I think there’s tremendous value that comes from experience with past standards, it also has me asking the question of why we think we’ll get different results when we have more or less the same people working on these new standards.

My guess is that they’d argue that they’ve learned a lot from the past standards that they can incorporate or avoid in the new standards. I don’t think these experienced people should be left out of the process because their background and knowledge of history can really help. However, if there isn’t some added outside perspective, then how can we expect to get anything more than what we’ve been getting forever (and we all know what we’ve gotten to date has been disappointing).

Needless to say, while the industry is extremely interested in FHIR, my take coming out of HIMSS is much more skeptical that FHIR will really move the industry forward the way people are describing. Will it be better than what we have today? I think it could be, but that’s not really a high bar. Will FHIR really helps us achieve healthcare interoperability nirvana? It seems to me that it’s really not designed to push that agenda forward.

What do you think of FHIR? Am I missing something important about FHIR and it’s potential to transform healthcare? Do you agree with the assessment that FHIR very well could be more of the same limited thinking on healthcare data exchange? I look forward to continue my learning about FHIR in the comments.

Kyle is CoFounder and CEO of Pristine, a VC backed company based in Austin, TX that builds software for Google Glass for healthcare, life sciences, and industrial environments. Pristine has over 30 healthcare customers. Kyle blogs regularly about business, entrepreneurship, technology, and healthcare at kylesamani.com.

Apple recently announced Health and Healthkit as part of iOS 8, and initial responses have been mixed.

For the uninitiated, Apple Health is a central dashboard for health related information, packaged for consumers as an iOS app. Consumers open the app and see a broad array of clinical indicators (e.g. as physical activity, blood pressure, blood glucose, sleep data). You can learn more about Health and Healthkit from Apple.

The rest of this post assumes significant understanding of modern health IT challenges such as data silos, EMPIs, HIEs, and an understanding of what Health and Healthkit can and can’t do. I’ll address what Apple Health does well, ask some questions, and then provide some commentary.

Apple Health does a few things well:

1) Apple Health acts as a central dashboard for consumers. Rather than switching between five different apps, Health provides a central view of all clinical indicators. In time, Health could help patients understand the nuances of their own data. By removing friction to seeing a variety of indicators in a single view, patients may discover correlations that they wouldn’t have observed before. With that information, consumers should be able to adjust behaviors to lead healthier lifestyles.

2) Apple Health provides a robust mechanism for health apps to share data with one another. Until now, health app developers needed to form partnerships with one another and develop custom code to share information; now they can do this in a standardized way with minimal technical or administrative overhead. This reduces app lock-in by enabling data liquidity, empowering consumers to switch to the best health app or device and carry data between apps. This is a big win for consumers.

Unanswered questions:

1) How does Apple Health actually work? Apple provided virtually no details. Does the patient need the Epic MyChart app on their phone? Is there custom code integrating iOS to Epic MyChart? Is there a Mayo Clinic app that is separate from Epic MyChart? If not, how does Apple Health know that the consumer is a Mayo patient? Or a Kaiser Permanente patient? Or a Sutter Health patient?

2) Does the patient give consent per data value, or is it all or nothing? How long does consent last? Must consent be taken at the hospital, or can the patient opt in or out any time on their phone? Who within the health system can access the consented data?

3) Given that there are hundreds of EpicCare silos and dozens of CareEverywhere silos, how does Apple Health decide which silo(s) to interface with? Does data go to an HIE or to an EMR? If to an HIE, can all eligible connected providers access the data with consent? If a patient has records in multiple HIEs and EMRs (which they likely do), how does Apple Health determine which HIE(s) to push and pull data from?

4) Does Apple Health support non-numerical data such as CCDAs? What about unstandardized data? For example, PatientIO allows providers to develop customized care plans for patients that can include almost any behavioral prescription. Examples include water intake, exercising at a certain time of the day, taper schedules, etc.

5) Can providers write back to a patient’s Health profile? Given that open.epic doesn’t allow Epic to send data out, how could Apple Health receive data from Epic?

7) How will Apple handle competing health apps installed on the same consumer’s phone? For example, if I tap “more diabetes info” in Apple Health, will it open Mayo Clinic’s app (and if so, to the right place in the Mayo Clinic app?) or the blood glucose tracking app that came with with my blood glucose meter? Or my iTriage or WebMD app?

8) Is Apple Health intended to function as a patient-centric HIE? If so, what standards does it support? CCDA? FHIR? Direct?

Comments:

1) The Apple-Epic partnership is obviously built on open.epic, which Epic announced in September of 2013. It’s likely that Apple and Epic reached an agreement around that time, and asked the public for ideas on how to shape the program to get a sense of what developers wanted.

2) The only way to succeed in health IT is to force the industry to conform to one’s standards, or to support a hybrid of hybrids approach. Early indicators show Apple (predictably) trending toward the former. Unfortunately, Apple’s perennially Apple-centric approach inhibits supporting the level of interoperability necessary to power an effective consumer health strategy. Although Apple provides a great foundation for some basic functions, the long term potential based on the current offering is limited. What Apple has produced to date provides for sexy screenshots, but appears to fall short of addressing the core interoperability and connectivity issues that plague chronic disease management and coordination of care.

3) In a hypothetical world at some indeterminate point in the future, there would be a patient-facing, DNS-like lookup system for provider organizations (Direct eventually?). Patients should be able to lookup provider organizations and share their data with providers selectively. Apple Health provides a great first step towards that dream world by empowering patients to see and, to some extent, control their own data.

Mandi Bishop is a hardcore health data geek with a Master's in English and a passion for big data analytics, which she brings to her role as Dell Health’s Analytics Solutions Lead. She fell in love with her PCjr at 9 when she learned to program in BASIC. Individual accountability zealot, patient engagement advocate, innovation lover and ceaseless dreamer. Relentless in pursuit of answers to the question: "How do we GET there from here?" More byte-sized commentary on Twitter: @MandiBPro.

In my January update on Meaningful Use Stage 2 readiness, I painted a dismal picture of a large IDN’s journey towards attestation, and expressed concern for patient safety resulting from the rush to implement and adopt what equates to, at best, beta-release health IT. Given the resounding cries for help from the healthcare provider community, including this February 2014 letter to HHS Secretary Kathleen Sebelius, I know my experience isn’t unique. So, when rumors ran rampant at HIMSS 2014 that CMS and the ONC would make a Meaningful Use announcement, I was hopeful that relief may be in sight.

Like AHA , I was disappointed in CMS Administrator Marilyn Tavenner’s announcement. The new Stage 2 hardship exemptions will now include an explicit criteria for “difficulty implementing 2014-certified EHR technology” – a claim which will be evaluated on a case-by-case basis, and may result in a delay of the penalty phase of the Stage 2 mandate. But it does nothing to extend the incentive phase of Stage 2 – without which, many healthcare providers would not have budgeted for participation in the program, at all, including the IDN profiled in this series. So how does this help providers like mine?

Quick update on my IDN’s progress towards Stage 2 attestation, with $MM in target incentive dollars at stake. We must meet ALL measures; there is no opportunity to defer one. The Transition of Care (both populating it appropriately, and transmitting it via Direct) is the primary point of concern.

The hospital EHR is ready to generate and transmit both Inpatient Summary and Transition of Care C-CDAs. The workflow to populate the ToC required data elements adds more than 4 minutes to the depart process, which will cause operational impacts. None of the ambulatory providers in the IDN have Direct, yet; there is no one available to receive an electronic ToC. Skilled resources to implement Direct with the EHR upgrades are not available until 6-12 weeks after each upgrade is complete.

None of the 3 remaining in-scope ambulatory EHRs have successfully completed their 2014 software upgrades. 2 of the 3 haven’t started their upgrades. 1 has not provided a DATE for the upgrade.

None of the ambulatory EHRs comes with a Clinical Summary C-CDA configured out-of-the-box. 1 creates a provider-facing Transition of Care C-CDA, but does not produce the patient-facing Clinical Summary. (How did this product become CEHRT for 2014 measures?) Once the C-CDA is configured, each EHR requires its own systems integrator to develop the interface to send the clinical document to an external system.

Consultant costs continue to mount, as each new wrinkle arises. And with each wrinkle, the ability to meet the incentive program deadlines, safely, diminishes.

Playing devil’s advocate, I’d say the IDN should have negotiated its vendor contracts to include penalty clauses sufficient to cover the losses of a missed incentive program deadline – or, worst case scenario, to cover the cost of a rip-and-replace should the EHR vendor not acquire certification, or have certification revoked. The terms and conditions should have covered every nuance of the functionality required for Stage 2 measures.

But wait, CMS is still clarifying its Stage 2 measures via FAQs. Can’t expect a vendor to build software to specifications that weren’t explicitly defined, or to sign a contract that requires adherence to unknown criteria.

So, what COULD CMS and the ONC do about it? How about finalizing your requirements BEFORE issuing measures and certification criteria? Since that ship’s already sailed, change the CEHRT certification process.

1. Require vendors to submit heuristics on both initial implementation and upgrades, indicating the typical timeline from kick-off to go-live, number of internal and external resources (i.e., third-party systems integrators), and cost.
2. Require vendors to submit customer-base profile detailing known customers planning to implement and/or upgrade within calendar year. AND require implementation/upgrade planning to incorporate 3 months of QA time post-implementation/upgrade, prior to go-live with real patients.
3. Require vendors to submit human resource strategy, and hiring and training program explicitly defined to support the customer-base profile submitted, with the typical timeframes and project resource/cost profiles submitted.
4. Require vendor products to be self-contained to achieve certification – meaning, no additional third-party purchase (software or professional services) would be necessary in order to implement and/or upgrade to the certified version and have all CMS-required functionality.
5. Require vendor products to prove the CEHRT-baseline functionality is available as configurable OOTB, not only available via customization. SHOW ME THE C-CDA, with all required data elements populated via workflow in the UI, not via some developer on the back-end in a carefully-orchestrated test patient demo script.
6. Require vendor products adhere to an SLA for max number of clicks required to execute the task. It is not Meaningful Use if it’s prohibitively challenging to access and use in a clinical setting.

Finally, CMS could redefine the incentive program parameters to include scenarios like mine. Despite the heroic efforts being made across the enterprise, this IDN is not likely to make it, with the fault squarely on the CEHRT vendors’ inability to deliver fully-functional products in a timely manner with skilled resources available to support the installation, configuration, and deployment. Morale will significantly decline, next year’s budget will be short the $MM that was slated for further health IT improvements, and the likelihood that it will continue with Stage 3 becomes negligible. Vendor lawsuits may ensue, and the incentive dollar targets may be recouped, but the cost incurred by the organization, its clinicians, and its patients is irrecoverable.

Consider applying the hardship exemption deadline extension to the incentive program participants.

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!

Email Address:

We never sell or give out your contact information. We respect our readers' privacy.