Interoperability by-design in application design

I note with great amazement that, with few exceptions, we continue to design healthcare applications as “islands in their own right”, but then worry, once the development is over, how to integrate them with other systems.

The problem concerns not only supply but also demand. If today it is quite usual to find in the non-functional requirements of the tender specifications the request for “privacy by default” and “privacy by design” systems, thanks to the indications of GDPR, none of this happens for interoperability.

The designers’ attention is focused on the choice of development technologies, functions to be implemented, data and database structure. Interoperability is usually a requirement that is fulfilled by a middleware or an appropriate infrastructure but does not affect the system architecture.

This approach could be fine as long as you use the HL7 version 2 and CDA standards which are based on the logic of events and messages / documents. Each system, at the occurrence of certain events, predetermined, exchanges through messages or documents information with the systems that are potentially affected / involved. The integration therefore requires the definition of specific cases of use, the identification of events and the development of messaging.

HL7 FHIR, the reference standard for the future of healthcare, is based on a completely different logic. Each application component “provides” one or more resources. A resource is, in FHIR, an entity able to store and exchange structured information through a URL. Each application can therefore, to perform a function or execute a process, access the resources that manage the necessary information; or, vice versa, make the information it manages available to other systems.

When designing an application, it is therefore necessary to think in terms of resources according to the HL7 FHIR scheme: exposed resources, which other systems can call; resources that the application uses to perform the functions it manages.

Between application components or applications of the same manufacturer, even more so if based on service-based logic, interoperability must take place through FHIR resources. In this way you get the maximum interchangeability between applications and it becomes really easy to “drop” an application in a heterogeneous system.

Healthcare is a complex world: in a hospital there can be up to 60 different applications; in an ASL over 100. Interoperability and interchangeability of applications are mandatory. It is not conceivable to continue developing software without addressing these aspects natively and having to invest time, money and resources to build clinical and management systems.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s