Hi,
May be I should give full picture here of what am trying to do, We have PAS, we need to build a bidirectional communication link with one of our third party downstream system using FHIR (for demonstration purpose - Assumption is the Third party downstream systems has FHIR server or FHIR capable).
use case 1: Patient created in PAS should be communicated to Third party system using FHIR
use case 2: Patient seen in Third party system - update the date of birth in Third party system - this should be communicated to PAS using FHIR
use case 3: Updated date of birth seen in PAS.
to achieve these FHIR communication what are the requirements from PAS side. [this is already working with HL7v2.4].
please share your thoughts on this.
thanks
Tharma
You are looking at creating equivalents of In HL7v2 (ITK) A28 (create Patient) and A31 (update Patient). In FHIR the closest equivalent would be FHIR Messaging using Bundles - https://www.hl7.org/fhir/messaging.html
A basic bundle would include:
MessageHeader (MSH/EVN)
Patient (PID)
Practitioner + Organization (would be referred to by Patient PD1)
Person (NK1)
EpisodeOfCare (+ Encounter) PV1
The format of these FHIR resources should match the profiles here: https://fhir.hl7.org.uk/StructureDefinition (where applicable - EpisodeOfCare and Person haven’t been profiled yet)
Once you’ve created the Bundle, if using REST, you would (http) POST these to the Bundle FHIR Endpoint e.g. POST http://yourdomain.com/FHIREndpoint/Bundle
Bundle only supports POST which is CREATE in REST, so you would also need to set the request properties of the Bundle accordingly (so the Patient entry.request for A28 would be POST and PUT for A31).
Your usecase 3 could be treated differently as you are only updating one resource (Patient). So you could just update that resource (PUT /Patient). The same could be said for the other use cases, do you need to send the other resources and could you just use PUT/POST Patient??
This way of working is referred to as http on the fhir site https://www.hl7.org/fhir/http.html
An documentation on NHS http api can be found here: https://nhsconnect.github.io/CareConnectAPI/api_entity_patient.html
The link shows equivalent of HL7v2 PDQ and v3 PDQv3
This api is demonstrated here: http://yellow.testlab.nhs.uk/careconnect-ri/ with source code available here: https://github.com/nhsconnect/careconnect-reference-implementation (it’s also available on docker, see here for instructions: https://nhsconnect.github.io/CareConnectAPI/build_ri_install.html )
A few notes on the reference implementation:
It has many components, follows DevOp principles and so services can be used by themselves.
In the diagram below the part referred to as Apache Tomcat is a HAPI RESTful server which uses Apache Hibernate to communicate to a SQL server (Hibernate supports SQL Server, MySQL, Cache and others). You can use this as a starter for building your own FHIR server but you would need to do your own mappings in Hibernate to your database structure.
The two FHIR Gateways are also HAPI RESTful servers which use Apache Camel to communicate to the main FHIR server. Apache Camel is integration/middleware tool used in a similar manner to trust integration engines (TIE) e.g. mirth. Both of these hide features of the main server (the main server supports POST/PUT operations but the public server just supports GET) and for the secure endpoint it also provides SMART on FHIR.
The Apache Camel layer (FHIR gateway) could be used to support HL7v2 messages (via the v2 HAPI) and also FHIR messaging. What I mean is we could take the PID from the A28/A31 or Patient from the FHIR Bundle and turn it into a POST/PUT Patient. A mobile/web app developer would probably just want to use POST/PUT Patient (and not use messaging).
Lastly the OAuth2 server is from here GitHub - mitreid-connect/OpenID-Connect-Java-Spring-Server: An OpenID Connect reference implementation in Java on the Spring platform. with smart on fhir extensions from HSPC Bitbucket
Thank you Kevin for these details, these would help me to start with FHIR.
I’m building a RESTful API for our application that will enable hospitals to create (and update) patients demographics. Our application needs to remember how to link the patient (created in our application) to the same patient held in the hospital PAS system. Once the patient is registered with our application hospital staff can log-in, create and manage specific episodes of care.
It seems as though there are several different FHIR Resources that could convey that information. I’m trying to understand which is semantically most correct.
I’d modelled that as a POST/PUT interaction (for create and update) that accepts a FHIR Bundle containing a Provenance resource that references an Organization (hospital) and Patient. Having read the above it looks as though the EpisodeOfCare might be semantically a better fit. Is that the case?
Also, if we use EpisodeOfCare to model an ongoing relationship between a hospital and patient, how would one model specific episodes that happen during that relationship? Perhaps that could be modelled as further linked EpisodeOfCare instances with different types, or perhaps a series of Procedures linked to an ongoing active EpisodeOfCare.
I’m new to FHIR - guidance is warmly appreciated 
Do you have a v2 feed from the the PAS system? If so do you know the MRN
Hi Ben
I would suggest splitting your issues carefully in two:
1 tracking “provenance”/linkage/data source issues
2 tracking episodes of care
These are almost completely separate I would say.
For 1 Provenance is a good one yes, probably the most appropriate and thorough. You may consider a “contained” Provenance resource in fact, in the patient, and you may then avoid a bundle (though there is still the organization to consider).
However you may also have enough by just recording the identifier of the patient (the PAS number), scoped by an identifier.system that corresponds to the PAS (e.g use a made up system URL e.g. http://sometrust.nhs.org/PAS). This says “this patient has an identifier allocated by this specific PAS”.
Now, that doesn’t technically mean that is where you got the patient record from (maybe it was sent by a third party), but it’s probably good enough for your needs. It is a simple identifier that says (more or less), Patient A came from PAS B.
As I say, not as good as Provenance, but a whole lot simpler.
If you want to enter and record episodes of care, then yes you may well want to use EpisodeOfCare. But that is a different issue, which we can discuss, from “provenance”/linkage issues.
Thank you, that’s very helpful.
In this instance we don’t have a V2 feed to convert (if I’ve understood the question correctly)
I’m really interested in the idea of scoping the PAS id using a URL. For our needs that would probably be enough, as long as we have a token to help us resolve the origin we can make the association 
Rik prompted me on my reply. I was going to wait and see how you linked to the PAS but using the MRN (Medical Record Number) via a uri is probably best.
I would see an hierarchy of Episodes, maybe top level being linked to specialty and then sub episodes linked to practitioner. How you do this depends on your model.
Technically it is actually a URI, I should have said that, not URL. Ideally it is agreed with whoever maintains the PAS, because others may want to use it too. And it can be used, via some resolution process, yes, to link the two - conceptually.
Thinking it through a little more, in our context I think Provenance may remain the best option because of the Signature.
Some trusts have centralised PAS systems and only a subset of hospitals may choose to adopt our software. So one system may represent several organisations. A scoped Identifier would solve the linkage issue, but our API would have to trust what was being sent.
The issue to mitigate against is the possibility that our API can be instructed to create a connection between a patient and a hospital they have no relationship with (within that trust). That could have serious security consequences.
I have considered if this could be solved at the API level, however I would expect an OAuth protected API would be administered at the system level, and not at the hospital level (i.e. there would not be a separate client id and secrets per hospital)
Whilst it might be harder to implement, signing the Provenance using a hospital scoped key would allow us to verify the origin. Then we could make assertions about which connections can be established.
I hope that make sense. Perhaps there are other experiences of solving this sort of issue?
Provenance is the way to hold full information of where something came from, and yes you can sign it.
There is also the concept of managingOrganization.
Defined as
Need to know who recognizes this patient record, manages and updates it.
Whether that works depends on which system you think of as the master. If there was a “handover”, then you are now the managingOrganizing. If you are a “front end” for the PAS then they are still the master and that might be what you need.
But again, it could be spoofed in theory, unless you strip out any incoming managingOrganizations. But it’s more to go wrong and can’t be signed easily.