Welkin Health

Today we’re talking about Welkin and how it’s used at your company. Could you give us a brief overview of the company and your role there?

Our company provides services remotely, using tools like Zoom, phone, and text, to assist patients dealing with diabetes. We’re building out a comprehensive service platform that covers everything from coaching to the actual provision of care by licensed medical professionals like doctors and nurses. Right now, we’re operating in just one state. Even though we’re small, we’ve got plans to expand across the nation in the future.

Welkin is our Electronic Health Record (EHR) system. We’ve also tapped into some of Welkin’s features that resemble a Customer Relationship Management (CRM) system, something you don’t typically find in traditional EHRs. That’s why we chose Welkin. On one hand, all of our providers use it to connect with their patients, take and review clinical notes, etc. We also use it for workflow automation and providing more longitudinal care. What sets us apart is that we’re really focused on the patient journey over time, rather than just handling individual transactions like many other healthcare setups. We’re using Welkin to track the patient’s progress and see how our care is impacting them over time, allowing us to make necessary adjustments. So, in a nutshell, that’s how we leverage Welkin and why we chose it over other EHRs.

I’m a senior program manager here. I work across departments on high-priority initiatives. My main focus is to make sure that products and projects within each department are in sync with our overall company goals and strategic initiatives.

How did you initially conceptualize the job-to-be-done when you decided to use Welkin? How has this perspective evolved as you’ve gained experience with its implementation?

For us, this broke down into two categories. The first is standard – ensuring that our providers can effectively care for their patients in a virtual space, including conducting virtual visits, taking notes, reviewing notes. We wanted a system that our providers could use relatively simply and intuitively. They need to see and share information across our care team, which is multidisciplinary.

The second facet revolves around one of our core organizational objectives – establishing a data-driven learning culture right from the outset. We needed a system, with its APIs, that could effectively handle data extraction, management, and analysis, to help us improve our clinical operations over time. When we were in the initial stages of considering Welkin as our solution, a significant question was, “Can this system effectively cater to the needs of our clinical users, such that we don’t need to switch to a different system in a year or two?” Furthermore, does it provide us with a solid foundation to evolve into a data-focused organization, capable of conducting the right analyses and generating the right reports? This also implies a system that’s able to integrate well, because as everyone in healthcare knows at this point, no one system can do it all. No matter which system you buy, integrating with other systems at some point is inevitable. So it was important for us to find a system that integrated data through a bi-directional data exchange.

When did you procure Welkin and how long have you been using it in production?

We purchased it at the beginning of 2023, and launched it in the middle of the year. So, we’ve been using it for about three months now. During this span, we’ve employed Welkin to cover a wide spectrum of activities, ranging from our coaching services to delivering actual medical care remotely via the system.

There are three areas I’d like to dig into. First is the clinical interface: how does it fare for your providers? What workflows does it excel at, and maybe which ones didn’t quite align with your care model? Secondly, your mention of the longitudinal approach to care is intriguing. I’m eager to delve into how Welkin approaches patient journeys. Lastly, the extensibility factor seems important. Shall we kick things off with the clinical interface?

Firstly, Welkin is different. It doesn’t look or feel like your typical EHR, which is not necessarily a good or a bad thing, but worth knowing. Now that our providers have started using it, we have received predominantly positive feedback. Once you get the hang of it and know where everything lives in the system, it’s quite intuitive and easy to use. The overall look-and-feel of it is pretty clean. So, that’s been positive.

I’ll highlight, though, that Welkin isn’t your typical plug-and-play solution. It’s akin to crafting a website on platforms like WordPress or Wix. Welkin offers the foundation and the tools to mold it into an EHR that works for your organization’s needs, but it’s up to you to assemble these components in a way that works for you. While the interface works well, it requires a good amount of upfront work in building and tailoring the interface to meet our providers’ precise demands. Furthermore, Welkin is pretty customizable. We can tweak the system, within certain limits, to look and feel different for different roles. So, our medical doctors, coaches, dieticians, and social workers can each experience a slightly different interface, but this requires upfront work to build it and customize it. These subtle differentiations can make a pretty big impact on day-to-day usage by our providers.

Now, there are a few features we don’t use. For instance, relational therapies, which show relationships between patients. Their system includes care plans and patient goals, but we decided to not use that part of the interface because it didn’t work well for us to see the patient journey over time. In a nutshell, components like encounters, assessments, tasks, and calendars are clean and simple, albeit different from the standard system.

