When building software, people used to come up with an innovative idea, build a product, and then try to sell it. Once they tried to sell their product, after many months and millions of dollars of building, they would quickly (or not so quickly) learn that even if they were directionally correct, they were significantly off in the details, and needed to evolve their product vision into something that better fit their customers’ real needs and workflows.
Eventually, with the onset of agile and lean methodologies, software development teams figured out that rather than optimizing for execution speed, it made more sense to optimize for future flexibility and for the amount of learning per dollar invested.
Software providers began to do seemingly crazy things like selling products before they’d even built them. Prototyping became more common, and teams started reciting mantras like, “make decisions at the latest responsible moment”.
Still, even with agile/lean product development, the end goal is generally to build a single product that works for as wide of a segment of the market as possible. However, there is another step that can be taken in certain situations that can further increase the chances that a tool will be a great solution for all of the use cases it’s meant to address.
Configuring for Scale
Consider for a moment Microsoft Word and Salesforce. MS Word is a many-featured solution to word processing. It can do a thousand things (some would argue too many things), but it does basically the same thousand things for everyone who uses it.
Salesforce, on the other hand, has some features that are common across all deployments, but nearly every configuration of the system is different. You almost can’t use Salesforce out of the box. Every implementation starts with a configuration process, generally requiring professional consultants. What makes Salesforce successful are the tools that make it relatively efficient to configure, so specialized implementations take only a fraction of the time that building a similar system from scratch would take.
In B2B settings, the model of configurability is common and successful. In healthcare, for example, EMRs are built with the Salesforce model. People often say about EPIC that “if you’ve seen one implementation, you’ve seen one implementation.” Meaning that it can feel like there’s almost nothing in common about EPIC as it’s configured across different hospitals.
When building a configurable product platform like Salesforce or an EMR, you have to make the configurability itself easy to change and evolve. The goal is to make configurability itself scalable. Not only are you trying to optimize the code behind specific features in the system to be inexpensive to evolve in the future, you’re also trying to make the code that controls the kinds of things that can be made configurable flexible.
As a new generation of conversational technology (chatbots) begins to mature, there is a new configuration bar that will be required to deal with the additional complexity layer of language and bi-directional messaging in high scale, complex environments like healthcare.
The Conversational Patient Experience in Healthcare: Configuring for Flexibility and Complexity
Healthcare IT generally lags other industries due to the complexity of its mission critical regulated workflows and processes. What will it take to move healthcare IT into the realm of advanced conversational engagement between providers and the hundreds of millions of patients seeking a better experience?
To start, patients are spending the vast majority of their mobile time in digital messaging platforms. Since that’s where patients are, that’s where the healthcare technology industry needs to “meet” and engage them.
To do that, a conversational platform needs a healthcare Domain-Specific Language (DSL) for defining conversational workflows that include the kind of specific features that are unique to healthcare. The chatbot designer needs the ability to define broad range a things, including:
-
The specific language the bot will use
-
The input options that will be made available to the end-user
-
The logic for how the interactive conversations flow
-
How data that comes in from integrations is used
-
How data is returned to systems of record
-
How events are tracked
-
How and when patients are authenticated
To make the DSL as flexible as possible, conversational designers will also need the ability to add code (e.g., JavaScript) directly into the bot as needed. This allows bot designers to use the authoring DSL in new ways that have the potential to address a range of challenges and opportunities as solution adoption increases and matures.
Over time, certain patterns will emerge in the way the DSL gets used. These can be a bit like the dirt paths that appear across the grass on college campuses where students actually walk, as opposed to the paved sidewalks where they’re supposed to walk. And as those patterns become more apparent, they turn into the guideposts for new configurability features and value delivery mechanisms.
The common patterns that naturally emerge can then be abstracted (e.g., DRYed up) into components that automate common and easily reusable tasks across a broad spectrum on conversational solutions. It’s like paving the dirt paths where they are, instead of trying to keep replanting the grass. Or, perhaps it’s like waiting to lay down any paved paths at all until the dirt paths emerged.
With these conversational pattern components, bot designers are able to sacrifice a small amount of flexibility for a huge amount of speed.
The Long Game Plan: Configurable Configurability
When building these conversational components, the trick is thinking ahead about how they can be built to be easily extensible. As use cases and new requirements expand, conversational authors need to be able to address unanticipated concerns quickly.
One way to do that is to make it easy for bot authors to extend their solutions with bespoke features, supplementing existing components with the original bot DSL. Then, when designers and authors see multiple solutions extending existing components in similar ways, they can then add new features to the underlying components or build whole new components as needed.
It is also important to keep an eye out for where a component has unnecessary configurability — features that are either only used by 1 or 2 customers, or that could be accomplished nearly as well in another, simpler way — and rip it out.
And, the abstraction doesn’t stop with conversational components. Go back to the Salesforce business model. Although each industry uses their version of the Salesforce CRM tool in substantially different ways, a number of large companies have built businesses around creating a specific configuration for a specific industry niche. Part of the reason they have been successful is because their customers are from a common industry vertical and frequently have the same pain points and opportunities.
An exclusive focus on the healthcare vertical allows for the next level of abstraction by solution designers. Conversational components can be configured into specific solutions for specific patient journeys — a concierge for emergency room visits, a referral management workflow, or a periop patient assistant. These solutions can be configured directly in a fraction of the time than even building solutions from conversational components, and much much faster than starting with a base conversational DSL.
In these cases and many others, specific health care organization workflows are slightly different, yet mostly similar. Learnings from one are likely to be applicable to others. The trick here is choosing the right elements to make configurable so effective conversational solutions can easily be spun up, modified, and maintained over time.
Hospitals can’t ultimately have 35 vendors providing software to their patients. The overall patient experience would be a disaster, even if each individual solution were pretty good. Healthcare organizations will ultimately prefer a single system of engagement that can do everything over a wide portfolio of individual solutions.
A successful conversational platform and product development strategy has to be designed for configurable configurability. Ultimately, that’s the kind of platform that will become a standard for patient engagement, sitting on top of EMR systems of record, automating countless healthcare processes and operational workflows between providers and their patients.
That’s what’s needed for healthcare organizations to actually deliver the next generation of patient experience.
