Stream: implementers
Topic: Part Resource Update / Authorisation
Medi Harsini (Jun 22 2020 at 09:58):
(deleted)
Medi Harsini (Jun 22 2020 at 10:01):
Has anyone come across an issue where one User can part update a typical resource and another one the whole resource.
Take an example medicinalproduct .... authorisationReferenceNumber ... Only a particular user can make sure the product is authroised and hence update the ref number above. How does this get implemented and documented?
René Spronk (Jun 22 2020 at 14:25):
That's purely a server side issue, authorisation/access control. Limitations on who's allowed to update are fairly common.
Medi Harsini (Jun 22 2020 at 18:28):
@René Spronk Well thats not entirely true... To shed some lights into the details when I wanted to design the API endpoints for two different users each with different sort of user access then I have to define my resource in part definitions. Take the same example where medicinalproduct can partly gets updated by user1 and partly for user2... Then your API endpoints may look like PUT /medicinalproduct/{id}/authorisation and/or /medicinalproduct/{id}/generaldetails where need to define two different schemas (both based on medicinalproduct) in which you can apply two user scope as you now have two endpoints. Thats one way of handling the above issue... Alternatively you can field check based on the issued scope which is very resource consuming
Rik Smithies (Jun 22 2020 at 19:08):
You can define endpoints that are operations (e.g. /MedicinalProduct/{id}/$updateAuth), and then you can have whatever behaviour you like. But it won't be standard FHIR and only those who work directly with you will support it.
Lloyd McKenzie (Jun 22 2020 at 19:41):
You can expose different CapabilityStatements to systems authenticating with different user ids, so you could expose distinct profiles (and distinct sets of supported operations) based on what the user is allowed to do. That would be conformant and interoperable with most FHIR solutions. (Custom endpoints would not.)
Michele Mottini (Jun 22 2020 at 20:05):
You can expose different CapabilityStatements to systems authenticating with different user ids
Usually /metadata is unprotected - so not really....
Medi Harsini (Jun 22 2020 at 20:56):
Im sure I am not the only person who come across this as a requirement... I agree with Michele that /metadata is not supported always and having different profile for one resource under the same organisation makes the deployment quiet difficult to manage. What it happens in practice is creating different schema for and different endpoints ex. Post /medicationlist and/or post medicationauth but we know FHIR doesnt like it ... But FHIR also doesnt support the hierarchical process as explained above.
Michele Mottini (Jun 22 2020 at 21:45):
Having said that I do not understand what the issue is: the API calls are always the same and they can / cannot do stuff depending on the user that issue them
Medi Harsini (Jun 22 2020 at 22:10):
It’s a requirement and the issue is the lack of feature/capability to support such requirement
Michele Mottini (Jun 22 2020 at 22:24):
I don't understand the requirement then. User 1 and user 2 do the same FHIR PUT - if one of them tries to change elements they do not have permission for the request fails with a 403 - forbidden, and possibly same more explanation in the response body as an OperationOutcome
Michele Mottini (Jun 22 2020 at 22:24):
No need for separate APIs or anything like that
Vassil Peytchev (Jun 22 2020 at 22:26):
I thought servers had the ability to decide how they process a create or update API call. Wouldn't that apply here, with the decision based on the API caller? I don't know whether this indeed means that checking the input is resource consuming...
Medi Harsini (Jun 22 2020 at 23:22):
Sorry for not defining this clearly. Both users need to update the resource but user1 can update all the fields on the resource and user2 only part of it
Lloyd McKenzie (Jun 23 2020 at 03:03):
Sure - but you can do that with different profiles. Alternatively, you can simply yell if a user changes something they shouldn't or (better yet), ignore changes they're not allowed to make and give them a warning message.
René Spronk (Jun 23 2020 at 06:36):
Exactly. No need for multiple endpoints or operations - the server just ignores those any data that a particular user isn't allowed to update. If you don't want that, use an operation, which works akin to a PATCH for a well defined subset of the data elements in a resource.
Medi Harsini (Jun 23 2020 at 08:36):
Thanks @Lloyd McKenzie I will probably going ahead with the suggestions on creating operation. Having different profiles and have them mandated in /meta is not something which can be easily done in implementation... Also I define all of my concepts in Swagger and thats even make it harder to clarify on the documentations ...
Lloyd McKenzie (Jun 23 2020 at 14:31):
Different operations means you're not going to interoperate with any other systems that use FHIR, so I'd be really cautious about pursuing that approach. In general, your objective should be to do things the same as other systems as much as possible - after all, the reason to use a standard is to exchange data with others as seamlessly as possible and minimize the need to write custom code to share with any particular system.
Medi Harsini (Jun 23 2020 at 18:43):
Thanks @Lloyd McKenzie just to clarify that I understood you correctly. If I’ve got to create two profiles for the resource appointment for any reasons, then should it be under one url endpoint; post /appointment but With one of the two schemas in which the backend system decides which profile is used and then perform the relate actions ? Or I can define it differently which makes it recognisable For the consumer into the two endpoints like post /appointment/v1.0/authorise and post appointment/v1.3/general
Rik Smithies (Jun 23 2020 at 19:16):
re your "Or": FHIR doesn't allow those endpoints on a single (logical) server, sorry. That is not the FHIR way.
You cannot have paths other than /server/{resource} or with an id on the end and/or an $operation.
To achieve what you suggest would need two servers (or one acting as two), which is possible but probably not what you want, and totally non-standard. FHIR clients won't expect to target two servers.
The only way to add custom paths on one server is via operations.
Your first suggestion (one URL) is better but you don't actually need profiles for the "modes". They would just act like a flag set by the client "I am using profile X, please allow me to do mode X".
But that can be abused, and would need cross checking with the permissions, so it doesn't achieve much imho.
Lloyd McKenzie (Jun 23 2020 at 19:29):
The general expectation is that everyone writes to a single endpoint and the server decides what each system is allowed to do - it doesn't expose distinct APIs
Grahame Grieve (Jun 23 2020 at 21:42):
the driver here is a limitation of swagger. if you want to express schemas that relate to different permissions, you need different end-points on swagger, even though it's the same resource.
Grahame Grieve (Jun 23 2020 at 21:43):
I don't see an easy way to resolve this mis-match given where we are right now. But you can secure /metadata, even if, as @Michele Mottini says, this isn't usually done
Grahame Grieve (Jun 23 2020 at 21:44):
or you can put up microservices for authorised clients - I've seen several implementers doing this, to the point of putting up microservices for particular work contexts
Lloyd McKenzie (Jun 23 2020 at 21:48):
How do those microservices handle resource identity if resource instances are shared across endpoints?
Grahame Grieve (Jun 23 2020 at 21:52):
they don't, I think, from what I saw anyway. It causes cache pollution, but I think the system developers didn't know about that or care about it
Grahame Grieve (Jun 23 2020 at 21:52):
not their problem....
Medi Harsini (Jun 24 2020 at 14:26):
@Grahame Grieve Thanks for explaining the underlying issue there as thats exactly the reason I brought this up...
Medi Harsini (Jun 24 2020 at 14:31):
I still not following how Microservices can help here... I have got microservices oriented architecture but the issue as you well defines is that you cant define one endpoints defined twice for two different purpose ( ex. general details updates / Authorisation). You can however add two schemas for the requestbodies and user oneoff type.. That would rectify the issue of how to define two version of a typical resource without mentioning the Profile tag under meta...
Medi Harsini (Jun 24 2020 at 14:31):
(deleted)
Medi Harsini (Jun 24 2020 at 14:32):
The issue is then the back end system on how to handle the request ... The only think that I could think of is that to enforce the Oauth scope to add the user, user's role into it... in which the backend application based on the user role decides the used schema is allowed or not...
Medi Harsini (Jun 24 2020 at 14:33):
Thats would help the issue but still doesnt help the API concumers when it reads the documents to quickly spot which schema must be used unless the openAPI spec comes with more descriptions ...
Medi Harsini (Jun 24 2020 at 14:34):
Or proceed with how @Rik Smithies suggests there... which then it can rectify the readability of the doc set
Rik Smithies (Jun 24 2020 at 14:43):
Yes your different profiles are a way to document the different fields that are expected, so that can aid spec readability. And they can be used by the client to check they are doing things right and by the server to check its a correctly formatted request. They just can't be your security or modes in themselves. Profiles profile usage of a single end point, they don't create or enforce multiple physical ones.
Last updated: Apr 12 2022 at 19:14 UTC
