Care Pathway as an SDK for a Digital Platform – Is it a viable option?
Another option that hospitals and healthcare organisations may consider is implementing care pathways as an SDK (Software Development Kit) as part of a larger digital platform. This would mean that the care pathway functions would not be in a standalone app, but would be embedded as part of the existing hospitals' digital app using the SDK.
This model brings many of the same challenges as the fully integrated app model, but it also has its own specific problems:
Dependencies increase further.
SDK development is expensive and complex.
The responsibility of the digital platform developer increases significantly.
Overall costs can become too high.
This blog explores why SDK-based implementation may not be the best solution for supporting care pathways.
How would the SDK model work?
In the SDK model, the care pathway developer would produce a ready-made software development kit that the hospital's digital platform developer would integrate into their own app. The SDK would include, for example:
User interface components (e.g., questionnaires, task lists, patient progress tracking)
Data transfer interfaces to the care pathway system
Possible background functions (e.g., notifications, appointment handling, certain logic)
This could theoretically reduce the need to build a separate care pathway app and give the patient a single point of access to all digital health services. But in practice, this involves many difficult challenges.
1. Too broad and heavy an entity
The SDK model combines two different systems: care pathway management and general digital services. This brings the same problems as a fully integrated app:
User experience may suffer because the care pathway logic is not separate but embedded within another app.
Notification management is confusing if different services compete for attention in one app.
Usage paths are different and can get mixed up: care pathways are active, and the digital platform is passive.
Using an SDK does not solve these problems; it brings new challenges.
2. Dependencies slow down development
Even though the SDK model would give care pathway developers a separate development environment, it does not eliminate dependencies on the digital platform's development:
All changes to the SDK require compatibility with the digital platform, and development slows down significantly.
The well-being county's digital platform developer must deploy and update the SDK regularly, which can cause further delays. This may require dedicated resources.
Potential bugs and problems can be difficult to fix because they can be caused by the SDK, the digital platform, or their interoperability.
For example:
If the care pathway developer wants to add, for example, a new questionnaire type or report view, it cannot be done independently, but requires the support of the digital platform developer.
If the digital platform is updated, it may break the SDK's functionalities, which requires additional testing and coordination.
SDK Development and Maintenance Are Expensive
3. SDK development and maintenance are expensive
Implementing an SDK requires high-quality development for several different platforms so that it can be integrated into the digital platform's app:
iOS: Swift/Objective-C
Android: Kotlin/Java
Flutter or React Native
This means that the SDK developer must maintain and develop several different versions of the SDK, which makes the solution expensive and complex:
Additional costs in development – specialised mobile developers are needed.
Testing and coordination increase costs – the SDK must work seamlessly with different versions of the digital platform.
Version management and continuous updates – if the digital platform changes, the SDK must keep up.
In practice, this means that the overall costs rise quickly because both the SDK developer and the digital platform developer must do significant extra work to ensure compatibility.
4. Additional work for the digital platform developer
The SDK model's success depends not only on the SDK developer but also on how well the digital platform developer can integrate and maintain it. This brings additional challenges:
The digital platform developer must have expertise in using and updating the SDK.
SDK integration requires additional development and possibly user interface customisation to fit in well with the rest of the app.
Potential compatibility issues can cause significant delays.
This means that the well-being county's digital platform developer must commit to long-term use and updates of the SDK, which may not be cost-effective.
Summary: The SDK model is not optimal for care pathways
While an SDK could theoretically provide a way to integrate care pathways into a digital platform, practical challenges make it an impractical and expensive option.
Too broad and complex entity → User experience suffers, and notifications can get lost.
Development dependencies slow down both parties → The care pathway developer and the digital platform developer must work closely together, which brings additional costs and delays.
SDK development and maintenance are expensive → Versions supporting several different platforms are needed.
Significant additional work for the digital platform developer → SDK integration and updates do not happen automatically.
Best solution?
A separate care pathway app offers the best user experience and enables rapid development.
API-based integration with the digital platform makes the most sense when interoperability is desired; an API solution is lighter and much more flexible than an SDK.
Flexible modularity → Care pathways can evolve without being tied to changes in the digital platform, and the digital platform without being tied to care pathways.
An SDK may be an attractive option in theory, but it does not eliminate the problems of a combined app. It just moves them to a new level and makes the solution even more expensive and complex. Therefore, a standalone care pathway app is still the best and most sustainable option.
