Open josephjclark opened 1 month ago
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?
@aleksa-krolls sounds good 👍🏽
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.
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
POST
and GET
. Choosing which method to use depends on how FHIR server is configured. Learn more here 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 usedGreat research @mtuchi , thank you.
Let's put this on ice and just get the basic FHIR adaptor done.
For the record:
query
object to read
, no problemresourceType
, compartmentId
and compartmentType
options)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)
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:
We already have
create(resourceType, resource)
(which tbh should just becreate(resource)
)This is in addition to the HTTP verbs
get
,post
,request
. I'd be tempted to namespace all these underhttp.
, but the verbs are distinct enough that I don't think it's neccessaryWhen this has been done, getClaims needs to be removed.
read
andsearch
make it superfluous.