A little over a year ago this time, I stepped off a flight in Las Vegas. Being relatively new to the industry and attending my first HIMSS conference, I approached the conference with a mixture of wide-eyed curiosity and uninitiated timidity. Truthfully, the sheer breadth of topics and content was quite intimidating and at best challenging to sort out in my mind. The labyrinth of the Expo floor with over 1,300 vendors was dizzying – even for a veteran of multiple Dreamforce conferences (a much larger event, but yet with a more manageably-sized Expo).
For those who have not attend HIMSS previously, the conference (and the organization at large) differs quite a bit from your traditional, vertical-focused IT conference. Health IT has evolved on its own path and for a multitude of reasons (and for better or worse) is a different animal. The world of HIMSS has historically leaned toward to clinical side – or more tangibly, toward EHR technology. Given the regulatory environment (heavy incentives and some regulation to drive the move away from paper) and the history of the industry (how many other verticals have multiple information officers? Traditional CIO + Chief Medical Information Officer + Chief Nursing Information Officer), it makes good sense. Truly, last year, it felt as if we were drifting into a massive world of EHR and wondering if we were in the right place.
Fast forward to HIMSS19. Quite a bit has changed here at MST, and it turns out that we are in the right place. Our understanding has made the Healthcare IT world less intimidating, and I believe, we are fortunate to be involved in this vertical at a key inflection point in the evolving of software technology. It was clear from the first keynote (featuring Seema Verma – CMS Administrator – the most powerful regulator in US Healthcare) that the tone was changing. Interoperability. APIs. Digital Patient Empowerment. Those were the words of the day. The tone and message was clearly that as an industry, Healthcare has moved past the paper-to-electronic transition and is moving – quickly – toward what some might refer to as “Digital Transformation” like so many other industries have experienced – with a heavy, heavy focus on empowering the patient. Essentially, standardize and get the data into patients’ hands in coherent and comprehensive fashion. Paint a complete profile of patients’ health which includes Social Determinants (60% of our health-related activity occurs outside of the provider context) and financial (insurance claims data provide the closed-loop picture) information.
As Dr. Harlan Krumholz (Founder, HugoPHR) a presenter at one of the many patient-empowerment focused sessions expressed, Healthcare has been paternalistic in its behavior toward patients. We have acted as if we believe our patients are better off not knowing. In other words, providers know better and patients aren’t best served to control their own data. Given the complexity of clinical information, one might argue that the behavior is appropriate, but if we consider the same mindset in any other vertical – such as finance and banking where the information can also be complex – we would conclude that something was terribly wrong. As a result, we have created an aspect of patient experience with Healthcare that is simply unsatisfactory and when placed side-by-side with other modern consumer experiences (online/mobile banking, retail, social, productivity, etc.), seems downright strange.
Whether you agree with Dr. Krumholz or not, the evidence is fairly compelling. Conveniently timed (perhaps because the Administrator was a keynote speaker?), CMS released its proposed rule set referred to as Interoperability and Patient Access Proposed Rule on Monday, February 11th. As the name implies, the set of rules proposes to place considerable requirements for data access directly to patients for Medicare Advantage, Medicaid Managed Care, CHIP, and other major programs under its purview. Unlike other patient access requirements, such as those found in the 2015 ONC edition of Meaningful Use requirements – which take full effect 10/1/2019, these proposed rules impact payers as well. Following after Medicare’s own Blue Button 2.0 program that enable patients to access (and direct) their Medicare data, the rules require payers to provide API access – which, like the other regulations is intended to facilitate app development targeted at consumers.
Another regulatory indicator lives in the 21st Century Cures Act, which attempts to incent Health Information Exchange (HIE) at a national level. While participation is voluntary at this point, it is another standards-based approach to getting health data into patients’ hands and under their control.
The evidence of the trend is also quite visible in the private market. The big four EHR vendors (Cerner, Epic, Allscripts, AthenaHealth) now all have at least some degree of FHIR support and operate “app stores” of their own. The idea of “Connector” software supporting FHIR integration has numerous options available from startups to Google and Microsoft. And even though the Apple Health App is still in a Beta mode, there are more than 200 provider organizations who support the interface – with the number growing quickly.
Throughout HIMSS19, whether in the presented content or in hallway discussions, interoperability is clearly the hot topic. APIs. Standards. FHIR. SMART on FHIR. CDS Hooks. CARIN Alliance. Gemini, Argonaut, and Da Vinci. So many previously arcane terms have become quite mainstream this week. There is great momentum to realize the vision of patient empowerment – not only accessing, but owning and controlling their own health data.
Key Challenges Ahead
The vision of the future discussed at HIMSS truly offers the potential of a highly satisfying consumer experience. A rich market of app providers competing on the merits of their tools provides a cost-free option for consumers to take control of their Healthcare data – their Personal Health Record (PHR). Government, through a mix of mandate/regulation (CMS rule, 21st Century Cures Act, etc.), incentive (Meaningful Use Stage 3), and endorsement of standards (i.e. FHIR) creates the conditions under which the platform providers (i.e. EHR vendors, payers, and data providers (social determinants)) get data exposed. A quick look at the Apple Health App demonstrates how this might look for the consumer.
Unfortunately, it also brings to mind some challenging questions that were discussed in multiple sessions at HIMSS19. While not insurmountable, these concerns help ground our expectations of interoperability-driven patient empowerment.
PHR Data – Who Organizes?
One question that a visit to the Apple Health App will quickly raise is “Who is going to organize my records?”. If you have even the most basic of health conditions and history, you will have likely have in your history a series of different providers, labs, and other services with different health systems. You will also have a claims history with multiple insurance providers. If you’ve had any hospital admissions, you will likely also have a mixed degree of overlap in the records of your various providers and the hospital as a result of ADT notifications, routine records requests between providers (the dreaded fax), and perhaps images of the paper records you brought with you to see that new specialist that one time. Yes. If you’re pretty average, then you’ve got one big hodgepodge of records out there.
Let’s just say that the world has become nearly perfect and all of your providers have built conforming interfaces and made it possible for you to access your records via your app of choice. Now what?
You go through the process of registering with each individual provider, hooking up your app, and then you get data – a lot of data. But what will it look like? How will you deal with the overlap (duplicate) of records between providers? Will it be summarized in a coherent manner? Will the timeline of your health record make sense?
Of course, these problems can be solved. Salesforce Health Cloud is one example of a system that has features that aggregate health data from multiple sources and present them in coherent fashion. However, that is an enterprise, staff-facing tool whose implementation can be fairly extensive. So, who will do the same for the consumer/patient?
Some have advocated Health Information Exchanges (HIE) being the jumping off point. After all, they do have most aggregated data. However, they also have limitations. Most HIEs are regional – and participation is voluntary. There is a proposal from ONC called Trusted Exchange Framework and Common Agreement (TEFCA), under authority of the 21st Century Cures Act to establish a kind of national exchange. However, participation there is also voluntary.
Identification and Registration with Services
Of course, to organize, de-duplicate, and summarize data, we actually have to get to the data. If you have actually tried to get your records into Apple Health, you will notice that each and every individual service (whether payer, provider, or otherwise) requires you to identify (prove it’s you), register, and maintain a set of credentials (an identity) in order to connect to their service. As a result, you end up with a lot of different identities created and go through quite an initial process.
If we look outside Healthcare to more common consumer experiences, the solution seems to already be well-described. In so many of the different sessions at HIMSS19, the speakers inevitably compared Healthcare consumer-facing solutions (or lack of) to Amazon, Facebook, and Google. One feature often invoked is the notion of “login with” – as in, login with Facebook or login with Google. By using one of these trusted services to identify and validate the consumer, many web services simplify the login experience for users – who, in turn, only have to remember the one set of credentials.
Is healthcare different? Perhaps. HIPAA makes the stakes for identification and authentication quite a bit higher. However, it seems that services such as Google are more than capable of handling the issue. It’s more a matter of coming to agreeable to standard which every health information service provider will support. Hopefully, that same registration picture – something more like:
Certification and Standards Enforcement
Even if we solve all the other challenges, there is always the challenge of consistency and conformance to standard. Based on the anecdotal measures of mentions and conversations as well as hard metrics of vendors claiming support, it is clear that HL7 FHIR (dstu 3+) is the agreed up on API standard for Healthcare (especially clinical) information. Yet, those of us who have worked with the various EHR vendors very well understand that “FHIR support” can have many different meanings. Some implementations require significant investment of time and resources in configuration to actually make it function. Others, when fully functional, may not support all of the FHIR resources.
In this respect, we need to look to HL7 and government entities to help provide more transparency for providers and application developers so that we truly understand what we’re getting when we see that a given vendor supports FHIR.
What’s MST’s perspective?
MST has established a growing presence in the healthcare space, and we’ve enjoyed good success by partnering closely with our clients in broader and deeper fashion than our core focus might suggest. Through practical advisory and delivery experience, we’ve developed a deep knowledge in terms business processes and IT ecosystems, working with provider organizations. We better understand how our core capabilities (Salesforce + Cloud and Architecture + Integration) map into the current state of our clients in Healthcare.
As we’ve learned in our own context, so many think of the challenge as integration (getting systems to talk to each other) and the solution as interoperability standards (defining a common language). While both are somewhat true, we believe that the foundational challenge is not integration per se, but rather the foundational architecture of a provider’s IT ecosystem. Good design and good practice facilitate integration just as important as standards-based implementations. In fact, we feel that it is perhaps more important. You can successfully deliver an empowering experience to the patient and give comprehensive and coherent access to their records without necessarily supporting a standards-based API. It is less efficient and more difficult for sure – but it is doable. However, you cannot successfully implement the standards-based API (at least well) without good, foundational design.
That said, we whole-heartedly support the further of these standards-based efforts and will invest our technical efforts in engaging communities like HL7 (FHIR), SMART on FHIR, CDS Hooks, Google Healthcare API, and the CARIN Alliance. We will seek to build solutions using these standards both to develop our own library of applications/modules and as a preferred mode of solution implementation for our clients.
As a Salesforce partner, we will leverage experience combined with evolving standards to deepen our expertise integrating Salesforce Health Cloud with EHRs and potentially supporting Patient-Directed Exchange via the Salesforce platform. As a natural data aggregation point, CRM platforms like Salesforce can potentially be the location where individual patients’ disparate records are organized, filtered, and summarized.
It is an exciting time in Healthcare Information Technology. The idea of helping to close the gap between today’s patient experience and what consumers have come to expect with the likes of Amazon and Apple, is very appealing. We look forward to partnering further with leading providers to deliver solutions that make tangible impacts to their patients’ experiences.
