Are you intending to add a POST /Task endpoint?
For a number of reasons but mostly to have a clean distinction between interactions to populate GOMS repository and interactions around workflow.
I think we need to have a clear distinction between when we are sending in an event or request(/command), as our system probably supports event notifications which require no action (by GOMS). (Question: Do you want copies of orders - this is IHE-LTW LAB-2 where the order is raised on the GLH system and we notify other systems of the order. It doesn’t need actioning).
I’ve checked https://digital.nhs.uk/developer/api-catalogue/genomic-order-management-service-fhir#post-/FHIR/R4 and this doesn’t mention POST /Task.
Hi Kevin,
Yes, we are intending to support POST /Task, though for different use cases to the one you suggest. We envision the POST /Task endpoint to be used for failure recovery purposes, e.g. where a sample preparation has failed and a new Task needs to be created for the repeated step.
POST /Task is already supported by the broker, but just currently not listed on the API Catalogue (the capability should still be listed within the brokers CapabilityStatement, however).
We would normally expect the equivalent to an LTW LAB-2 interaction as a PUT on an existing Task.
For internal orders, for a single system/entity where no action is required by external organisations, we do not expect systems to send this to the GOMS, as the scope for the central system is just to facilitate cross organisational communication.
Wouldn’t that be a POST /Task? This is like to be the result of a manually entered order which could have be phoned or emailed in (from outside region), so the broker wouldn’t know about this and this interaction corrects that.
I would probably prefer an upsert PUT /Task?identifier={identifier}, so we don’t have to perform a GET to decide whether this is a POST or PUT
Hi Kevin,
If the order is manually entered by the Lab, e.g. in the case of request coming from out of region, this will be a test request bundle (ServiceRequest), i.e. the equivalent of LAB-1, where the filler is raising the request on behalf of the placer.
Further updates re LAB-2 should be against the Tasks that have been spun up in response to the request. This means that all Tasks will be ‘basedOn’ a ServiceRequest within the GOMS environment.
If there is no need for national visibility of the order, e.g. not NHSE commissioned, or fulfilled locally by the lab, neither the Task nor the ServiceRequest needs to be sent to GOMS and can be managed using local procedures.
We will be looking to support upserts in general across a number of resource types post Alpha, which should alleviate needing GETs before submitting information to the broker.
Best,
Omar