Stream: implementers
Topic: Use of fhir-operation ($) to create resource
Allan Bro Hansen (Jun 05 2018 at 20:42):
How should we support the creation of resource with fhir operations ($)?
Is the against the specification to use the fhir-operation on the base resource?
E.g. (just a made-up example to illustrate) :
../Patient/$createSimplePatientUseAddressFromNationalSystem - with some basic values as parameters
../Patient/$createPatientAlsoInformNationalSystem - with some other basic values as parameters
The spec says (From https://www.hl7.org/fhir/operations.html#executing):
"A Resource type (e.g. http://fhir.someserver.org/fhir/Patient): These are operations that operate across all instances of a given resource type"):
I may seem like a bit far-stretched interpretation of "operate across all instances" to include "create a new resource instance"?
My specific scenario:
We develop a booking system having mainly appointments (quite naturally), but also referalrequests to support the case an expected visit by a Patient to the emergency ward.
We also support a queue flow for specific departments and have a queueItem-resource to model this.
When the patient arrives at such a department the queueItem resource is created.
We have decided to use fhir-operations at QueueItem to support the state-transitions after the arrival .
(like ../QueueItem/theQueueId/$callPatient with needed information in parameters).
The use of Fhir-operations seemed more accurate (and client friendly) than using a PATCH to set a status (or to PUT the full resource); also, the operations may perform changes of the appointment.
The queueItem is created as part of the patient arrival - to keep a symmetric/logical solution, the choice for the patient arrival support would be:
POST ../QueueItem/$callPatient
with parameters including (amongst other) the id of the appointment/referalrequest.
Lloyd McKenzie (Jun 05 2018 at 20:49):
You can define operations to do all sorts of things - your challenge is that no other systems are going to support them unless you pay them enough money to make it worth their while to do the development and ongoing maintenance of that custom interface. So, while a custom operation might be more "efficient" than just doing a standard HTTP POST create or PUT update, you're actually imposing a lot of cost on the community by going that route. Also, QueueItem isn't a FHIR resource, so your interface wouldn't technically be using FHIR operations either. It'd be a custom interface that happened to pass FHIR resources around as part of it.
Lloyd McKenzie (Jun 05 2018 at 20:50):
Rather than QueueItem, have you looked at Task? It's intended to manage "lists of things to be done", including requesting state transitions. For example, Task is the proper way to say "Can you please cancel prescription XYZ?"
Allan Bro Hansen (Jun 05 2018 at 21:39):
Thanks for a quick reply
1) Are you saying that "technical" an FHIR concepts (like $operations) do not apply to a custom resource? (custom resources are still resources, right, so I would say we are using FHIR operation on a custom resource.
2) Task does not seem to fit the "resource handling flow and information concerning the patient arrived in the waiting room (giving a ticket) and being called to the examination room)". (That is based on a 5 min read - we are on stu2 which is without the task resource)
3) Our FHIR interface envolves by client demands - this is a client asking (and paying) for a easy way to e.g. call the patient.
4) (my question) I know I can do all with operations - but it may seam that for /Patient/$soSomeThing , it would be wrong to let $soSomeThing create a new Patient instance.
Lloyd McKenzie (Jun 05 2018 at 22:48):
1. 'Custom' resources are not FHIR compliant. That doesn't mean you can't go off and create any kind of resource you like - but doing that is outside of FHIR and won't work with FHIR reference implementations, FHIR test servers, etc.
2. Task is all about workflow execution. Tasks can have hierarchies of sub-tasks. So if you're wanting to generate a set of steps triggered by patient arrival and monitor who's assigned to do each and where you're at in the process, Task is your resource.
3. Make sure to understand what your client expects to get in the end. If you implement a bunch of custom operations that no other system supports and your client is expecting to interoperate with a bunch of systems because "they have a FHIR interface", then you're not meeting your client's needs. If your client controls both sides of the interface and doesn't need to talk to anyone else and just wants something that is FHIR-ish where they don't expect to leverage any of the publicly available tools and resources, then custom resources and custom operations may be fine.
4. It's not "wrong" to use Patient/$doSomething to create a resource, it's just a bit weird - and not something other systems will support out of the box. When approaching a FHIR interface, it's generally best to ask the question "How does almost everyone else do this?" followed by "Is there any reason we need to do it differently?" If you're implementing a standard interface, you'll never be as efficient as if you build something custom-tuned for your architecture, requirements and environment. So "not as efficient" isn't a strong need unless you're starting to get into orders of magnitudes of difference. Also, always keep in mind the costs of those who will be integrating with you in addition to your own direct costs. In the end, you'll end up paying for others' costs too - or if no one pays the costs, then you'll find you have no one to integrate with.
Lloyd McKenzie (Jun 05 2018 at 23:08):
(In DSTU2, the equivalent of Task is a combination of Order and OrderResponse, though they're a bit broken, so you'll probably need to use extensions and a few work-arounds to get them to meet your needs.)
Allan Bro Hansen (Jun 06 2018 at 06:01):
Thanks
1) Okay - we still try to follow all FHIR guidelines for our custom ressources - so I think we are still "inside FHIR" but of course test servers will not have them, just like they don't have all our extensions of FHIR's built-in ressources.
2) Okay - maybe a task with subtasks could work - but it would mean a conceptuel change of our 10 years old QueueItem concept.
3) I understand - I still think custom operation are fine as add-ons to meet clients demands. Specially in respect to state transitions.
4) Yes "the weirdness" goes for all kind of interfaces.Our interface evolves by client demands (and an fhir operation is not my first "offer").
Lloyd McKenzie (Jun 06 2018 at 06:56):
1. Right now, any use of 'custom' resources is non-conformant. We're exploring options to support custom resources, but the current state is "outside FHIR"
2. You'll need to map your internal objects to FHIR objects. The FHIR objects won't necessarily have the same names and may not work identically. That mapping exercise is part of what it means to use a standard
3. Custom operations aren't prohibited. Just be aware that most systems won't support them and expect to do state transitions with a simple update of the resource instance
4. So long as the client is aware that custom operations won't likely be supported by anyone else and they're fine with that lack of interoperability, then I guess proceed. (Though the question then is - what is their reason for wanting to use FHIR?)
Grahame Grieve (Jun 06 2018 at 06:59):
I have a really good hammer....
Allan Bro Hansen (Jun 06 2018 at 07:25):
Sometimes you clean your house by taking one room at a time - instead of just swinging a big hammer :-)
Jens Villadsen (Jun 08 2018 at 13:41):
I don't necessarily think that this customer actually pays much attention this kind of extended use of FHIR. It is however a step in the right direction just to have them accept the use of FHIR. @Allan Bro Hansen I fully agree with you - baby steps is the way forward most of the time. You could sell it as continuous improvement ;)
Last updated: Apr 12 2022 at 19:14 UTC
