fhir: support the correct verbs

[josephjclark]

This is the FHIR API spec:

I think we need to extend the FHIR adaptor with the following functions, which should be familiar to FHIR users:

read(resourceType, id, query) // get a resource by id

search(resourceType, query, options) // list resources with a filter

update(resourceType, resource) // upsert a resource (but resourceType is in the data, so maybe this is just update(resource)

We already have create(resourceType, resource) (which tbh should just be create(resource))

This is in addition to the HTTP verbs get, post, request. I'd be tempted to namespace all these under http., but the verbs are distinct enough that I don't think it's neccessary

When this has been done, getClaims needs to be removed. read and search make it superfluous.

[aleksa-krolls]

Hey @josephjclark I'm onboard with adding these 3 functions (read, update, & search) per the FHIR documentation, and removing getClaims().

@mtuchi I'm going to add this to this week's sprint and drop some of the other lower priority adaptor issues. Does that sound okay?

[mtuchi]

@aleksa-krolls sounds good 👍🏽

[mtuchi]

Just minor discovery on read(). It looks like we will need to support an additional params query. This will look something like this read(resourceType, id, query). This is because the read function will need to support query params for filtering.

[mtuchi]

Another finding, looks like search(resourceType, query) needs more design thinking. There are couple of limitation that i am seeing in their documentation. Read more here

• FHIR search operations are in both HTTP POST and GET. Choosing which method to use depends on how FHIR server is configured. Learn more here
• There are more than one FHRI search operation. Apart from Resource Type Search there is Server Root, Compartment Search, and Compartment and Resource Type Search`. The url changes based on which type operation and the HTTP method used

[josephjclark]

Great research @mtuchi , thank you.

Let's put this on ice and just get the basic FHIR adaptor done.

For the record:

• We can add a query object to read, no problem
• You're right about get and post for search. I thought we could just implement it as POST but we'll have to support both and carry a flag on the options object. Or the configuration schema.
• For the different search type, we'll default to server root search. But we'll add an options object to cover the different types (expose resourceType, compartmentId and compartmentType options)
• If the http functions have callbacks, these should have callbacks too. Hopefully by the time we do this work, we'll be in a position to remove all the callbacks. Let's wait and see.

[josephjclark]

When we come back to this work, I think we need to refactor createTransactionBundle into batch and transaction (the only difference, I think, is the type key on the payload - so batch and transaction need to be wrappers around some common util)