Vonk FHIR Facade

Vonk FHIR Facade FHIR-enables legacy (non-FHIR) systems, either directly on the database or by accessing (web) services provided by that system. This approach does not require a copy of the data in FHIR format: the data can be accessed directly from the original source. So Vonk FHIR Facade speaks FHIR at the front end and talks directly to your native data at the back end. This is a very powerful and efficient shortcut to expose your systems to FHIR clients.

Scenarios

There are some typical scenarios where you may choose Vonk FHIR Facade over the other flavors (Vonk FHIR Server and Vonk Components):

  • You are building a web or mobile app that needs to access data from several back end systems. Instead of implementing the details of every back end system into the app, you standardize on FHIR communication between the app and the back end systems. A Vonk FHIR Facade for each of the back end systems enables this scenario. As soon as you start developing a second app you will see the benefits of this approach.
  • You are the developer of hospital system registering lots of data, e.g. a PDMS, and your customers ask you for FHIR access to that data.
  • You want to add web services to open up your system. Choosing the FHIR RESTful API saves you inventing and documenting your own API and Vonk FHIR Facade can deal with the FHIR intricacies, allowing you to focus on the familiar domain of your  own system.

Storage and mapping

Vonk FHIR Facade lets you connect Vonk to existing storage. This will often be a database, but if you prefer to access other services, a queuing system or something else, that is also possible. Vonk FHIR Facade breaks down the often complex REST calls to easy to map query parts. Once you have mapped the query side to your database, you can leverage the .Net FHIR API to map the resulting data set to one or more FHIR resources. In many cases any one system will only expose a few different types of resources and can only support some of the search parameters. Implementing the mapping will then take a few days at most.

You implement the mapping using the same storage abstractions that the Vonk FHIR Server uses. This means that you can even leverage advanced capabilities like history, including related resources ( ‘_include’ ) or even scoping access to data based on OAuth2 token claims. Just by mapping the correct parameters to a database that is already familiar to you. Metadata operations like the CapabilityStament or validation do not even require any mapping.

The mapping should be built in Microsoft .Net. We advise you to use the new .Net Core framework.

Security

Since the data that Vonk FHIR Facade accesses stays in its original system, that data is as safe as it always was. On top of that, Vonk FHIR Facade can provide the same security measures as the integrated Vonk FHIR Server. Note that for scoping access the relevant search parameter(s) must be supported by the mapping.

Deployment

If the mapping is developed in .Net Core – as Vonk itself is – you get all the same deployment options as with the Vonk FHIR Server:

  • Dockerized
  • Stand alone cross-platform binaries
  • Azure App Service
  • Windows Service
  • IIS Web application

If you prefer to use the classic .Net Framework, Vonk FHIR Facade will require Windows or Azure App Service and the .Net Framework to run on.