This is the second article of a series dedicated to Healthcare IT platforms. The following aims to describe the foundations of our healthcare platform and how it differentiates from others.
Several concepts mentioned here are tightly related with those mentioned in the first article “Healthcare IT Platforms”.
What can be improved?
By analyzing the existing healthcare software platforms, one can infer several of their main goals:
- Provide a “place to live” to healthcare applications
- Improve the interoperability by enforcing certain standards
- Serve as a one-stop shop to the end users
- Reduce the complexity of developing healthcare applications
- Shorten the time to market (TTM) of new applications
While it is important to take all of them into consideration, we are focusing more on the last two, as we have identified that there is still more to offer, compared to other products.
The complexity of developing healthcare applications can be reduced in two extremes:
- By taking care of specialized topics, like the clinical repository or the interoperability features.
- By taking care of more general topics, like identification and authorization as well as the whole user interface development.
The weighted importance of each one will depend on the individual capabilities of the development team, but handling both extremes will contribute to the reduction of the uncertainty regarding the success of a development project.
Shortening the time to market
The TTM may determine the success or failure of a product’s development, as competing companies may be developing similar products and deliver them faster. Even if a product is better than others, the adoption rate can influence the decision of other care institutions.
This factor not only applies to new products but also to the capability of a product to evolve fast, following the current trends in agile software development. Cloud and mobile applications are now updated on a monthly or weekly basis, rather than the old-fashioned quarterly or yearly release cycles.
The Healthcare IT Platform revisited
So, our ultimate question is: how we can improve the mentioned aspects of a healthcare IT platform?
A standard response provided by several platform providers is: by eliminating repetitive tasks for developers.
We can find this is true for most backend operations: authentication, authorization, storage and retrieval, interoperability, etc. have already been covered, but the frontend development is still a responsibility of the software manufacturer.
On the frontend, we can still identify repetitive development tasks, especially related to the user interface: fill-in forms, worklists, schedule calendars and even imaging viewers. Some offerings also leave the developer the responsibility of hardcoding their business logic (authorizations and workflow).
Converge with Low Code Development Platforms
Low Code Development Platform or LCDP is a new term for the inheritors of the Rapid Application Development tool predecessor. Some relevant examples of LCDPs are Salesforce, QuickBase, Appian and Microsoft PowerApps.
Among the common features of LCDPs are:
- Form builders with drag-and-drop designer
- Process workflow modeling
- Database integration
- Mobile support
- Application marketplace
Most products require no or minimal programming for building an entirely functional application that can be ready in a matter of days following the design stage. The participants are no longer just developers, but other IT professionals, end users and the product owner.
LCDP can offer a combination of visual or spec-based design facilities. While visual tools are best suited for non-developers, written specifications like JSON or XML files may be faster for developers and even passible to automation.
Revisiting the definition
We have examined many kinds of healthcare IT platforms that can be used in a variety of ways with different focuses. All of them are valid when compared to the “pure manual coding” alternative.
We aim to produce our own definition of what a “complete platform” should be from a LCDP point of view. From clients’ perspective, the definition is:
- A concrete cloud infrastructure, with all the inherent benefits: redundancy, scalability, high availability, security facilities, etc.
- A Clinical Data Repository (CDR) based on HL7 FHIR, as the emergent de-facto standard for healthcare records storage.
- A security layer for managing authentication and authorization.
- Other core services like billing, logging, interoperability, notifications, etc.
- A definition-based application builder, including the entire application UI.
- A visual-based tool for achieving the same.
- A marketplace for bringing exposure and promoting the integration with other applications using the same platform.
The Efferent Healthcare Platform
The following high-level diagram depicts our concrete healthcare platform implementation:
We have chosen the Microsoft technology stack for the platform, and hence it resides on the Azure cloud infrastructure. The FHIR CDR is a Firely Vonk server, which encapsulates a scalable Azure SQL Server database.
The whole platform security relies on Active Directory, for single sign-on (SSO), identification and authorization services, and also for hosting the application specification documents.
Most of the platforms we have evaluated tend to solve the repetitive tasks at server level. Some common services already mentioned are: Security, billing, logging, interoperability, notifications. These services are accessible through an API (see diagram below).
This is already a big relief for an in-house development project, but still leaves a couple of blocks in the developer backlog: the frontend infrastructure and the business logic. Both require a considerable amount of effort, translated into hours of coding.
The Efferent Healthcare Platform aims to close that gap by providing ready-made user interface components, specialized in presenting FHIR resources in different ways (fill-in forms, worklists, dashboards, calendars, imaging viewer, reports, etc.)
The business logic and the specific UI storyboard can be captured in an “application specification” document, either directly in an XML file or by using a visual tool. This XML becomes the main application artifact (see below), replacing the traditional source code files.
This approach has a direct impact on several aspects of a project, besides the common benefits of other platforms:
- Notorious reduction of the time to market and fast turnaround time for incoming improvements.
- One-day prototyping.
- An entire development team can be reduced to one professional with lower requirements of programming abilities.
- Minimal in-house operational costs, as the whole platform is self administered.
- Removal of any uncertainties, especially those related to technical aspects.