# Building a FHIR (Care Connect) Server **Category:** [FHIR](https://openhealthhub.org/c/fhir/31) **Created:** 2018-04-13 20:29 UTC **Views:** 8758 **Replies:** 37 **URL:** https://openhealthhub.org/t/building-a-fhir-care-connect-server/1527 --- ## Post #1 by @mayfield.g.kev This is a write up from the NHS Digital Connectathon last month. https://nhsconnect.github.io/CareConnectAPI/build_patient_server.html It's aimed at people providing FHIR Servers to existing systems. Those looking for an example FHIR enabled Care Connect server (such as those developing a mobile or web application) take a look at the Care Connect demo site (http://yellow.testlab.nhs.uk/careconnect-ri/). This server is has both un-secure (http) and secure (https) endpoints. https is using OAuth2 (plus SMART on FHIR) - see site for more details. The authorisation server is open source Open Mitre Authorisation server plus extensions from the US 'open source' health service provider consortium HSPC. --- ## Post #2 by @jkmcs Just brilliant Kev, bravo such a great help. Many thanks --- ## Post #3 by @Tharma Hi Kevin, What would be the approach to build a FHIR server (expose Patient Resource as REST FHIR API) with CareConnect Profile to the existing PAS, the PAS has its own database and java APIs to Read / Write patient demographics. As a first step, implemented the FHIR REST API using HAPI libraries with the mapping between HAPI-Patient Resource and PAS-Patient. The next step to convert this to CareConnect API, am not sure where to start with ? please share your thoughts ? thank you. --- ## Post #4 by @mayfield.g.kev I’ve tried several approaches so far, using a TIE and also Apache Camel but settled on using the restful server from hapi fhir. It’s used in the link above the fhir starter link above with the core code here https://github.com/nhsconnect/careconnect-examples/tree/master/ccri-nosql-fhirStarter As you already have java API’s you should be able to replace the (mongo) data access layer with your own. We’ve been doing this with most of our later projects, we start with the fhir starter and then implement a data layer, either: hibernate (for sql access) Apache camel (for calling other API’s and then transform using hapi classes) Hapi client for calling other fhir servers If I still had access to a TIE, I’d still using that for processing or orchestration, calling these hapi server endpoints. Would also facade the TIE with a HAPI server as that makes it easier to configure and add in security (tokens, oauth2, etc). Doing the configuration in java (and learning java) is easier in the long term than trying to do the same in JavaScript or Caché. The other bonus of taking the data access and transform out of the TIE is you can reuse the FHIR servers for other projects - the main one I’ve seen in practice is the rest endpoints for clinical portals. --- ## Post #5 by @mayfield.g.kev ![image|365x500](upload://x0SdbJWg0z3fhMMCCwItUZiQVuS.jpeg) This is from the next care connect reference implementation, it’s still based on a implemention in a West Yorkshire NHS trust (well just) It’s using five fhir servers now, the two fhir servers connected to databases do transform and data access only. The two public servers (on the left hand side) do orchestration and security. The other one creates FHIR documents. I’ve gone off on a bit of a tangent but wanted to show using fhir micro services (embers??). In TIEs I’d worked with, productions we’re getting quite large and maintence had a lot of risk. Splitting out components has really reduced that risk but the down side is having more components To monitor. --- ## Post #6 by @Tharma Thank you Kevin, appreciate your quick response. get back to you once I go through the information you provided. --- ## Post #7 by @PhilTauwhare HI Kevin, We have Open RiO hosted by Servelec and no access to the live database. Will they be providing the necessary API's? Thanks Phil --- ## Post #8 by @mayfield.g.kev From the replies here it appears to be a yes https://www.digitalhealth.net/2018/08/servelec-and-microtest-assert-interoperability-ambitions/ --- ## Post #9 by @Tharma Hi Kevin, Thank you, just have another question after gone through your example, how can I make sure that the FHIR server (restful) I implemented from HAPI Fhir uses the care connect profile or compliance with care connect profile. thanks --- ## Post #10 by @mayfield.g.kev I believe the NHS Digital Reference server (https://fhir.nhs.uk/) will have testing capabilities shortly. --- ## Post #11 by @Tharma hi Kevin, The Apache Camel between FHIR server and the APIs are there any specific reason ? thank you. --- ## Post #12 by @mayfield.g.kev we’re using it as a switchboard, so requests to the front fhir server get redirected to either the ‘epr’, ‘Edms’ fhir server or business logic fhir servers. We also use this camel/fhir server to reduce our capability statement (the internal servers support get, post and put plus extra resources). Also we include api security on one of the external servers. It is not necessary. --- ## Post #13 by @Tharma Hi Kevin, how the FHIR server handles sudden peak of requests ? should this be always synchronous ? or can the Apache Camel act as queue and provide asynchronous behaviour to the FHIR server ? Thank you, --- ## Post #14 by @mayfield.g.kev Good question. We run all queries synchronously but internally the post runs using a queue (it takes time to post a lot of resources). Idealy we should make the post async but it increases complexity --- ## Post #15 by @Tharma Hi Kevin, How is the outbound flow working here, ie when a resource needs to be sent outside to another REST Server(s). how can this be handled ? thank you --- ## Post #16 by @mayfield.g.kev By outbound do you mean a system where a Patient is created and that triggers an outbound Patient event (similar to ADT^A28 or ADT^A31)? --- ## Post #17 by @Tharma Hi Kevin, not exactly, in the above reference implementation, a 3rd party system (FHIR Client) calls FHIR Server to post/put with a resource. In the same way how this reference implementation can act as a client to call the post/put on the 3rd party FHIR Server(s) with a resource? thank you --- ## Post #18 by @dunmail Outbound messaging would be handled by a [FHIR Subscription](http://hl7.org/fhir/subscription.html) capability. I haven't seen this mentioned as a core part of the NHS architecture but I think it may be being piloted within the child health domain. We're using Subscription as part of the [Somerset CCG SIDeR programme](https://github.com/Somerset-SIDeR-Programme/SIDeR-interop-patterns/wiki/subscription) and have shared a [reference implementation](https://github.com/BlackPearSw/fhir-stu3-subscription-resthook) for a REST-hook endpoint that you could experiment with. --- ## Post #19 by @mayfield.g.kev Is that purely restful/resource based? CCRI doesn't include a trigger/event service but it wouldn't be difficult to include one, that could be a feed to a subscription service. --- ## Post #20 by @dunmail Yes - on C_UD the resource can be sent to the subscriber if it matches the subscription criteria --- ## Post #21 by @Tharma @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 --- ## Post #22 by @mayfield.g.kev I was just thinking restul/resource based, it is green field rather than messaging brown field. Would allow new ways of doing things. --- ## Post #23 by @dunmail **Does** allow new ways of doing things :wink: --- ## Post #24 by @Tharma 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? --- ## Post #25 by @riksmithies 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. --- ## Post #26 by @dunmail 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! --- ## Post #27 by @Tharma 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](http://) 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 --- ## Post #28 by @mayfield.g.kev 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 --- ## Post #29 by @jeff.greco 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 hawt.io, 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! --- ## Post #30 by @mayfield.g.kev 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. --- ## Post #31 by @mayfield.g.kev '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. ![22|633x500](upload://AoIiz0xBNPVntZnEjWuXtj21LEs.png) 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. hawt.io 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 hawt.io). I would like to include access to log files via hawt.io The current list of git's used within the ccri is: https://github.com/nhsconnect/careconnect-reference-implementation for ccri-fhir and ccri-smartonfhir, FHIR Explorer and HIE Portal (*) https://github.com/nhsconnect/careconnect-document for ccri-document and ccri-messaging https://github.com/nhsconnect/careconnect-oauth2 for ccri-auth (OAuth2) https://github.com/nhsconnect/careconnect-testing for test scripts (*) These angular 7 apps will be separated out to other git repos, they are used here https://data.developer.nhs.uk/ccri This are part of what I suppose is best called LHCR Reference Implementation --- ## Post #32 by @jeff.greco 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! --- ## Post #33 by @mayfield.g.kev 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. --- ## Post #34 by @mayfield.g.kev New instructions for building a local dockerised version of the care connect reference implementation have been published. https://nhsconnect.github.io/CareConnectAPI/build_ri_install.html 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 https://data.developer.nhs.uk/document-viewer) --- ## Post #35 by @Tharma hi, Is this latest build has the implementation of digital signature like JSON digital signature ? thanks --- ## Post #36 by @mayfield.g.kev [quote="Tharma, post:35, topic:1527"] JSON digital signature [/quote] Not done any work on JWS, if that's what you mean? --- ## Post #37 by @Tharma Hi Kevin, I was referring this http://hl7.org/fhir/2018Sep/signatures.html thanks --- ## Post #38 by @mayfield.g.kev [quote="mayfield.g.kev, post:31, topic:1527"] ‘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. [/quote] No, that's not been discussed. --- **Canonical:** https://openhealthhub.org/t/building-a-fhir-care-connect-server/1527 **Original content:** https://openhealthhub.org/t/building-a-fhir-care-connect-server/1527