Stream: genomics
Topic: Input on Article - can FHIR Scale to high volume production?
Arthur Hermann (Nov 08 2021 at 18:32):
I read this article this weekend and wondered if anyone can provide their input on whether the author is way off base, or if there really are significant concerns about FHIR scaling in high-volume healthcare production use cases - based on their own experience:
https://vneilley.medium.com/most-fhir-servers-are-unusable-in-production-8833cb1480b1
Most FHIR Servers are Unusable in Production
FHIR Proof: Call to Action for FHIR Solutions to Prove their Usability
Bob Dolin (Nov 08 2021 at 19:04):
I'd say 'way off base'. It's a question of apples vs. oranges. When, for instance, you deploy FHIR operations, there is nothing inherently faster or slower about the operation because it is based on FHIR. When you have to manage millions of patients, particularly where a good percentage of those patients have whole or partial genome testing, we just need to think of a server's internal data store as a black box, served up by a FHIR API. It's not necessary that we limit our focus to servers that are trying to store millions-plus instantiated FHIR resources.
May Terry (Nov 08 2021 at 19:09):
generally agree, although the greater question is what actually gets returned as a FHIR response resulting from the query. If we anticipate a very complex bundle that is "fully stuffed" then we might have to start considering what this might look like in say, bulk FHIR. So if anything, it gives credibility to some of the genomics FHIR Operations design work that you've been spear-heading for quite a while. What is the right balance between transactional chattiness of certain targeted FHIR operations and say, $everything. :-)
Bob Dolin said:
I'd say 'way off base'. It's a question of apples vs. oranges. When, for instance, you deploy FHIR operations, there is nothing inherently faster or slower about the operation because it is based on FHIR. When you have to manage millions of patients, particularly where a good percentage of those patients have whole or partial genome testing, we just need to think of a server's internal data store as a black box, served up by a FHIR API. It's not necessary that we limit our focus to servers that are trying to store millions-plus instantiated FHIR resources.
Arthur Hermann (Nov 08 2021 at 19:29):
It definitely seems to depend on the use case within the healthcare system. This is the response I received from one of our SME's inside of KP: We are already hitting many of the performance issues.
Ingest, inefficient request protocols, storage bloat.
But we’ve also made great headway to address issues and process large number of requests/ingests today.
Vendors are helping to fix some issues, but there needs to be more investigation on this topic.
ONC FHIR at Scale taskforce is working on the next generation capabilities.
One channel is providing input to this taskforce.
Arthur Hermann (Nov 08 2021 at 19:36):
I am concerned that a lot of the inefficiency and bloat come from the fact that the sender of the FHIR data, is not yet familiar enough with FHIR and therefore there is a lot of extraneous information being sent along with the data which is required. This is simply something for us to keep in mind in Genomics. In general these problems are outside of the CG scope and hopefully they will work themselves out in the near future.
Bob Dolin (Nov 08 2021 at 20:13):
Arthur, I couldn't agree more. And since May broached the subject of Operations, I thought I might include a link here - still pretty preliminary, but striving to do as you suggest, which is to hit the right balance between atomic vs. molecular operations, that allow for speed despite size of data store. http://build.fhir.org/ig/HL7/genomics-reporting/branches/operations/operations.html
Bret H (Nov 08 2021 at 20:15):
right. references back to your server with a URI and a identifier can be used to reduce the payload size. And there's also the combat of getting folks who've been used to using SQL on relational databases to adjust to using the FHIR RESTful API to query.
Bret H (Nov 08 2021 at 20:16):
A lot of the bulk requests I have seen are based on the SQL paradigm - things that scaled there do not scale with an API. You use the API differently and can get better performance.
Arthur Hermann (Nov 08 2021 at 22:42):
I see that most of your responses have been about queries... I think that the article I referenced (and definitely the info I shared from an SME at KP) are based on data being sent via FHIR to a healthcare system or directly to an EHR. I am certain that a big part of the problem is what Bret pointed out.... FHIR is a new paradigm, and it will take some time to get people to move from thinking in their old paradigms. I hope that helpful tools, vendor applications and IG's such as ours will help people understand how best to use FHIR... and in the meantime, hopefully there will be tools for the "receiving end" which can pair down the requests automatically so that they contain only the absolute necessary data.
Jamie Jones (Nov 08 2021 at 22:56):
@Arthur Hermann High volume FHIR ingestion is far from standardization. In part due to Postel's Law, it doesn't matter much if systems are storing things one way or another as long as they can all transmit to and accept from the same data model. There are some fun open source tools starting to emerge in the research & analytics space, but it will be interesting to see what market forces can accomplish on the receiving end for large systems (and if regulators will need to step in).
Joel Schneider (Nov 09 2021 at 06:20):
The article is mainly concerned with "FHIR servers". In my mind, this topic is not quite the same as FHIR proper (the interoperability standard itself). The scalability topic is an interesting one, but I think it's important to keep that distinction in mind.
Bret H (Nov 09 2021 at 18:02):
also note: the author says 'Disclaimer: I am employed at Google Cloud as a Solution Architect.' and goes to show that Google scales the best. But the metrics are certainly worth asking about when considering a FHIR server. Also, one is more likely to be putting a FHIR server as a layer for interfacing above current architecture. The actual storage of data for 'local' EMR use is not currently FHIR (if it will ever be).
As a side note, it is interesting how much folks talk about storing data as FHIR. That speaks to some kind of success in adoption. Rather than just being a competitor for HL7v2 in data exchange, HL7 FHIR offers value that you don't have there. Can you imagine someone saying they want to natively store HL7v2.....v2 is definitely meant to be parsed and the information transformed into more accessible formats
Arthur Hermann (Nov 09 2021 at 19:21):
Good points from both Bret and Joel.... this was just meant to be food for thought. The one reason that I think that there really is "smoke" here is the response I received from a key SME at Kaiser when I sent him this article (which is noted above). But I think (and hope) these issues will be addressed as people "use FHIR better" and better tools are put in place to address these issues. I agree with Bret about storing as FHIR. I am seeing a huge amount of work from large vendors including MSFT and Google to use FHIR as the normalization and storage tool/format for "all" health care data. They are creating tools to "convert" data to FHIR, and tools to ingest new data in FHIR as it enters the healthcare system.
Bret H (Nov 09 2021 at 21:57):
but FHIR is meant (or was) for exchange, not a storage model as such see: Fast Healthcare Interoperability Resources (FHIR, pronounced "fire") is a standard describing data formats and elements (known as "resources") and an application programming interface (API) for exchanging electronic health records (EHR).
May Terry (Nov 09 2021 at 22:03):
agree with @Bret H - and sometimes I wonder if there is some confusion in the community between a FHIR server being an interim staging server for exchange as opposed to a persistent storage server / data mart. I don't think it should be seen as the latter...at least at this time. This kinda reminds me of an old informatics paper I read a while back where someone prototyped an EHR with the schema based on HL7v2 as a persistent store. :grimacing:
Last updated: Apr 12 2022 at 19:14 UTC
