Stream: implementers
Topic: Developing an app
Stanley Denman (Oct 20 2021 at 21:58):
I am not a programmer or health IT expert, but I am exploring the creation of an app that would collect medical data for a personal injury lawyer's clients. The idea would be to furnish the lawyer with uniform medical data about her clients. I was attracted to FHIR as I read about this issue of a standard medical data model. But I am wondering about making the API calls to disparate EHR providers - there appear to be hundreds. Would I have to figure out how to make calls to Epic, eClinicalWorks, LLC , NextGen Healthcare, GE Healthcare and on and on..which I think would make the project unviable.
Michele Mottini (Oct 20 2021 at 22:26):
They all use FHIR (more or less), but yes, it is not trivial
Michele Mottini (Oct 20 2021 at 22:28):
Especially the 'uniform medical data' part - even if it all comes as FHIR is still not very uniform!
Lloyd McKenzie (Oct 20 2021 at 22:33):
There are patient apps that have connections to most, if not all of the EHRs. Also, EHRs are required to share with patient apps. If you can get the data from the patient app, that might solve your problem.
Steven Vafadar (Oct 21 2021 at 02:46):
I had an idea for a software service that would encompass a multitude of functions. It's a prescription transfer service company, where there is a central government database (to collect and send patient data to), a network layer for pharmacies to connect to, and an interface layer where the user is able to access functions regarding their prescriptions. Because it's dealing with consumer health info, I would need to encode it within FHIR/HL7. I'm inquiring about how I would go about learning that encryption, and if I could use other programming languages to create the 3 layers mentioned above, and still implementing FHIR/HL7 encryption standards.
Thanks!
Lloyd McKenzie (Oct 21 2021 at 03:54):
FHIR is a data encoding standard, not an encryption standard. What country are you planning to operate in? (Some countries have regulations that govern what standards can be used for this sort of thing.)
Steven Vafadar (Oct 21 2021 at 04:02):
Canada
Lloyd McKenzie (Oct 21 2021 at 04:37):
Are you familiar with PrescribeIT? It's an Infoway-driven initiative that's doing exactly that and is slowly being rolled out across the country...
Steven Vafadar (Oct 21 2021 at 05:27):
PrescribeIT is responsible for the electronic transfer of prescriptions, not the user-end (patient) access of a pharmacy's services.
Lloyd McKenzie (Oct 21 2021 at 05:43):
I'm not really understanding. PrescribeIT manages the transfer of prescriptions from clinician to pharmacy and between pharmacies. What pharmacy services are you looking to provide a patient with electronic access to?
Stanley Denman (Oct 22 2021 at 20:43):
So if every EHR system is different, then creating a FHIR API has to be customized for each EHR, what good does the FHIR data model do? it seems only that once we have struggled and spend hours learning how to talk to EHR's A-Z, all the FHIR database does is to serve up the data from EHR's A-Z in a uniform way? That is half the battle I guess, but wow, a long way from a workable solution, right?
David Pyke (Oct 22 2021 at 21:29):
The API doesn't have to be customized, the API is uniform. The interface to the EHR has to be customized to fetch the appropriate data to put into each of the FHIR Resources. FHIR is about interoperability, not data storage (although some are doing that)
Lloyd McKenzie (Oct 22 2021 at 22:23):
FHIR isn't magic. It doesn't miraculously cause systems to do what we might wish they would do. It simply provides a specification where, if a system chooses to, it can implement capabilities in ways that are consistent such that a client system can talk to multiple servers using the same interface to achieve the same function.
Stanley Denman (Oct 23 2021 at 13:23):
I am just trying to outline the scope of such a project. So if I have EHR systems A-Z I would need custom interfaces A-Z?
Rik Smithies (Oct 23 2021 at 13:41):
Yes someone has to do custom A to FHIR, custom B to FHIR and so on. But not A to B, because that is covered by A to FHIR to B. So for 26 systems it's 26. But not 26 factorial.
Stanley Denman (Oct 23 2021 at 14:12):
Right. OK. Does seem like a mountain of work, and maintenance. Do you know if this Health Information Exchange is designed to solve this issue? https://www.healthit.gov/topic/health-it-and-health-information-exchange-basics/health-information-exchange
That is, if EHRs A-P are on exchange 1, and EHRs Q-Z are on exchange 2, you only need to create an FHIR interface for exchanges 1 and 2?
Rik Smithies (Oct 23 2021 at 16:15):
If they are already all on an HIE (or on one of a pair of HIEs), which can do FHIR, then you have yourself a translator. But work had to be done to interface each to the HIE in the first place. If that is done, you are in luck. But interfacing 26 systems to an HIE is also a mountain of work - about the same amount of work as converting to FHIR. HIEs are also not magic. They don't start off knowing how to speak to EHR A any more than FHIR does.
Lloyd McKenzie (Oct 23 2021 at 17:44):
Also keep in mind that HIEs tend to be repositories for documentation, not for workflow. So they can share information about a patient's meds, allergies, conditions, etc. But they're not set up to allow you to request changes or drive action in remote systems. Flow through HIEs is also often not real-time.
Last updated: Apr 12 2022 at 19:14 UTC
