“Transformation is an ongoing process that tends to appear ordinary, when, in fact, something extraordinary is taking place.”
Dr. Suzy Ross
There’s considerable focus in the healthcare IT industry on digital transformation. While it may seem like a buzz word, it represents a significant shift in thinking about how an organization uses the intersection of people, processes, and technology to ultimately change how it delivers value.
At the heart of many digital transformation initiatives is the concept of digital platforms. A digital platform can be defined as the technology, people and processes that create value between two or more distinct types of customers by enabling frictionless acquisition, scalable growth, on-demand access and speed, and trust. An important concept here is that the term “customers” refers to different users of the digital platform. For example, the customers for Uber’s digital platform are people seeking rides and people offering rides. Extending this thinking to our industry, the customers could be citizen’s accessing their EHR data through a provincial
viewer, and on the other side are clinicians contributing and consuming EHR data.
Another key attribute in digital platform thinking is the concept of “frictionless” acquisition. In many ways this obsession with removing friction points is what differentiates for-profit digital platform companies from the more traditional thinking in healthcare organizations where the focus is still on removing “barriers”.
Our industry has many barriers to the seamless delivery of care and exchanging information between organization. For example, forcing clinicians to remember and constantly reset different login credentials across their local, regional and provincial systems is a barrier to adoption.
Digital platform organizations already know that barriers are business killers and are now competing on removing anything that a user might find annoying but doesn’t prevent them from committing to the use of the digital platform. It can be as simple as removing the friction of entering credit card information by using the camera on a mobile device to read the credit card details and populate them in a web form. Entering credit card data isn’t a barrier to a user buying something online but making it easier for them to do so removes friction.
Complimenting the obsession with removing friction points is the aggressive partnering to integrate digital platforms and technologies. This often means looking at traditional and non-traditional competitors to find ways to partner and integrate platforms using APIs to provide a seamless experience for clients. For example, first Google opened its Google maps APIs to the world, which Uber then integrated into its digital platform. Overtime, Google integrated Uber’s APIs to suggest Uber rides and potential costs as one of the transit options when selecting directions to a destination.
Contrast this type of thinking with what we’ve seen in the healthcare industry. It seems most applications were developed as an end point; a place for data to go in but not for data to go out. Any attempt to integrate these applications has been costly, and tended to be one offs, leading to costly integration efforts for each new data exchange.
The good news is we’re starting to see more digital platform thinking in new healthcare IT initiatives. More and more organizations – both for-profit and non-profit – are offering APIs. We’re also seeing more commonality in how the APIs are designed (e.g., use of REST, Open API specifications, OAuth 2 and OpenID, etc.). However, none of these technologies get at the heart of the data exchange challenge in healthcare, namely the structure, syntax and codification of health care data to be exchanged in the APIs.
This is where HL7’s FHIR comes in. FHIR is HL7’s first publicly available standard. By making it free and removing the registration friction point, anyone in the world can access it online without needing a username and password. FHIR, like any standard, requires further specification as to how it is intended to be used in particular APIs. There are many initiatives around the world where industry vendors are joining forces to establish minimum FHIR resource profiles to be commonly used in their APIs. The key word here is minimum.
For example, one vendor consortia’s medication resource profile only requires implementers to support the “drug code” data element. Implementers can support more data elements if they choose, but at a minimum they must support drug code. This is hardly sufficient to support advanced use cases such as ePrescribing and medication reconciliation, but the goal here is to make it as easy as possible for vendors to adopt the profile and embed in their APIs (i.e., frictionless, wide-spread adoption).
Given that many of these consortia are comprised of US based vendors, we can expect to see these APIs in the products sold in Canada. Which leads to the need for creating Canadian baselines of the FHIR resources used by these vendors. Going back to the medication resource example, the profile requires the RxNorm value set for the drug code. RxNorm is not used in Canada. In order for this API to work in Canada it would need to support DIN or some other Canadian drug code system.
The Canadian FHIR Working Group on Infocentral is taking these US-based vendor FHIR resource profiles and trying to determine the minimal changes required for them to be used in APIs in Canada. Again, the key word here is minimal. History has shown that vendors will not customize their products for the Canadian market beyond the minimal required to fit within legal and regulatory frameworks.
In terms of practical application, the goal is to maximize the number of organizations – whether for-profit vendors or government funded EHR programs – building their digital platforms with common FHIR resource profiles in their APIs, and over time elaborate the base profiles to support more sophisticated use cases.
On the surface, these efforts to standardize healthcare data in support of digital transformation initiatives may seem ordinary, but in fact, they represent an extraordinary change in how the industry is approaching interoperability challenges.