benefits of FHIR servers

165 views
Skip to first unread message

Tony ThaDee

unread,
Apr 14, 2021, 2:03:24 PM4/14/21
to HAPI FHIR
I'm trying to determine the benefits of using a FHIR server.  More specifically, I'm curious if anyone knows:

are there any benefits to using a FHIR server as opposed to just using a regular server for the purpose of sending patient data to an EMR.  As a solo developer I have access to our practice's EMR's API and can send data no problem. But does anyone know if there are any benefits to using a FHIR server in our current solution when dealing with passing to EMRs?  This is perhaps an odd question, but I'm just curious about benefits or even if some special consideration or access is granted to softwares that utilize these servers.

I also like the benefits of conversion operations to older versions of the FHIR standard and things like validation, but more specifically I'm trying to find out if I get more from using a fhir server from the EMR rather than the server itself. Or is there some method of accessing that allows me to pass more data somehow?

again, perhaps dumb question, but I'd appreciate even a simple 'no' if anyone cares to respond.

thanks

Tony

granada Coder

unread,
Apr 14, 2021, 4:09:38 PM4/14/21
to HAPI FHIR
The move to "FHIR" (or better said, a version of FHIR, like "R4" FHIR).......is to use HL7 standards for 

DOMAIN LANGAUGE
and 
REST CALLS

so that each "entity" out there STOPS DOING THEIR OWN THING.

My metaphor is this.

FHIR is the Domain Language.

If you are a native english speaker, and you go from USA to UK to Australia .... then you're going to be able to communicate WITHOUT "translators".  You might have some edge cases that don't translate, BUT most of it you will get.

If you go to China or Korea or Argentina, you're going to need a Translator each each "system" you visit.

So if you do not write your new code against (r4 FHIR), then your consumers will have to write "Translator Code" to interpret your data, your custom payloads, your custom rest calls, ETC, ETC.


While learning FHIR is a learning curve, there is NO reason to write NEW code without using the standard.


Your consumers are going to be like "You could have written code where we are all taking the same language, but you chose NOT TO???"

The beauty of "consuming" FHIR servers, is that it SHOULD BE a simple base-url change......and you get the functionalty (<< take this with a grain salt)

Don't believe me?

Run these GET queries in POSTMAN



That's my 2 cents.

Tony ThaDee

unread,
Apr 14, 2021, 5:12:23 PM4/14/21
to HAPI FHIR
thanks for responding, you've definitely given me some good things to consider regarding servers like HAPI. If I understood you correctly I'll respond by saying:

I totally intend on using the standard as I strongly want a standard to make the process of exchanging data easier. I'm just trying to find out if there's a way I can perhaps find other means of using the functionality of FHIR servers like HAPI (i.e. data validation) without having to change the current server I have, AND if there's some means that EMRs provide to teams using FHIR servers to exchange data aside from the usual APIs that developers commonly use.

I know this may seem like a dumb question, but I'm a little new at this and I'm trying to understand if there's some special access ( or means of data exchange ) for certain software solutions. To paint a picture, does Cerner decide to expose a sql database directly to certain developers for faster or better connectivity with fewer restrictions strictly because they use a FHIR server? This is probably a bad example, but I'm trying to paint a good picture here.

I'm guessing the answer is that all solutions have to use the same API, but I'm unsure and was hoping for the opinion of someone who knows more than I do.

Gregory Akins

unread,
Apr 15, 2021, 7:43:10 AM4/15/21
to Tony ThaDee, HAPI FHIR
I'm not 100% sure I understand what you're asking, but perhaps you're wondering if you need to replace your current SQL database, which stores your data with a new database that stores the data from the FHIR Server.

HAPI FHIR Server JPA defines a specific datamodel (the exact SQL database doesn't matter, it can be Oracle, PostgresSQL, etc..). But it is possible to implement a HAPI FHIR plain server server where you don't use their JPA implementation, but instead write a data translation layer yourself that allows you to implement your own datamodel, but use HAPIs validation, models, etc...

Look here for more information. https://hapifhir.io/hapi-fhir/docs/server_plain/introduction.html

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/ca9cf873-9499-4b78-b9b3-33808bae3c4an%40googlegroups.com.

granada Coder

unread,
Apr 15, 2021, 9:41:36 AM4/15/21
to HAPI FHIR
//To paint a picture, does Cerner decide to expose a sql database directly to certain developers for faster or better connectivity with fewer restrictions strictly because they use a FHIR server?//

As a in general software guideline.... "databases" should NEVER be "exposed".  That a a recipe for fragile code and people over burdening the RDMBS server.

Data should be exposed via (rest?) services.

Then the rest layer can "scale", can do caching, implement "real" security, etc, etc.
Reply all
Reply to author
Forward
0 new messages