Building a FHIR (Care Connect) Server


@Kevin, yes hypothetically my initial thought was pure restful/resource based. any other options please share your thoughts here ?

I remember we discussed in the separate thread about message bundle similar to ADT/HL7 2.x feed.


(Kev Mayfield) #22

I was just thinking restul/resource based, it is green field rather than messaging brown field. Would allow new ways of doing things.

(dunmail) #23

Does allow new ways of doing things :wink:


regarding the error handling, when a post / put method is failed due to internal reason, store it locally and try later ? is this approach recommended in fhir?

(Rik Smithies) #25

Hi, FHIR doesn’t attempt to give guidance here because this is a very general implementation issue, that no more applies to FHIR than any other REST interface, or indeed anywhere that a resource may be temporarily unavailable. Guidance would be so general as to be a bit pointless.

(dunmail) #26

As Rik notes - FHIR doesn’t provide any guidance as this will be implementation specific.

If using a Subscription the sender could set $.status: error and populate $.error within their local Subscription resource. This could be used by the sender to trigger a fault resolution and resend process.

Architecturally, queues and retry policy can be used to provide resilience. Need to be careful that the endpoint can handle messages arriving in a different order to which they were sent!


hi Kevin,

  1. Instead of using TIE for processing, orchestration and calling these Fhir APIs, what about using an API manager

2 I agree, API manager cannot be used for orchestration but do we need orchestrate the FHIR API ? because consumer of these APIs (say a smart App) should orchestrate these APIs ?

please share your thoughts ?


(Kev Mayfield) #28

It’s a bit of a new area for me with REST API’s, on HL7v2/TIE I’d inherited dashboards from @adamlees, it was really useful showing what the status of systems were and we could be proactive about issues. I did extend it to query tomcat servers running REST API’s using and jolokia but that was pretty basic we just did a ‘ping’ to check the server was up or not.
I’d definitely do this again, the number of API’s and servers we had to support was causing a lot of headaches (in a space of about 6-8 months we went from near zero REST API’s to around 30 on around 10 different servers)

For the CCRI we’d been using ELK stack ( and following the recent move to NHS infrastructure moved it over to splunk.
We’ve also got jolokia activated for querying the API’s/JVM’s directly but we’ve not got an API Management.
It is something I’d want to have on live NHS service and I don’t really want develop a management layer so I’ll have a look at those tools. It’s been on my mind for a while and was one of the reasons we started using this angular add on

I found this good for ideas