4S Microservices is a collection of Microservices and an accompanying infrastructure that are created to support telehealth and welfare technological scenarios. The project is currently at a mockup/prototype stage and the initial version was created as a proof of concept project over a three month period from November 2016 to January 2017. This part of the project was funded by Region Midtjylland and by the project "Nem adgang til datadeling på tværs af sundhed og velfærd" (result contract with the Danish Agency for Science and Higher Education). This project was a continuation of the ideas formulated under the heading OpenTele3. A report on this project can be found here (a translation of the original report in Danish).
We are in the process of adding more information and documentation about 4S Microservices and the ongoing maturing of these that has been going on since the above mentioned project ended.
Overall the 4S Microservices architecture sits at the intersection between technologies in use in the citizens personal domain and technologies in use by traditional health and care organisations. The broader goal for architecture is to support services that are targeted at collecting, processing and sharing health, fitness and wellness related data between private and public sources of data.
In further detail the proposed overall architecture of the 4S Microservices infrastructure / OpenTele3 can be illustrated like this: In the proposed software architecture citizens and healthcare professionals apps can, through an API Gateway, communicate with dedicated backend-for-frontend (BFF) APIs and input services. BFFs are modeled over the BFF pattern as for instance outlined by Sam Newman. Input services can be seen as part of the BFF strategy, but are special services dedicated to receiving input from devices (for instance measurements and questionnaire responses). The BFFs and the input services encapsulate the central microservice infrastructure toward outside clients. Microservices on the inside process, store and expose received data. Furthermore, microservices will convert data to CDA format and store it in XDS-based archives.In relation to these archives the proposal is that the infrastructure can function as a cache of master data stored in these central archives.
The infrastructure exposes REST-based HL7 FHIR APIs for client apps. FHIR is also used for internal, REST-based, synchronous communication amongst microservices. However, mostly microservices will communicate asynchronously via the asynchronous messaging system. Via publish-subscribe based communication the messaging system facilitates loosely coupled communication between microservices.
An overview of the microservices implemented during the OpenTele3 Proof of Concept project is illustrated below:
Overview of docker containers and monitoring in the PoC:
Illustration of the use of Kafka in this project:
Example of a single service: FHIR service with database and Kafka messaging:
The various microservices implemented are in general loosely coupled, but there are some assumptions that the microservices must adhere to, for example the flow of data in the ecosystem.
TODO More descriptions of dependencies here…
Source code can be found in the 4S Microservices Bitbucket project