Stream: implementers
Topic: What is different to a GET server that serves FHIR JSON res?
lychenus (Nov 23 2020 at 04:39):
We are a company that works on health kit data (or blood lab stuff you can imagine) and some of the healthcare organization asked us if we can provide a FHIR format.
We already have a server that serves the results with our in house JSON format
After I went through all the materials I am confused. We only provide the data so I guess we do not really need PUT/POST/DELETE (even if a customer wants to DELETE his data, he can do so via the current means, and the data would be deleted from our server. And of course he cannot change his blood results because.... we do not suppose we can do it that way).
So what is it different from that we can build a simple node js GET server with authentication, in which our case it is a token we gave them, and then serve their data in the selected FHIR format? We do not even save identification in our database since it is our company policy to not keep any personal identification... so... what is the different? Isn't this just a simple JSON response server that queries upon a database and then present the response in a designated format called FHIR?
Grahame Grieve (Nov 23 2020 at 06:47):
at a minimum, yes, that's it.
Michele Mottini (Nov 23 2020 at 15:06):
You need to return also a CapabilityStatement (GET [base]/metdata) describing which FHIR resources your server support - but that can be a simple static file
Lin Zhang (Nov 23 2020 at 15:44):
Sounds like a read-only server
Paul Church (Nov 23 2020 at 15:46):
The only other area is having the GET server try to make headers and error responses conform to the standard so clients have a more consistent experience.
Yunwei Wang (Nov 23 2020 at 18:46):
And don't forget search is also a GET. And security.
Lin Zhang (Nov 23 2020 at 23:37):
Sounds like a read-only server
Lin Zhang (Nov 24 2020 at 00:19):
Wierd duplicate post, sorry.
lychenus (Nov 25 2020 at 03:29):
Wait, why do you allow SEARCH?
I do not get it lately. But suddenly I have a lightbulb moment. Is it this FHIR or HL7 ultimately aims to link all US hospital systems such that they can exchange clinical data easily, and authorized person (like doctors or nurses) can access clinical records in another hospital?
That would explain why SEARCH is allowed, because they are only for authorized persons?
In such case, our company would not need to have SEARCH since we are only supplementing the data for patient's convenience. If they do not allow sharing their personal record, they do not have to. And we do not really need PUT/POST/DELETE mostly either?
I suddenly realize it earlier today since
(1) UK has the NHS
(2) Hong Kong they have a linked system in public hospital called the CMS (clinical management system)
(3) I assume the Canadian has the same since they have no concept of a "private hospital"
So systems outside US weren't particularly interested in FHIR.
So FHIR or HL7 was a movement such that different hospital can exchange data a lot more easily, and that was particular for US. amirite?
thanks
René Spronk (Nov 25 2020 at 08:33):
As a diagnostic device vendor your interoperability requirements are 'relatively easy' compared to some others, and I'd urge you to look at the IHE PCD specifications for guidance. You may not require your own server at all, perhaps you should architect to push the data to someone else's server. There;s also a #devices stream on this chat forum that may prove to be useful.
FHIR as a standard is used for many different kinds of exchanges and workflows. And whilst FHIR is being used quite a lot to facilitate exchanges between healthcare organizations, it is by no means limited to that. HL7 and FHIR have the aim to support "data interoperability in healthcare", in the widest sense of the word 'healthcare', inclusive of things like device-interoperability, patient-apps, back-end exchanges between EHRs, and data exchanges between healthcare organizations. An no, this is in no way US specific, interoperability challenges exist regardless of how one structures a nation's healthcare system.
Lloyd McKenzie (Nov 25 2020 at 23:06):
@lychenus Search is necessary whenever a system that might need information wants to get that information from another system and doesn't know the specific record ids it needs - which is the vast majority of use-cases. The need for search has nothing to do with private vs. public. An app might need to look up a patient's vaccination history. A decision support system might need to look at a patient's current meds. A payer might want to see if a lab test had been done prior to making a referral. All such exchanges might well have constraints on who is allowed to perform certain types of searches or what information they're allowed to get back. But the search mechanism would be consistent.
Last updated: Apr 12 2022 at 19:14 UTC
