Stream: implementers
Topic: Fhir on AWS
Adam Flinton (May 21 2019 at 06:57):
Has anyone looked at how best to run Fhir on AWS? i.e. lambda vs container, how dumb/bright the api gateway, what db in the background (e.g. dynamodb vs aurora/sql, use of elasticsearch etc.etc).
Early days trying to work out how best to put something together which will be reasonably easy to roll forward as fhir versions come & go. i.e. I would like to build something that can steadily roll forward vs some sort of right right now system.
thanks
Grahame Grieve (May 21 2019 at 07:08):
we don't usually talk about it as an AWS thing... you choose how you want to build your server , and deploy whatever you choose on AWS...
Adam Flinton (May 21 2019 at 07:13):
I sort of agree.... the sort of coming from the fairly specific capabilities aws has and how best to use them. I have been looking at how the MS on azure system is set up & the degree to which capabilities map to pipelines of compute, events & persistence etc. vs the "a server" approach.
Grahame Grieve (May 21 2019 at 07:16):
k. I don't recall a discussion that specific before
Adam Flinton (May 21 2019 at 07:23):
quick example, fhir doc could come in sync via http (& expect sync response) or async via mesh (in amongst a bunch of non fhir messages) & thus output might need writing out to a mesh mail box but the underlying logic & thus pipeline will be the same. This pipeline might be specific for a given version of fhir thus when the next version (of fhir) comes along, we can create a new pipeline based off the old (probably) but with one stage changed to handle the new version while leaving the original in place to handle any of the old which might still be coming in from others who are not yet at the new spec.
Adam Flinton (May 21 2019 at 07:29):
Only vague example I have spotted is: https://www.slideshare.net/AmazonWebServices/aws-serverless-interface-building-and-cerners-fhir-experience-hlc401-aws-reinvent-2018
Robert Winterbottom (May 21 2019 at 12:41):
We are using AWS, but I tend to agree with Graham here. The infrastructure really depends on use cases and any cloud provider has more than enough tools or customization available to support all of these things. We personally decided on containers and to be specific kubernetes (which is supported by all three major cloud providers). We also use terraform so if we need to modify infrastructure it is really simple, and can be ported to other providers. DB also is entirely up to the customer, it's pretty easy to setup a cluster in RDS where you can choose whatever engine you want.
Yunwei Wang (May 21 2019 at 15:11):
My Terminology Server is on AWS.
Mikael Rinnetmäki (May 30 2019 at 05:59):
Amazon's Chris McCurdy gave a presentation at FHIRDevDays Amsterdam 2018 on Deploying FHIR Data in AWS, which gave at least some suggestions.
nicola (RIO/SS) (May 30 2019 at 08:14):
We deploy aidbox and postgresql in AWS kubernetes without any problems. Kubernetes is a good abstraction layer - if you will use it - you will be able to deploy to most of the clouds with small changes.
Ahmed Mohamed (May 31 2019 at 14:44):
Amazon's Chris McCurdy gave a presentation at FHIRDevDays Amsterdam 2018 on Deploying FHIR Data in AWS, which gave at least some suggestions.
Do you happen to have a URL for this one, I can't seem to find it?
Adam Flinton (Jun 04 2019 at 13:51):
We are trying to stick to AWS services etc wherever possible (& the global ones at that i.e. avoiding vpc joy i.e. dynamodb instead or aurora & sns/sqs/lambda/api gateway etc.) i.e. trying to stay as far away from EC2 as possible (right through to fargate if docker etc). Serverless if possible and event driven.
Veliyan Georgiev (Jun 11 2019 at 15:50):
The API Gateway is pretty good. Actually it is one of the most spec-compliant out there. There are some limitations around the formatting of scopes but all and all - can’t say a bad word about it. We have a fhir server instance running on top of RDS (Postgres) and it is also not bad. If you like MySQL better - they have a performance optimized option that was kinda hidden in the drop down so it is easy to miss but it seems like it performed better. As far as Analytics - it is a much longer story. (I’m hoping we do a talk on the next dev days)
Adam Flinton (Jun 13 2019 at 12:09):
If doing a talk let me know so I could possibly hook in to listen (if they are shared to voip or afterwards to a recording). Been looking a fair amount at this e.g. the various aws hadoopy things (lakeformation/athena etc, etc.)
Mikael Rinnetmäki (Jun 28 2019 at 16:25):
@Ahmed Mohamed I know this is most likely not what you ask for, but you can find the program for FHIR DevDays Amsterdam 2018 at https://www.devdays.com/wp-content/uploads/2019/02/FHIR-DEVDAYS-_PROGRAM_GUIDE_AMS_2018.pdf, and see Chris's presentation slot at 15.35 on Wednesday.
What you're probably looking for is the presentation materials (only available to attendees AFAIK) or the recording of the presentation. I've heard rumours that the recorded videos from the event will be published at https://www.devdays.com/videos/ any day now.
Adam Flinton (Jul 01 2019 at 06:28):
Thanks. I'm sure it will be useful when it is posted. Useful site in general.
Jag Gunawardana (Jul 01 2019 at 19:50):
Been looking at something similar, but over multiple cloud providers. The Google healthcare offering looks interesting. We're looking at building functionality on top of this using microservices orchestrated in Kubernetes. Has anyone else used other cloud services for this (other than noted above)?
Kevin Mayfield (Jul 02 2019 at 05:44):
We’ve not gone into depth on AWS but so far our approach has been to use a series of ‘micro’ FHIR servers.
These servers are a mix bag, mostly security and transforming interceptors. Some turn fhir apis into fhir servers.
These services are for UI clients and expect to reuse them in a messaging layer (another set of fhir servers - actually clients to your endpoint use case)
We’re also looking at federating authentication - using health and gov openid at the servers would be complex. Ditto authorisation which maybe a combination of identity management and api gateway.
Kevin Mayfield (Jul 02 2019 at 05:45):
We’ve also gone for containers, managed by rancher.
Kevin Mayfield (Jul 02 2019 at 05:46):
Servers are all built using HAPI at the mo with some HAPI JPA servers
Jag Gunawardana (Jul 02 2019 at 12:20):
It feels a bit like authorisation is left as more of an afterthought in FHIR. I don't mind 'rolling your own', but the mechanism seems very open (maybe that's a good thing). I've experimented on AWS, but ended up using Open Policy Agent to get find grained attribute based authorisation. Are there any implementations (on AWS or otherwise) that have pluggable authorisation?
Adam Flinton (Jul 05 2019 at 09:58):
Authorization is a hard problem. Authn is easy Authz is hard. We have a policy of using aws services & as such cognito + our own auth system using RBAC's mandated by the (English) NHS (also applicable to other parts of the union) with a declared aim of patient consent etc.etc. i.e. who owns the record etc. We have found have found a number of 95% solutions but then the final 5% is fatal and that solution is not viable. OPA is very good & is part of a (the?) solution. I have to say this is not new and is a massive hole in health it in general e.g. I was involved in the failed NHS Legitimate Relationship Service (LRS) which foundered on the question of who owns the data & thus who can given the perms in the 1st place. So the quick answer to your question is no but it is not hard to build one (e.g. using cloud directory, cognito & possible dynamodb) but that is just the start i.e. the pluggable part is fairly easy. The set of assertions given A, B & C is more fun. e.g. "If org A has a sharing agreement with org B then Clinician from Org A can see patient data from Org B" where org to org rels are in an separate orgs system.
Grahame Grieve (Jul 05 2019 at 10:27):
authorisation is left as more of an afterthought in FHIR
Yes but we strongly recommend Smart App Launch (http://hl7.org/fhir/smart-app-launch)
K Nag (Apr 03 2021 at 01:59):
Dear All, This is my first post and apologies if I am deviating from the Topics that you are already discussing. I am a newbie to this FHIR world and trying to help a Hospital in setting up our own EHR Servers + Custom build the client (Web/Mobile) application connecting to the FHIR server.
Read about FHIR on AWS - I followed the below documentation and was able to test the solution with postman.
https://docs.aws.amazon.com/solutions/latest/fhir-works-on-aws/welcome.html
Now I am exploring for a Mobile and web library/SDK so that I can connect the AWS FHIR service which I created using the above documentation.
I have explored https://github.com/SMARTMarkers/smartmarkers-ios for iOS Application, But struck with authentication using OATH 2.0, I guess I will have to spend more time exploring.
Just curious if someone have consumed the AWS solution in mobile/web application and may have any advices. Also Am I going in the right direction. Appreciate your kind advice and suggestions ! Thanks a Bunch in advance.
Tilo Christ (Apr 03 2021 at 10:47):
Generally speaking, OAuth2 on mobile is more tricky than on the browser, as you have to deal with routing the redirect URL into your app. An implementation of that for iOS and Android is AppAuth https://appauth.io. Depending on your preference (native vs hybrid) there are also wrappers available, such as flutter_appauth (https://pub.dev/packages/flutter_appauth). If you feel that this is not enough wrapping already, there is also fhir_auth by @Grey Faulkenberry which ties it in with a family of FHIR libraries for Flutter. You might also find ResearchPackage (https://github.com/cph-cachet/research.package) or Faiadashu FHIRDash (https://pub.dev/packages/faiadashu) helpful.
K Nag (Apr 03 2021 at 13:05):
@Tilo Christ Thank you for the valuable information. The fihr_auth doesn't seem to support AWS cognito yet. And I am looking for Native solution.
@Grey Faulkenberry Do you have any suggestions in my use case. Appreciate your kind response.
Tilo Christ (Apr 03 2021 at 13:08):
For native solution you would probably go with AppAuth. @Grey Faulkenberry has AWS support for fhir_auth in his plans, but not there yet. But since you want to go native that would not be an option for you.
Grey Faulkenberry (Apr 03 2021 at 13:14):
Aws just released their amplify for flutter packages a couple of weeks ago, so I haven't implemented them for cognito login.
Grey Faulkenberry (Apr 03 2021 at 13:17):
Also, not sure if you've looked at aws health lake. I think that's where they're going.
Grey Faulkenberry (Apr 03 2021 at 13:18):
It's only in preview right now, not production, and I think that is what they're going to use for fhir, not fhir works.
Grey Faulkenberry (Apr 03 2021 at 13:21):
I've been told it's not that difficult to implement amplify, but I haven't had the chance yet.
Grey Faulkenberry (Apr 03 2021 at 13:23):
Also, can I ask what you mean by native? Flutter compiles to native code, but I'm not sure everyone would consider it native.
Tilo Christ (Apr 03 2021 at 13:33):
native = more bare metal, fewer layers of wrapping :-D https://www.youtube.com/watch?v=evUWersr7pc
K Nag (Apr 06 2021 at 17:20):
Yes. I was able to authenticate from iOS (Native) application to aws incognito using Amplify, so now I should be able to connect to the service layer "FIHR works on aws". And for trying various FIHR modules - SWIFT ON FIHR is probably the library which I can integrate on iOS Native application.
K Nag (Apr 10 2021 at 13:19):
I cloned this project https://github.com/SMARTMarkers/easipro-patient-ios and tried to connect to my FIHR on AWS. I am really clueless what is going wrong with Authentication.
Last updated: Apr 12 2022 at 19:14 UTC
