Building a FHIR (Care Connect) Server


#21

@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.

thanks


(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:


#24

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!


#27

hi Kevin,

  1. Instead of using TIE for processing, orchestration and calling these Fhir APIs, what about using an API manager https://nordicapis.com/20-api-management-solutions

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 ?

thanks


(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 http://hawt.io/ 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 (https://www.elastic.co/products?camp=branded-uk-ggl-bmm&src=adwords&mdm=cpc&trm=elk%20stack&gclid=EAIaIQobChMIwf2h-9-V3gIVCbTtCh3OwQyMEAAYAiAAEgKav_D_BwE) 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 https://teradata.github.io/covalent/#/

I found this good for ideas https://www.amazon.co.uk/Devops-Handbook-World-Class-Reliability-Organizations/dp/1942788002/ref=sr_1_1?ie=UTF8&qid=1540064289&sr=8-1&keywords=devops+handbook