FHIR for Developers: Part 8
FHIR Implementation Strategies
Till now in the FHIR for Developers series, we looked into different aspects and components of the FHIR specification. Starting from defining FHIR, FHIR Resources, Profiles, Exchange Module, Clients, Servers, etc. All these are the building blocks of the FHIR and understanding these is important before starting the actual FHIR implementation.
After understanding the basics of FHIR and its components, a question might arise in your mind about where to start your implementation or how we can integrate FHIR into your existing implementations. It is not an easy job to decide how to start, where to start, and what should be your implementation strategies for implementing your FHIR application.
What to expect?
In this article, we will take a look into what are the different implementation strategies that you can use for the implementation of the FHIR application. We will take a look into what are the different factors that you may look at before moving forward with your implementation. We will also take a look into which strategy should be used in which case.
Strategies
Now when it comes to implementing FHIR there are different strategies available. Choosing the strategies will depend on how your current system is implemented and what is your end goal to be achieved. Every strategy has its own pros and cons which we need to consider before coming to our ultimate decision of what strategy to be used.
Generic Servers
These are used when we use most of the FHIR resources in the implementation. Also, it is easier to implement a generic FHIR server. Generally, these types of FHIR servers come with their own storage options and may come with several other features which may be specific to the servers. There are both open-source implementations of generic FHIR servers like HAPI servers and proprietary servers like Google, Microsoft servers, etc. Since we are implementing a complete FHIR Server cost of implementation is higher than implementing generic FHIR servers.
Specific Servers
These are used when we need to introduce FHIR in the existing apps/legacy apps. Even if you are not implementing the legacy app but starting with the fresh implementation, you may want to consider this server if you are developing a simple FHIR application. In this case, it is better to implement these types of servers when we just need to use only a few FHIR resources from the given list to implement the exact specific requirements. It is also cheaper to implement a specific FHIR server but the cost may increase exponentially with the increasing complexity of the systems. There are different FHIR facades or adapters that can be used for implementing specific servers.
- Option 1: There is an existing system in place to access and store the non-FHIR data. An adapter will understand the normal and FHIR and provide access to both when required.
- Option 2: There is an existing system in place to access and store the non-FHIR data and that will keep working independently. An adapter will directly connect to the database and provide the FHIR access.
What is Adapter? An adapter is a FHIR layer over your existing legacy apps. These adapters are used as the mini FHIR servers implementing just a specific part of the FHIR server. This will also include mapper implementations that will be used to map your legacy data to the FHIR models and also contains the implementation of FHIR APIs. You can check FHIR Plain Servers implementation in HAPI FHIR for implementing your own custom adapter
- Option 3: There is an existing system in place to access and store the non-FHIR data and it is difficult to implement the adapter directly on the data. In this case, we will use a translation layer to translate the existing data to FHIR data. Now we can implement an FHIR generic server over using the translated data.
SMART on FHIR
This is another important strategy that you can use for your implementation. SMART on FHIR is built on the open id and oAuth specification which lets you connect to the different EHR providers for your FHIR data needs. This is a very popular and easy way to implement and develop FHIR applications without the need of setting up any FHIR server. You can easily connect and access the data from EHR supporting SMART on FHIR. But like any other FHIR implementation strategy, this also has some limitations. Since the FHIR server is not implemented on your side you would have very less control over it and depend only on your EHR provider for your data.
Decision Factors
Before deciding on which of the above strategy to choose we need to answer some of the fundamental questions which will help us in deciding which will be our strategy for implementing our FHIR system. These are also the deciding factors for going with a certain strategy and not going with another.
New or Legacy?
We need to first find that what kind of system we need to implement. Is the system a new or fresh implementation? Is the system a legacy system for which we need to move to implement and create the FHIR application? Based on the answer to the above we can decide what strategies you should move forward with. If we are just going to implement a new system then it will be better to go full on FHIR right from the start and use some generic server, this will help you to be part of the FHIR ecosystem from day one. But if your answer is otherwise you can choose some specific FHIR servers that will help you move a certain part of your application to be moved on FHIR.
Complexity?
The other question that you might want to answer and is a deciding factor is the complexity of your implementation. Is the system you want to implement large and complex? Is the system you want to implement a simple one? If your system is very complex and you will be requiring many FHIR resources for implementing the whole system then it would be better if you go with and invest in a generic FHIR server. But if your answer is otherwise and you don’t require a very complex system and you need to use only a small number of FHIR then you can use specific FHIR servers targeting a specific set of FHIR resources.
Cost?
Another very important question or deciding factor you want to consider before going with any of the FHIR implementations is the cost of implementation. If you have limited resources and cost is the deciding factor for you, then you might prefer the specific FHIR servers over the generic FHIR servers. Generic FHIR server being the wider implementation of an FHIR with a lot more features results in higher costs but this cost can be avoided by using some open source implementation. If you are implementing the specific FHIR implementation then you can avoid costs that come with the generic FHIR servers thus it is cost-effective but it only saves you the initial cost and to implement a generic FHIR server you require a lot more manual coding and thus more resources.
Summary
There are many strategies that you can choose while starting with your FHIR implementation. You can choose from the general FHIR server, a specific FHIR server, or choose to implement a SMART on FHIR app. We also looked into what the different factors that we need to consider while choosing an implementation strategy. In the end, we can safely say the non of implementation strategy is perfect and every strategy has its own pro and cons. Which strategy to choose will depend on your own specific use case.
If you loved my work please like and share this article(and it’s free :)). Also, do follow me for more articles like these.
Also, check out my complete FHIR for Developers series:
Also, check out my other work:
