Stream: implementers
Topic: Frameworks for Patient App setup
Simone Heckmann (Jun 15 2016 at 16:27):
Does anyone know of any frameworks for patient apps that describe how these apps can be configured / initialized?
I am currently pondering such questions as:
How can an a Practitioner "invite" a Patient to use a specific app to e.g. manage medications or submit data to the practitioner's system?
How can be ascertained that the Patient installs the proper app and not something from the AppStore that looked similar?
How can the App be set up to communicate with the practitioner's endpoint?
How can the Patient's username be associated with the Patient in the practitioner's system?
Does anyone have some answers or can point me to people thinking about the same questions?
I looked at SMART and FHIRFrame but both don't seem to go there...
Simone Heckmann (Jun 15 2016 at 16:35):
I keep thinking that it would be nice to have the EHRs/Practitioner systems send out eMail invites to patients including a QR-Codes with a download link, some basic instructions and maybe another QR-code that can be scanned by the installed app and configure it with the proper endpoint. But having standardized Apps is somewhat pointless if the setup process is proprietary :P
Abbie Watson (Jun 15 2016 at 16:49):
:) Running up against the deployment distribution problem, eh? The questions you're asking have been asked by most everybody who eventually adopts Node.js. The thinking goes like this:
- Javascript is already installed on all the browsers (ergo, deployment and distribution solved)
- Javascript can be compiled to webapps (via phonegap/cordova) and submitted to app stores (more distribution)
- Node/JS on the server allows a full-stack solution and consistent database strategies between website and apps
- Using a Node/JS stack allows a person on a website and a person using a compiled webapp to use the same backend infrastructure
So, if you're using a full-stack Node/JS framework, it's pretty easy to create apps where Practitioners can invite Patients, download mobile optimized versions of an app via the webstore, and connect everything to the same endpoints. It's all pretty straightforward. It's all within a single framework.
The problem, of course, is that not everybody can simply ditch their existing infrastructure and choose Node/JS. If you're stuck with other infrastructure, you have to piecemeal and glue it together using emails, barcodes, REST endpoints, SDKs, etc.
To your final point, Javascript has been identified as a non-proprietary setup/distribution/deployment solution. And working the app life-cycle backwards, there's a movement towards Node/Javascript frameworks because it has the setup and distribution problem solved from the outset. If every browser was installed with Pascal or Ruby, we'd be talking about full-stack Pascal or full-stack Ruby. But they're not. They're installed with Javascript. So people are talking about full-stack javascript. Because it solves the distribution/deployment problem.
Abbie Watson (Jun 15 2016 at 16:53):
If you want something more tangible, there's the Clinical Meteor project; which is a version of the Meteor stack that supports FHIR. Send a FHIR message to the Meteor FHIR server with Patient ID and the ID of the practitioner who sent it, and an associated Meteor App can be installed via the App Store. The Meteor FHIR server would then handle brokering messages between EMR and app. It's all still a work in progress; but very looking at addressing the questions you asked above.
Clinical Meteor is a distro of the Meteor framework, which supports PhoneGap/Cordova, by the way.
http://www.meteor.com
Erich Schulz (Jun 15 2016 at 23:14):
+1 for full stack JS @Abigail Watson
Simone Heckmann (Jun 16 2016 at 12:49):
Thanks, @Abigail Watson for the input, I will look into your suggestions.
However, we are not so much looking for concrete coding solutions but rather to create guidelines for App implementers aiming to integrate patient centered apps with practitioner / EHR systems.
Abbie Watson (Jun 16 2016 at 16:02):
Fair enough. For what it's worth, the Meteor community has an active community of developers creating patient centered apps, and as a community is starting to connect to EMR systems. I myself have been involved with probably 40 prototypes, and a half-dozen patient portal apps that have made it into various stages of production and are using FHIR to some extent. I'm happy to write up a learned lessons document, as it's been on my backlog for a few months now and I'm currently preparing for a public talk on this general topic. We've got recipes for pretty much every question you ask; they're simply spread out throughout the Cookbook, Guide, and various reference apps. Just need to be put all into one place.
Simone Heckmann (Jun 16 2016 at 16:13):
That sounds definitely like a document I'd be eager to read :)
Simone Heckmann (Jun 16 2016 at 16:15):
BTW: Does anyone know what happened to http://wiki.hl7.org/index.php?title=MHWG_Consumer_Mobile_Health_Application_Functional_Framework, ?
From the mission scope it sounded like they'd discuss this sort of thing but the minutes stopped in August last year...
Simone Heckmann (Jun 16 2016 at 16:32):
@Abigail Watson : I can't seem to find any information on the website about how meteor Apps are associated with EHRs. Can you point me to some resources? Thanks!
Abbie Watson (Jun 16 2016 at 18:51):
Yeah, the EHR specific stuff is in the hl7-argonaut-fhir repository. The documentation is somewhat bare-bones right now, which is why I'm currently working on it; but does have working code examples. Importantly, the fhir-client example compiles to Meteor, which supports Cordova, and can be distributed through AppStores. The fhir-server example has the routing/proxy server and PHI vault for connecting to EHRs and secure HIPAA storage.
https://github.com/clinical-meteor/hl7-argonaut-fhir
Abbie Watson (Jun 16 2016 at 18:56):
As for the Cerner Mobile Health App Framework, my guess is that they completed v0.3 whitepaper, and got something that was sufficient for their internal teams, claimed success, and called it a day. That document is a mash-up of various architecture documents that have been floating around Cerner for years (speaking as a former Cerner Admin). Very similar to what we used when putting Clinical Meteor together.
Abbie Watson (Jun 16 2016 at 18:56):
Question: would it be better to have a FAQ style document? Or a checklist style document? Or an architectural whitepaper? (I feel like I ought to do all three, but not sure which to start with.)
Gregory Johnson (Jun 17 2016 at 01:01):
@Abigail Watson An architectural whitepaper would be best to start with. If you setup that way you can track who downloads the white paper and use that as validation to show the demand/interest of what's being built.
Abbie Watson (Jun 17 2016 at 21:46):
Unfortunately, the whitepaper is also the most difficult to produce. I do agree that it seems to be the target to aim for though.
Last updated: Apr 12 2022 at 19:14 UTC