Staying within the realm of the clinical interface, are there features where you feel Welkin’s current capabilities might fall short, requiring either extensive customization or perhaps even a look beyond Welkin to address certain needs?

There are definitely areas where Welkin falls short in certain aspects. To give you an example, take the calendar interface. Many of our peers who also use Welkin have found it necessary to integrate with third-party systems such as Google Calendar or Acuity. The reason being, while Welkin’s calendar appears decent on the surface, it lacks some essential functionalities. For instance, if I am trying to schedule an appointment for a provider, I can view their existing appointments, but I can’t see their working hours or designated days off that they might have set. Scheduling group calls, involving multiple patients or providers, can also be hard to do. You have to get creative with workarounds. Another example is their chart notes. While they are different from the conventional EHR style, you can customize them to suit your needs, with a few exceptions. But once a note is finalized, a provider can’t edit it subsequently. This is on their roadmap and should get fixed soon, but I’d think they’d have resolved it faster than they have.

Here’s a crucial area for us: external care coordination. Our model heavily involves collaboration with patients’ primary care providers and other medical professionals. We aim to complement primary care rather than supplant it. When it comes to coordinating care externally, you want to be able to generate PDFs and attachments from patient charts and notes and send them externally. Here, Welkin falters. It lacks support for any form of fax, including e-fax, which is widely favored among medical providers. We’re currently circumventing this through our data warehouse. These are just a few examples that spring to mind. I think of them as limitations that one needs to keep in mind and work around.

It seems like one of Welkin’s strengths lies on the patient journey side. Could we delve into this aspect further and explore how you’re using this functionality?

One thing we discerned when looking at EHRs, which wasn’t exactly a surprise, was that they’re built to be transactional in nature. They’re geared towards enabling providers to swiftly access patient charts, skim over necessary medical history, complete an interaction, and promptly move on to the next patient. Our vision, however, extended beyond this. We really wanted the ability to not only from a data perspective but to visually show how a patient progresses through our programs and through our services. This is where Welkin’s “programs” component comes into play, which is reminiscent of a flowchart or tools like Lucid.

How we use this is that we’ve essentially created a program for each of our core service lines, recognizing that not all patients require the entire spectrum of services we provide. This approach allows us to do two things for any given patient. First, we can visually and promptly see which service lines they’re engaged in or which services they’re availing of within our organization. Second, we gain insights into where they are in their journey for different services, over time. For instance, if a patient is enrolled in a program providing supplies or prescriptions, the system not only indicates their participation in that program but also provides a granular breakdown of their journey within it. This means we can readily discern whether they’ve completed the application, if approval has been granted, and whether we’re in the process of awaiting delivery or confirmation from the patient. This is really helpful, because imagine if one of our care team members steps in to deliver care to a patient. They often need not only key medical history, typical of other EHRs, but also an understanding of the specific services or programs the patient is engaged in, and where they stand within these programs. This allows our educator to vary what they provide not only based on the individual but also their program or service line. This dynamic allows us to provide supplementary resources or referrals that might otherwise evade our attention, all contingent on the patient’s stage in their individual journey.

Do patient journeys integrate with external data sources? Are you able to learn what’s going on with a patient outside your platform, potentially utilizing APIs or independently working with the data?

It’s a mix of both, based on the data’s origin. Welkin does come with built-in connectors and integrations with platforms like Health Gorilla for labs, DrFirst RCopia for prescriptions, and even DocuSign. DocuSign is an example of a built-in integration where all the action takes place within Welkin. When we require documents to be completed and signed by patients, we can manage the entire process within the system. Upon completion within DocuSign, Welkin automatically updates the status to “complete,” uploads the signed document to the patient’s profile, and can even trigger subsequent automated actions. The system could advance the patient to the next stage within their journey or prompt a provider to carry out a specific task.

For many needs, these integrations are not built in, which is where Welkin’s APIs give us a pretty way to do what we need to. For instance, when propelling a patient through their journey, Welkin’s workflow automations largely hinge on data type updates (e.g., filling out a form). If, let’s say, external confirmation arrives that a shipped item has reached the patient, Welkin’s APIs auto-updates the relevant data field that says confirmation receipt, for example. Welkin then uses this trigger to progress the patient, initiate tasks such as a provider call, set up an educational session, or enact other relevant actions.

