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

(Jeff Greco) #29

Hi Everyone,
I am new to FHIR and coming up to speed as fast as I can and am very interested in the CCRI and how it can get us started. We have previously implemented the HAPI FHIR JPA server and hacked a workable demo together to our legacy data. We would like to mature our solution and like the integration of other components into CCRI like OAuth and monitoring.
I have the docker demo up and have started pouring through the code in GIT and have a couple of questions, hoping that this is the correct forum. (There doesn’t seem to be a way to register on the CareConnect API channel and my email to apilabs went unanswered)

  • Is there a document mapping the components in the high level architecture to the docker install to the ‘active’ GIT projects? Specifically, all the projects in GIT are not in use. It would be nice to know how things have been organized and which module contributes to which output (jar/war/etc)
  • There are many FHIR servers implemented, what is the role of each? There is mention in this thread that there are internal/external and security etc. Is there a simple use case for each?
  • Is it possible to know the roadmap or maturity of what has been implemented? I ask because in reading this thread, you mention, ELK and Splunk in varying levels of implementation. I am only asking for an idea of where each is at so not to focus on anything ‘on its way out’.
  • What are the external dependencies and their projects that are not contained with the CCRI GIT repo. For instance, the OAUTH2 Git project is separate, are their others?

I apologize again if this is not the correct forum. If this is documented somewhere and I am just poor at searching for it, please point me in the right direction!

Thank you!

(Kev Mayfield) #30

We’re currently refactoring the components so it’s more plug and play. I’m hoping this is done within two weeks.

It’s probably easier for me to post the links to articles explaining each bit as they are produced.

(Kev Mayfield) #31

‘fag packet’ diagram of the refactor. This is rearranging the code to reduce the number of modules.
ccri-fhir and ccri-smartonfhir will actually be one module with OAuth2 security configurable.

ccri-messaging, ccri-fhir and ccri-document will be separate FHIR servers.

ELK and splunk - the intention here is to eventually provide a FHIR AuditEvent service. At present we are sending the logs from the FHIR servers to ELK or splunk. is a bit of an experiment at present, we’re after a way of monitoring each FHIR Server. So what we have at the moment is each FHIR server exposes a jolokia API (via I would like to include access to log files via

The current list of git’s used within the ccri is: for ccri-fhir and ccri-smartonfhir, FHIR Explorer and HIE Portal (*) for ccri-document and ccri-messaging for ccri-auth (OAuth2) for test scripts

(*) These angular 7 apps will be separated out to other git repos, they are used here
This are part of what I suppose is best called LHCR Reference Implementation

(Jeff Greco) #32

Thank you very much for the quick reply. Alot to digest here.
I understand better the makeup of the projects and your direction in splitting/merging.
This makes it a bit easier for me to start at the data layer (we have a terrible legacy Oracle database) and some of the simple stuff, and possibly wait for the re-org on your end. The key components I am interested in for our deliverable in March is the document piece as well as SmartOnFhir with OAUTH2.
We are still in the Proof of Concept phase so productionalizing with audit is not a high priority, but will down the road.
Thank you again!

(Kev Mayfield) #33

Anyone using the source code or public images for the Reference Implementation. Please note we are making many changes over the next few days. (It’s being simplified and split into other git hub repositories)

Will update once complete.

(Kev Mayfield) #34

New instructions for building a local dockerised version of the care connect reference implementation have been published.

Some of the access url’s have changed which are detailed in the document.

In addition this includes the document-viewer which provides a method of rendering ‘Transfer of Care’ FHIR Documents locally. (the docker version doesn’t have security like the public version



Is this latest build has the implementation of digital signature like JSON digital signature ?


(Kev Mayfield) #36

Not done any work on JWS, if that’s what you mean?


Hi Kevin,

I was referring this Signatures - FHIR v3.5.0


(Kev Mayfield) #38

No, that’s not been discussed.