Stream: implementers
Topic: SMART on FHIR Implementers
Lisa Nelson (Mar 15 2016 at 18:05):
I would like to know what companies offer implementation services for an HIT Solution that needs to outsource development to make the solution a SMART on FHIR application. Does anyone know of any companies that provide development services to help a small entrepreneurial company develop a SMART on FHIR interface for an existing web application?
David Hay (Mar 15 2016 at 19:41):
I don't, but this seems like a good niche for a company to move into . Ironically, I'm doing a series of posts on SMART with the intention of persuading my company to support SMART, and one of the benefits I've identified is the potential to move into this space! I'll be interested to see what responses you get...
Gana Pemmanda (Mar 16 2016 at 23:18):
Hi Lisa,
We are a FHIR impementer and in the process setting up SMART on our FHIR server for testing a SMART app we developed(indiviual health risk assessment). We have capabilities and bandwidth (hopefully) to help you with your application. Please let me know what exactly you are looking for. If you want to reach me directly, you can send me an email at gana@hygeiais.com.
Doug Bulleit (Jul 14 2018 at 16:47):
Is this the right place to ask a question about OAuth Refresh Tokens?
John Silva (Jul 15 2018 at 12:12):
I was at DevDays and went to a couple of presentations about SMART on FHIR. What I was looking for was some information about EHRs actually being the 'targets' of SMART on FHIR invocations. What I mean by that is that I was interesting in learning about EHRs that can be launched via a SMART on FHIR mechanism rather than the EHR launching an app. Has such a use case been brought up? The notion is that the EMR isn't always 'in the center of control', could there be other applications (or app frameworks) that control the launching of EMRs using the same mechanism? (Of course that would also mean getting EMR vendors to allow themselves to be launched this way. Even more importantly would be EMRs that can have their context controlled via FHIRcast so that an 'app framework' could control the EMRs 'current user and patient' and other contexts.)
Lloyd McKenzie (Jul 15 2018 at 14:33):
SMART can allow a web app to access data of an EMR that's already running, but there's no ability in SMART to launch an EMR and I don't think that use-case has been talked about. Can you expand more on the proposed workflow and why it's needed?
John Silva (Jul 15 2018 at 14:44):
A simple example is that if I'm at a desktop running a DICOM viewing application and I want to launch the EMR with the same patient context so that I can check something on the EMR, e.g. some procedure related to the image I'm looking at, I need to launch the EMR ideally without additional 'keystrokes' (login, choosing patient, etc.). [It's not about accessing the EMR's data via FHIR in this example, it's really like the context management that CCOW addressed, hence looking at how SMART on FHIR and FHIRcast could be used to solve this workflow.] Not sure if you remember or have heard of the Orion Concerto product (back ~ 20 yrs ago - https://orionhealth.com/global/about-us/our-story/timeline/) it had the ability to launch and control context (user, patient and other subjects) in a web-based portal with the "EMR" just being another application; this use case has been around for a long time.
Lloyd McKenzie (Jul 15 2018 at 14:50):
There's a draft specification for context synchronization using FHIR called FHIRCast (http://fhircast.org/) however it doesn't rely on a system running a "context manager". If you want to get into launching applications, you need to have a context manager - no way to start apps on a system with a REST call unless there's something sitting there listening that can do the launching. What FHIRCast could do (I think) is synchronize the EMR with what you're looking at in DICOM when you launch it manually. @Isaac Vetter ?
John Silva (Jul 15 2018 at 16:42):
Yes, I know (a little) about FHIRcast (went to Isaac's talk at DevDays). I thought though that SMART on FHIR had a "launch mechanism" for starting 'SMART apps" from an EMR? Why can't EMRs be 'just another' target of a SMART App launch? (The DICOM use case is just an example; it could be any set of applications on the desktop that are or can be coordinated by an 'app framework' that uses SMART on FHIR and FHIRcast to coordinate launching, single sign-on and patient context. In other words, there can be something other that the EMR controlling the FHIRcast context and launching apps.)
Grahame Grieve (Jul 16 2018 at 00:42):
@John Silva The smart spec and the argonaut work derived from it assume a simple case: one EHR launching one layer of apps. There's no support for apps launching other apps - it's a problem around creating derived tokens (so not directly related to smart it self). Similarly, there's no anticipation that the argonaut vendors will be interested in the kinds of questions you're asking....
Isaac Vetter (Jul 16 2018 at 04:19):
Hey @John Silva , indeed, derived OAuth 2.0 tokens are complicated. I'm not sure that we need them to enable your use-case. I know that the FHIRcast core team has talked about this scenario (but I couldn't find it as a documented issues and so) I just created issue #35. This is a fairly common workflow and this functionality does exist in prod, so I'm pretty sure that I understand your use-case, but please do add comments to the FHIRcast github issue.
John Silva (Jul 16 2018 at 12:55):
@Grahame Grieve - I view the EMR as just another peer in this SMART app launch world, not the 'master' (but that might be from my historical perspective from CCOW) [It also feels like the older HL7 "Infobutton" though that is more equivalent to "CDS Hooks" with older HL7 technology - http://www.hl7.org/implement/standards/product_brief.cfm?product_id=208 ]. I do not know about the technical issues with OAuth 2.0 tokens but in the CCOW world there used to be this concept of 'chain of trust', which needed to be established so that all participants in the context were able to trust each other ( as peers).
@Isaac Vetter - thanks for entering the GForce item; I'll try to update it with more info about the 'peer apps' concept.
Last updated: Apr 12 2022 at 19:14 UTC
