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.
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 ?
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.
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.
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.
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.
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,
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
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?
Outbound messaging would be handled by a FHIR Subscription 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 and have shared a reference implementation for a REST-hook endpoint that you could experiment with.
