Adding custom logic, validation etc. about fhir-works-on-aws-routing HOT 3 CLOSED

Glad to hear your enjoying the project so far!

• Only allow one user to retrieve/view a resource at a time (only for certain types). Once a user "GET"s a resource that resource cannot be "GET" by any other user until the first user releases it or a timeout expires.
  • Very interesting use-case I haven't thought much about this - but you will probably need to add this locking logic to the persistence layer.
  • As for locking out specific ResourceTypes or operations you can control those two things in the fhirConfig
• Support a different schema/profile (australian base profile +)
  • We are working on IGs/Profiles support now
• Validating that a resource referenced from a created resource contains certain data
  • This sounds like referential integrity? Or is this more than that?

As for the best path forward I think a good bit of the work would be done in the persistence layer, with maybe smaller updates to the router. For the router optimally the changes are generic enough to bring into mainline via PR. On the persistence side you may need to roll your own package due to this specific locking use-case.

I hope this helps! Happy to chat more

Robert

from fhir-works-on-aws-routing.

Thanks for the response.

I had a look at adding the locking logic to the persistence layer, however the persistence layer isn't currently passed the userIdentity which would be required. Would modifying things to pass the userIdentity into the persistence layer seem reasonable to you?

I'm actually starting to wonder if some of our use cases like the locking would best/easiest be handled in the lambda handler before/after calling into the fhir-works-on-aws express pipeline rather than being able to customize the internal behaviour of the fhir server itself... treat the fhir server as a separate service that we layer our business logic over...

Looking forward to seeing what you are doing with IGs as we are just starting to investigate that at the moment!

Thanks

from fhir-works-on-aws-routing.

Would modifying things to pass the userIdentity into the persistence layer seem reasonable to you?

Hmmm yeah I think you would have to pass that in as well (which may require an interface change). Especially since you want to add this locking on 'GET's

The idea of treating the FHIR server as a black box and you intercept it before/after is a strong idea. You could do it before and use the user's access_token as their ID to lock against.

from fhir-works-on-aws-routing.