Even if Welkin doesn’t have a pre-built integration with an external data source, if you can get the engineering team to set up and use the API, it’s pretty easy to still automate workflows.

How does this compare with some of the other clinical operations tools out there, like like Awell and Dock Health? How did you decide to go with Welkim, which seems to have a lot of patient journey modules built in, as opposed to selecting another EHR and then integrating a third-party solution?

Personally, I tend to advocate for reducing the number of systems you have, whenever possible. The more systems you have connected, the more things there are to break and issues to deal with, especially around your source of truth. That was one of the inputs – Welkin’s capacity to do in a single system what an EHR like Healthie does with Awell. Another factor was that we have been moving very quickly this past year. Had we decided we needed multiple systems, like another EHR and say, Awell for workflow management, you would have had to set each of those up, which would have delayed our use of those systems. It was easier from a data management and integrations perspective and a little quicker to go with Welkin.

These were not deciding factors, because Welkin ultimately had to work for our providers. But once the providers gave the green light to Welkin and a couple of other EHRs we demo-ed, we looked at data management from a scalability perspective. Having fewer systems to oversee not only simplified the initial deployment but also bodes well for our long-term expansion.

I’m keen to explore the extensibility side of things, which manifests through both APIs and front-end customization. Perhaps we could start by delving into the front-end clinical interface customization, and then discuss the APIs.

Customization was another advantage of Welkin. It does come with an initial layer of support and construction, as you need to build and customize it yourself. Roughly speaking, I’d estimate that between 50% to 70% of a clinical user’s day-to-day interaction is entirely customizable. What this means is that each time you access Welkin, the interface could appear completely distinct from what it looks like for another provider. Certain elements such as the homepage or the layout and filtering mechanism for managing organization-wide patients can’t be readily adjusted. But the core functionalities providers use extensively – encounters, notes, assessments, or in our scenario, program monitoring within the patient journey – can be customized entirely, pertaining to roles and permissions. Whether certain information is displayed at all, can be modulated based on distinct roles. This proves particularly beneficial for a multi-disciplinary team like ours, ranging from coaches to social workers and clinicians.

To illustrate, we’re able to distill insights from assessments and forms and put them in a concise patient summary view. For instance, a social worker might quickly understand a patient’s housing and social requirements without navigating through previous assessments. This real-time snapshot augments the efficiency of their ongoing tasks. Conversely, a health coach’s interface could be tailored to spotlight prior notes, patient goals, and any obstacles to success. Such customization enhances usability, so the interface aligns with the distinct requirements of various providers.

How did you find Welkin’s APIs’ overall robustness and comprehensiveness? What was it like to build on top of them and extend?

Broadly, I’d say Welkin’s APIs are pretty inclusive and widespread in terms of letting you do what you might need to do. But there are limitations. Consider their existing integration with platforms like Doctor First. These are helpful when it comes to the initial setup, but the integration is owned by Welkin. So, right now and probably for the foreseeable future, that integration leads to a unidirectional data flow. Welkin can seamlessly update and display data from Doctor First, but any attempt at bidirectional data flow hits a snag. Right now, if a provider wants to update a patient’s allergies or medication, they must leave Welkin and do it all in Doctor First, and then sync those changes to Welkin. We cannot use the APIs to do this ourselves because the integration is owned by Welkin. Apart from the experience besides the pre-built integrations, the APIs are easy to use.

If I had to rate their API documentation, I’d give it a B. It’s pretty good. The reality is that we’ve looked at a lot of EHRs’ API documentation, and many of them are not great and lack in a lot of areas. Welkin’s lacks in some areas. Sometimes, we’ve had to guess and run a few test runs to see if we’ve got the code right or wrong. But while some sections are slightly wanting, it stands above documentation offered by several other EHRs. Overall, Welkin’s APIs prove to be pretty good, meeting most of our needs, with only a handful of limitations that we’ve been able to work around.

Do you have any advice for other organizations wanting to build upon tier APIs or extend Welkin?

I’d say if you find yourself contemplating Welkin’s suitability for your organization, it would help to identify a preliminary list of potential integrations and connections you anticipate needing. That way, you can engage with Welkin’s team in these initial stages on those ideas and understand how their APIs could work or not work for your needs.

