Vision Statement: Build
We want to empower your developers to create innovative and seamless solutions on top of Awell. By providing them with the right tools, you can quickly and easily integrate Awell into your projects, allowing them to focus on creating amazing experiences for their users.
The Build stage of the CareOps lifecycle is all about enabling your software engineers to work with and build upon our technology. The overall goal of product efforts in this stage is continuously lowering the effort required to build on top of the Awell software.
Building on top of Awell
Healthcare for the many, not the few.
At Awell, we want to empower healthcare providers of all sizes and technical abilities to easily and seamlessly integrate Awell into their business. We strive to be a platform for providers who want the flexibility to build custom integrations on top of our APIs, as well as for those who simply need a solution that works out of the box with minimal development resources required. We believe that by offering both options, we can cater to the needs of a diverse range of healthcare providers.
Want to build custom integrations? Use our robust set of tools (SDKs, APIs, …) that enable tailoring our platform to your specific needs. Need something simpler? Our low-code integrations offer a fast and easy way to get you up and running with Awell.
Regardless of the option you choose, we are committed to giving you an experience that is reliable, secure, and easy to use. Our goal is to help you focus on what really matters – providing the best possible care to patients – while we take care of the CareOps infrastructure. Ultimately, we want to be the partner you can rely on to help adopt and implement CareOps practices because we strongly believe it can drive continuous improvement in care delivery (read more in our https://awellhealth.atlassian.net/wiki/spaces/AH/pages/3503783957).
How will we do it?
Build breadth and separate concerns
When you start to untangle what’s underneath an integration with Awell, there are three components you can look at:
The user interface (UI): defines what the application looks like for your users (patients & clinical stakeholders).
The behavior: a set of utility functions, hooks, … that deliver ready-to-use functionality for a developer and help you define how your application behaves.
The API integration: this defines how your application communicates with the Awell API.
When building tools focusing on one of these components, we understand we have to make some prioritization calls as we don’t have an unlimited developer capacity working with infinite time. We bound ourselves to use insights to help make these prioritization calls.
Some examples:
The user interface (UI): build a set of UI elements in React first but not yet in Vue
The behavior: show questions one by one (conversational) instead of on a single page
The API integration: client-consumable API vs. M2M API, Node.js SDK vs. Rails SDK
However, we are aiming to provide a maximum amount of flexibility to developers in terms of which opinionated choices they accept. That flexibility is something we believe we can achieve by separating concerns and offering solutions that decouple these components from one another.
The user interface
When the UI is decoupled from the behavior and the API integration, you can choose to either:
Use pre-built UI elements by Awell (much like https://stripe.com/docs/payments/elements) that still allows for customization so it can match your brand.
Use your own design system or components so you have full flexibility and are not limited by any opinionated choices by Awell.
And given the UI is decoupled from the other components, integrating the behavioral & API components should still be a breeze.
The behavior
Developers should have the tools available so they can easily adjust the behavior of their application and have access to utility functions that prevent them from writing complex logic to make their integration with Awell work. While the solution might be similar to the tools needed for the API integration (eg: some form of SDK), we believe the distinction between the 2 is important to have.
The API integration
We want to provide developers with the tools they need to easily and seamlessly interact with our API. We believe that having an SDK simplifies interacting with the Awell API as we don’t want developers to write and maintain API integrations with Awell.
Our vision is to create an SDK that is easy to use and supports a wide range of programming languages, auth options, and frameworks. We understand that every developer has different needs and preferences, and we want to ensure that our SDKs can be tailored to meet those needs.
Low-code integrations
We want you to be able to get up and running with Awell within one day, and that’s the premise of our low-code integrations. It should save developers time and effort, reduce development costs and at the same time provide a secure and optimized experience for all your stakeholders involved.
These low-code solutions will typically combine all of the three components which comes with great benefits, but also some trade-offs:
With only limited development resources (one day), you can start using Awell out-of-the-box
These drop-in solutions are opinionated because they will are built & maintained by Awell
Offers only limited flexibility in terms of customization
Integrated & drop-in solutions
While drop-in or plug-and-play solutions are at first sight similar to low-code solutions, these are not pre-built apps but rather front-end SDKs that can easily be imported into your apps and offer more customization options.
Where low-code integrations have the least flexibility for customization, these drop-in solutions - while still somewhat opinionated, offer more flexibility for customization.
Low-code integrations can also be integrated in our your apps, but then you are limited by doing that in an iframe. Whereas these drop-in solutions can really be imported as components into your apps.
It’s a spectrum
At Awell, we want to empower healthcare providers of all sizes and technical abilities to easily and seamlessly integrate Awell into their business.
That’s why we understand that there is a spectrum or continuum to integrating with Awell depending on your size, technical abilities, technical resources, and use case.
In general, there are 2 trade-offs to consider on this spectrum:
Flexibility & Customization: low-code integrations will offer the least amount of flexibility and customization compared to custom integrations where you have almost unlimited degrees of freedom.
Developer effort: low-code integrations can get you up and running with Awell within a day with very limited developer resources compared to custom integrations that will require more engineering lift.
We also believe that you might want to move along the spectrum and maybe start with Awell using a low-code integration but over time might have an appetite for transitioning to a more custom integration. It’s actually also a path we would encourage you to take (start small, learn fast).
Where are we today?
Build breadth and separate concerns
The user interface
Currently, there is no decoupled UI library available yet. We started building a library of UI components, but currently, it still combines the user interface component with the behavioral component.
The behavior
Currently, there are no utility functions, hooks, or SDKs available.
The API integration
Currently, there are no SDKs available. If you opt for custom integration, you are still required to interact with the API through regular API calls (with or without a GraphQL library). Additionally, the Awell API today is a M2M API only so you have to make sure all API calls to Awell are made from a server/back-end.
Orchestration stories
Although today we don’t have any tools available for developers that could help them with the user interface, behavior, or API integration. We do have Orchestration Stories available, this is a collection of interactive code samples that perform simple tasks using the Orchestration API (built using NextJS).
These code samples can be used as a starting point to understand how the user interface, the behavior, and the API integration can be tied together.
Low-code integrations
We have Awell Hosted Pages, which is a prebuilt app where patient and clinical stakeholders can interact with activities in care flows. It is the quickest way to get started with Awell.
Integrated & drop-in solutions
Currently, there are no drop-in or plug-and-play solutions available that developers can use
Awell as an integrated solution
Besides investing in the tools to build on top of Awell, we also want to make Awell easily extensible which we’re doing through our Extensions architecture.
The Awell Marketplace
We want to create an Extension Marketplace that enables software developers to showcase their extensions while providing non-technical users with access to a vast range of powerful and easy-to-use solutions for their care flows.
On one hand, the Marketplace should become a central hub for developers to share their expertise and collaborate on new ideas. By fostering this community of creators, we will enable the rapid development and distribution of high-quality extensions that address the needs of our users.
On the other hand, non-technical users will benefit from the ease of finding and integrating powerful extensions into their care flows, not only saving them time and resources in the development process but also allowing them to easily integrate their care flows with any 3rd party solution out there.
Homegrown and 3rd party extensions
Extensions will both allow integrations with other 3rd party software providers (think Healthie, HelloSign, Twilio, …) and Homegrown or proprietary apps or systems. While the former type of extensions will usually be published on our Marketplace so others can use them as well, we understand that the latter type of extensions will mostly be private extensions that you do not want to expose to the outside world.