The Matrix Protocol – A look inside the TI-Messenger

The TI Messenger is an important step towards the digitalisation of the German healthcare system, as it can connect heterogeneous organisations and IT systems. In this blog post from my blog series on the topic of telemedicine, I will be taking a more technical approach: I will introduce you to the matrix protocol, the centrepiece of the TI Messenger, and explain why it is the ideal communication platform for the healthcare system. If you are new to the blog series and want to learn the basics of telemedicine and the TI Messenger before reading this article, please feel free to read my other blog posts.

The matrix protocol

The matrix protocol has been developed by the company Element (New Vector Ltd., GB) since 2014 and provides a robust basis for the exchange of sensitive information and cross-sector collaboration. It is therefore used not only in healthcare, but also in other areas that require secure communication platforms (e.g. the BundesMessenger for public administration, the BwMessenger of the German armed forces, or Logineo for schools).

It is an open standard protocol for messaging and real-time communication that was developed specifically for the realisation of decentralised and interoperable communication networks. Its architecture allows different, equal servers to communicate seamlessly with each other without the need for a central server. This feature makes it robust against failures and offers a high degree of flexibility and scalability – not least because it does not have to be administered by a central instance.

The figure above shows a schematic representation of a matrix network in which each organisation (grey) uses its own matrix communication server (also called a home server) (yellow). Via the server-server API [3], the various servers synchronise communication rooms that include participants from different organisations. Clients (dark blue) communicate (via the client-server API [4]) with their home servers to send messages or receive updates. Clients do not have to be just human end users. They can also be any software components (e.g. hospital information systems, image archives, medical devices) that can exchange data via Matrix Rooms in the form of bots (shown here in light blue).

The decentralised architecture of the Matrix protocol allows each instance (home server) in the network to work independently, but still be able to communicate with other home servers, which it can identify and contact independently (via the server-server API). This makes the protocol highly dynamic and resilient, because failures of individual servers only have local effects. The protocol is similar to the Internet, which is also decentralised and dynamically configures its routes itself. Another similarity, which is particularly apparent when looking at the figure above, is the networking of neurons. It is no coincidence that the reference implementations of the matrix home server are also called Synapse and Dendrite.

Technical details and how it works

The central component of the matrix protocol are the aforementioned rooms, in which communication between users takes place. Users can create rooms and invite each other to existing rooms. Users have different rights (power levels), which can be configured from read-only access to full administration rights for each room. All information about rooms is communicated via events in JSON format. Messages exchanged between users are also events. The following diagram provides a graphical overview of the data structure:

All events that are visible in the chat history are referred to as message events. All other events are called state events, since their totality defines the current room state (e.g. the current name, the list of participants, or similar). In addition to the officially specified event types, users can also send their own events into rooms to exchange additional information between software clients. It is also possible to attach message events to metadata that is invisible to human users, which means that it can be transmitted in a structured form in addition to its human-readable form. This allows, for example, medical software to interpret message content, enabling the transmission of findings, diagnoses and medications. One outstanding feature of the Matrix protocol is its ability to transmit messages end-to-end encrypted despite its federated structures. This security and privacy protection is particularly important in the healthcare sector, where sensitive health data is exchanged. This security is ensured by the Olm and Megolm protocols developed for the Signal messenger. Without going into too much cryptographic detail, they allow a new cryptographic key to be used for each message. Should a key be compromised, it can only be used to decrypt one message. All previous and future messages remain secure. This also makes it possible for users who are only invited at a later date to decrypt messages in the room from the time they join if necessary. It is important to note that not all events are transmitted in encrypted form, but only message events. Sensitive data must therefore always be sent in the form of messages.

Integration into TI-Messenger

The matrix specification is used unchanged for the TI Messenger. However, the TI Messenger consists of additional components to further secure it and connect it to other services of the telematics infrastructure. The central element here is the so-called messenger proxy, which maintains a federation list with all officially approved TI Messenger home servers and strictly limits any communication between matrix home servers to these. This prevents non-officially certified and approved messengers from participating in secure communication for the German medical system.

Another special feature of the TI Messenger is the use of the FHIR directory service (VZD-FHIR-Directory). The TI directory service (VZD) is the central address book of the telematics infrastructure (TI) in Germany. It contains basic data such as addresses and certificates of medical service providers and institutions connected to the TI, including doctors' practices, pharmacies and hospitals. The directory is divided into an organisation directory (for institutions) and a personal directory (for doctors with an electronic health professional card).

The central IDP service (Identity Provider) of the telematics infrastructure is currently responsible for the authentication and authorisation of organisations and users with an electronic health professional card. In the future, this service will be replaced by a network of federated identity services that can be contacted either directly or via a central federation master. Users without a health professional card can be added by an organisation administrator (org admin) in alternative ways, either manually or via the institution's own IDP services. It is also possible to set up functional accounts (e.g. for doctors on duty).

Providers of TI messengers provide registration services for setting up administration accounts and registering messenger services (Matrix home server with messenger proxy). In addition, each messenger provider operates a push gateway that is responsible for delivering notifications.

Conclusion

When the third stage of development is reached, the TI-Messenger will be a powerful tool for networking heterogeneous structures in the healthcare sector on a comprehensive and scalable basis. It not only standardises real-time audio and video communication of various telemedicine applications, but also allows the direct exchange of structured data between software systems – without complex network configurations. Its federated structure makes it scalable and fail-safe.

The publication of the specification for TI-Messenger 3.0 was originally planned for the fourth quarter of 2023. Like other services of the telematics infrastructure, TI-Messenger is also experiencing delays, meaning that the specification and an official launch date are still some time off. However, I don't think that this delay should be taken as an opportunity to put off the Matrix topic even longer.

Important decisions are currently being made for the future of digital supply platforms, for example by associations of panel doctors. The use of the TI Messenger or the Matrix protocol offers enormous potential here. The integration of these open and interoperable solutions can promote future-proof and comprehensive networking in the healthcare sector. At the same time, there is an opportunity to actively shape the further development of the messenger as a pioneer and to benefit from a flexible, adaptable platform that creates real added value in the long term – without the risks of a vendor lock-in, as is the case with proprietary solutions.