Wondering why the getCareRecord is a POST i.e. POST /Patient/$gpc.getcarerecord
I know REST operations aren’t part of the core FHIR spec but would have expected it to be of the form
GET /Composition?subject=Patient/{NHSNumber}&encounter.period.start>={date}&encounter.period.end<={date}&type=gpcarerecord etc
POST implies I’m sending information to the system (it is sending some parameters).
Using Patient implies it’s an operation on Patient demographic’s. This may be confusing to those learning FHIR and REST - it’s actually a Composition we are working with.
I’m pretty new to AngularJS/Ionic but found the composition’s difficult to work with. It would be easier if it was broken down into sections rather than having to parse the html to extract out the sections/headings.
I’ve just used the html in the app screen shot below but it shows how the raw data appears. Appointments and Documents (from NRLS) were a lot easier to process.
It’s a POST rather than GET because it is a FHIR operation. An operation will often carry parameters in the body. Operations don’t map neatly onto a CRUD model so there is a conceptual mismatch between FHIR and http verbs; this is why Black Pear use a custom claims model for access control.
( https://github.com/BlackPearSw/jwt-claims-fhir/blob/master/jwt-claims-fhir.md ).
Operations define their own return types, so an operation returning a Composition is OK. You shouldn’t have to be parsing the HTML to identify sections within it. If the HTML does not render correctly in your environment then it is the responsibility of the system providing it to make it safe. This is a significant clinical safety risk; the obvious answer is for the provider to respond with structured data that can be presented by the consumer system (this is is on the GP Connect roadmap).
I agree that there are different options for the scope of the operation. As it is an operation about a single patient, I think it would make more sense as an operation on a Patient instance, e.g.: POST Patient/123456/$gpc.getcarerecord (or a system operation on a Patient compartment ). This could require an extra request, which may be why the identifier has been passed as a parameter.
CORS
Can you get a dump of the requests/http headers/responses from the iPhone version? This usually helps id CORS problems. From memory ng libs use unauthenticated CORS preflight requests.
Not convinced using /Patient makes sense, I would expect to use that for Patient resource operations.
Think it’s confusing, at first glance (with simple version of REST) POST /Patient/123456/$gpc.getcarerecord looks like an attempt to add in a new Patient record, possibly with a careRecord.
re: CORS I’ll try and find the logs. Had similar problem with Ionic but configuring a proxy worked, it just failed on this operation when I moved it to a simulator/iPhone.
Not sure if you’ve got all this working by now but wanted to let you know we’re currently implementing CORS support in the Spine Security Proxy so that pure web and hybrid mobile apps will work more easily. We did consider moving the $gpc.getcarerecord operation onto the instance level but it was felt on balance leaving it at the type level was easier for implementers in this case. We are in the process of updating the specification to mark the Bundle as being of type “document” (and not searchset) so that you’re expectation around the Composition being the first element in the returned Bundle holds. Finally, you’re correct the specification (and the $gpc.getcarerecord operation) has always allowed individual sections to be requested - so stay clear of parsing the HTML to split sections as that does sound correct and potentially risky!
Jorvik/summary.js at master · KevinMayfield/Jorvik · GitHub
). This could require an extra request, which may be why the identifier has been passed as a parameter.