Stream: smart
Topic: User Preferences
Brian Wright (Apr 18 2019 at 19:49):
Are there are recommendations/patterns for persisting user UI preferences in a SoF App? My question is primarily regarding provider facing standalone SMART application that will be used by each user on many desktop systems. User preferences would be things like default color scheme, default clinical time ranges, etc..
Lloyd McKenzie (Apr 18 2019 at 19:55):
I expect you'd be looking at either Observations or Basic. I don't think there's been much discussion of standardizing that sort of thing.
Patrick Haren (Apr 18 2019 at 20:04):
There are only patterns for apps embedded in EHRs - so that they follow the same stylesheet/look-and-feel and appear seamless.
For standalone, you're on your own. I would not expect FHIR to define anything here either (following the 80/20 rule).
Lloyd McKenzie (Apr 18 2019 at 20:23):
Creation of resources isn't driven by the 80/20 rule. But it is driven by "is this a healthcare-specific solution space?"
Grahame Grieve (Apr 18 2019 at 20:59):
http://www.hl7.org/fhir/smart-app-launch/scopes-and-launch-context/#styling
Brian Postlethwaite (Apr 22 2019 at 13:26):
I would say user preferences relevant to your smart app would belong in your smart app.
Brian Wright (May 09 2019 at 19:10):
Thank you for the replies. My summarization:
If you have a smart application with a backend API, using that API would be the preferred approach for providing cross device user preference management.
If for some reason, you have a strong preference for a "client only" application with no app specific API, you could:
1) Write user preferences to your FHIR server using a standard FHIR resource (Observation or Basic). This would require you to request write scope, which, depending on your environment, may seem overly broad.
2) Speaking with Christiaan Knaap, if you are using the Vonk server, this may be a good use case for Vonk support of custom resources (not for interoperability, avoids having to set up and maintain a separate persistence layer).
3) If this becomes a more common requirement in the future for a broader set of applications, something similar to smart_style_url may be appropriate.
Last updated: Apr 12 2022 at 19:14 UTC