When we made this decision, we were guessing. We’re building something we haven’t seen in healthcare yet, so we’re guessing, but if you can have that foresight upfront, I would leverage the Welkin team ahead of time. I’d say that we’re thinking about integrating with this system or using the API to enable these kinds of data flows and analytics, and understand how those might work. In cases where such knowledge might not be available early on, and you have the right engineering talent, it looks like we’re able to do what we want or need with their APIs, with only a small set of limitations. At that point, you want to make sure you have a strong engineering team on your side.

How did you find the sales process overall with the Welkin team?

Overall, I’d say it was decent. Like many organizations, their sales approach followed a somewhat typical pattern. They seemed to have a standard demo pitch that they presented, which was a little frustrating, but this wasn’t solely a Welkin issue. We encountered a similar trend with other EHRs during our demos. Given that our operational approach significantly deviates from the norm, we found these pre-packaged pitches didn’t always align with our unique requirements. We needed to actively steer discussions towards how the platform could work for our needs. They were pretty responsive and cooperative. Welkin, being a relatively new player in the EHR landscape, seemed more capable of adapting and accommodating unique customer demands compared to more entrenched competitors. That was nice to see and it was nice to work with a team like that.

How did you go about comparing Welkin with other solutions in the market? What factors did you consider and how did the different products stack up against Welkin?

Our evaluation process was quite structured. We began by conducting an in-depth needs assessment within each department, outlining what was essential for both clinical operations and our data and information systems. This helped us identify our high-priority must-have features. Once we narrowed down our choices to Welkin and a few other strong contenders, we assessed two key aspects: usability and the system’s underlying structure, from their APIs and documentation to the extensibility. We are so heavily focused on using data to support our clinical team and to support our growth and scale, and not every system is built in a way that allows that.

Among the contenders, Healthie was a strong competitor, but we were concerned that it might require additional integration with Awell to fully meet our needs. Otherwise, it was pretty good. We also looked at Elation, which was the most traditional of the EHRs we had in the running. It was a favorite among some of our clinicians, given its quick and easy-to-use interface. But we found its API documentation lacking, and felt like it would be difficult for us to scale with and become the learning organization we wanted to become. We couldn’t just look at short-term usability. Pricing was another consideration. While their individual pricing was similar, we also factored in the potential costs of integrating additional systems that the other solutions might have required.

The question for us was whether Welkin could work for our clinical team once they got used to it and whether it could be set up from a data perspective such that we could use the data across the organization to truly grow. Ultimately, our clinical team adapted to the Welkin interface, and the potential for data integration across the entire organization sealed the deal.

Before we wrap up, I’d like to know what your experience with customer and product support and account management has been, with Welkin.

Overall, it has been positive. It’s important to note that we use their enterprise support, which is a paid add-on service. This gives us enhanced access and direct communication channels with their team. So, I can’t speak for organizations that don’t opt for this level of support, but we benefit from using their Jira ticket management system and regularly chat with them through platforms like Slack. We’ve had the same two or three representatives we’ve worked with since the early days of our demo and sales process, which has provided continuity and a deep understanding of our needs and goals.

Welkin’s support team, like many tech companies, is not well-connected with their engineering team. So, when we ask them questions, they often don’t know. They are responsive and quick to engage with their engineers to address our queries, but it’s something to keep in mind when you reach out to them, particularly if the query is urgent or time-sensitive. Even if they’re quick to respond, they might have to wait on the engineering team to respond to them, which might put some additional time and delays on the overall process.

What is the likelihood of continuing to work with Welkin over the next 2 to 3 years?

I would say it’s highly likely that we’ll continue using Welkin for the next couple of years. We don’t see any compelling reasons to switch at the moment. Looking further down the road, it will be interesting to observe how Welkin evolves and expands its platform and offerings. As part of our growth strategy, we aim to work with larger patient groups and communities, and currently, Welkin’s capabilities may be somewhat limited in that specific aspect, focusing more on one-on-one care. However, Welkin is actively developing its features and making updates, which is promising. So, whether we continue with Welkin in the long term may depend on how well their product aligns with our evolving needs and goals. We’re both young organizations, and our trajectories may influence this decision. But for now, we have no immediate concerns or plans to explore alternatives in the next couple of years.