Stream: argonaut
Topic: App state
Josh Mandel (Mar 17 2022 at 16:09):
Reminder that our App State call is on today at 1p CT.
Josh Mandel (Mar 17 2022 at 19:05):
From today's call -- please reflect on the proposed goals and proposed design at https://hackmd.io/@argonaut/smart-app-state
We'd like to understand who's willing to build infrastructure in support of the prioritized goals below. As I said, I think the same design can readily cover the P0 and P1 proposals, and as such it's a good thing to cover both. But if we have folks willing to support the P0 and not the P1, that'd be an important input. As @Cooper Thompson mentioned, restrictions could always be at the business level (contracts/agreements) rather than at the technical level, if we opt for a unified design.
Proposed Goals
- P0 Enable patient-facing apps to store "small" data in EHR in support of use cases like E2E encryption of external data. This enables EHR-embedded apps to display at-home fitness data with E2E encryption. It's important because it surfaces diverse at-home data in the clinical workflow.
- without being prescriptive about the "how" (algorithms, token formats, etc would be app-internal details)
- P1 Support additional use cases including provider-specific preferences for apps that otherwise have no backend. This enables EHR-embedded apps to serve up the screens that a user prefers. It's important because it lowers the friction of launching an app and getting into a productive state.
- Good thing about this goal is that it helps shape API design for P0s (toward minimalism)
- P2? Support app ability for provider-facing "companion apps" to write back non-opaque data. This enables EHR-embedded apps to return standardized data into the EHR. It's important because it helps other clinical tools make use of data, if standards exist.
- e.g., Audit log documents?
- e.g., Discrete FHIR data that a clinician has chosen to import?
Ben Winters (Mar 31 2022 at 21:36):
Another use-case that may fit within P1: an application's "message of the day" would be an example of something an app without a backend might want to store. If that fit here, the the subject wouldn't be a patient or practitioner, so the scope of Basic.subject would need to be expanded. Device could potentially be used - the verbiage in STU3 Device states "Non-medical devices may include items such as a machine, cellphone, computer, application, etc." Not sure why that line was removed from the R4 Device description.
Josh Mandel (Mar 31 2022 at 21:48):
Interesting. Are there use cases where this message of the day would contain protected health information or other sensitive information that an app could not make available through its own static hosting? The app does need at least enough hosting to support static application content (HTML, JavaScript , css, etc)
Ben Winters (Apr 01 2022 at 16:07):
That's definitely fair, I don't have a scenario for PHI in the MotD. One of our FHIR customers did the use-case I stated, but they eventually changed that to use a cloud function of some sort instead.
Josh Mandel (Apr 12 2022 at 02:57):
Based on our last call, I've drafted a separate write-up at https://hackmd.io/@argonaut/smart-app-state-with-custom-ops which aims to support routing App State requests based on URL pattern matching.
To accomplish this, we'd have to move away from using the standard FHIR REST API and use something like the custom $smart-app-state-* operations I've proposed in the draft. (The details of how we accomplish this can be debated -- e.g., do we defined one operation or several? Do we return Bundles or Parameters? etc, etc -- but I'd rather suppress that debate while we squint and decide if we like the general way this is shaping up.)
This is a significant cost in my view, because it means out-of-the-box behaviors like batching, search parameters, version management, conditional operations, and contention management won't work, or we'll have to re-invent them.
The benefit is that @Brian Forbis would be able to perform path-based routing, instead of routing Basic CRUDS requests based on payload content.
It's not clear to me that the benefit is worth the costs, but I'd like to get feedback here or on Thursday's call.
Last updated: Apr 12 2022 at 19:14 UTC
