Helping Dutch Healthcare Speak the Same Language with XMPP

Blogs Ignite Realtime Blogs
, , , ,
1

Helping Dutch Healthcare Speak the Same Language with XMPP

The XMPP Standards Foundation (XSF) has put out a call to action: it’s time for the community to help make secure, interoperable chat a reality - especially in healthcare. Here at Ignite Realtime, we’re excited to support this effort. Our projects, such as Openfire and Smack, provide powerful building blocks to explore what’s possible for Dutch healthcare communication.

Building Blocks for Dutch Healthcare Messaging

Many of the features mentioned in the XSF’s call to action (such as attachments, group chat, and read receipts) are already available in our projects, providing a strong foundation for exploring messaging workflows. Openfire offers a scalable XMPP server with a flexible plugin system, while Smack, a modular Java library for building clients on Android, desktop, or other platforms, makes it possible to experiment with custom client-side solutions. Together, these tools allow developers and organizations to prototype, test, and explore how messaging could work in Dutch healthcare contexts.

How Our Community Can Contribute

Even though the Dutch healthcare chat standard is still being finalized, there are ways to explore and prepare for it using projects such as Openfire and Smack:

  1. Develop Proof-of-Concepts (PoCs): It’s possible to build early prototypes of messaging solutions to explore how the new standard might work in practice. Many core specifications are already implemented in our products, so prototypes can focus on workflow and interoperability rather than reinventing basic features.
  2. Experiment with Custom Functionality: The modular architectures of projects like Openfire and Smack make it possible to create custom plugins, extensions, or client features to test new communication ideas. Resources and examples from the project repositories can help get started.
  3. Explore Security and Privacy Configurations: By building prototypes, setting up test environments, or simulating messaging workflows, the community can experiment with authentication, encryption, and access control setups to see how patient data could be protected under the new standard.

Let’s Build a Connected Dutch Healthcare Community

Projects such as Openfire and Smack give us the building blocks to explore messaging that’s secure, reliable, and ready for the future. By experimenting, prototyping, and sharing insights, the community can help ensure the new Dutch healthcare chat standard meets real-world needs from day one.

And since the Ignite Realtime Foundation is a Dutch stichting with local contributors and partners, we like to think of this as more than just coding - let’s discuss the possibilities over a stroopwafel sometime!

For more information and to join the conversation, visit Ignite Realtime and introduce yourself in our community at disource.igniterealtime.org. Together, we can help Dutch healthcare teams communicate better and build a strong, collaborative XMPP ecosystem in the Netherlands.

For other release announcements and news follow us on Mastodon or X

2 Likes
2

This is just my opinion but I think the thing really holding XMPP back has been a lack of decent clients for both desktop and mobile. I guess you could make the argument that there are a few decent desktop clients out there (Spark is archaic and in need of a complete overhaul but it does work), but the lack of any functional client for iOS is a killer. Had there been a decent mobile client for iOS (even Android is not great but it is much better) during the pandemic, I think we would have seen major adoption. Nobody seems to be able to make an XMPP client for iOS that works well and the excuse is always that Apple won’t allow it to run in the background and keep the connection alive and all that. Push notifications was supposed to be the cure but even that doesn’t work well or reliably. Yet WhatsApp, Telegram, Signal, etc. all seem to be able to figure it out in their clients.

Anyway, just my 2 cents worth. It’s a shame to me because XMPP is awesome, and Openfire (and even other) servers are amazing, but when you go to try and find clients, things get sort of bleak.

3

Thanks for sharing your thoughts, Bill! You raise a point that’s been discussed in the wider XMPP community for some time. Reliable, polished clients are indeed an important part of user adoption.

It’s worth clarifying, especially for readers less familiar with XMPP, that the iOS challenges you mention are not unique to XMPP - they affect all messaging apps because of how Apple manages background network connections and push notifications. These are platform constraints that any real-time communication app must work within. The XMPP protocol already provides standardised mechanisms to handle them effectively, such as XEP-0357: Push Notifications, which is supported by modern servers like Openfire.

The current generation of clients (such as Monal and Siskin IM on iOS, Snikket on iOS, Android, and web, Conversations on Android, and Movim for web and desktop) are implementing such features actively and improving quickly. In practice, healthcare deployments will likely need specialised clients anyway, to meet strict requirements for authentication, auditing, and integration with clinical systems. That’s exactly where XMPP’s open, extensible architecture, and open-source platforms like Openfire and Smack, really shine: they allow purpose-built solutions to be developed without reinventing secure, interoperable messaging.

The goal of the original post was to highlight that XMPP and the Ignite Realtime projects provide a mature, standards-based foundation for anyone who wants to start experimenting with interoperable and secure messaging in healthcare today.

Feedback like yours helps us keep improving the ecosystem Thanks again for contributing to the discussion!

4

You’re not wrong.

But existing XMPP-based clinical messaging solutions in the UK do have iOS clients, and they work really well. I believe Alertive is XMPP-based, and Pando certainly is. In the case of Pando, the iOS client routinely scores truly astonishing NPS scores as well.

My personal view on this is that - based on how it’s worked in the UK - individual health organisations will be purchasing “complete breakfast” solutions from suppliers. These will include client support, servers, ancillary services that probably won’t operate over XMPP (like EHR export for conversations) and so on.

You’ll likely get a degraded service when federating heterogeneously because certain services won’t be replicated on different suppliers - Pando has an “Ask Advice”, whereas Alertive has a “Role-based messaging” feature. In my ideal world, suppliers will engage within the XSF to produce common specs and “heal” these problems.

The biggest reasoning for not having generic clients in use is the authentication piece - clients will absolutely have to use some kind of authentication which ties back into organisation or even national health identities - Pando uses NHS mail for this, I don’t know what Alertive does here but you can be assured that authenticating to a specific actual clinician’s verified identity is important to them too.

So yes, existing Open Source clients are a bit rubbish - and even the ones we hold up as good examples aren’t as slick as WhatsApp, Slack, etc. But I wouldn’t expect Dutch healthcare to be using those anyway, based on my experience with clinical messaging in the UK.