As we near the end of the year, we wanted to take a look at some industry trends and what will likely impact our clients and key industries in 2020. For this blog, our focus is on the healthcare industry. Brian Silverman, iSOA Group Sales and Marketing Leader, sat down with Bryon Kataoka, iSOA Group CTO, to discuss FHIR (Fast Healthcare Interoperability Resources), and to get his advice on his experience guiding our healthcare clients with their implementation of FHIR.
BRIAN SILVERMAN: Hi Bryon, Thank you for taking the time to speak with me today.
BRYON KATAOKA: I am happy to do so, Brian.
Bryon, what do you see as the key advantages of FHIR as compared to earlier HL7 standards for the exchange of medical patient information?
Well, FHIR has some very distinct advantages over the previous versions of HL7. We really aren’t bound by clunky piped delimited structures (V2) nor difficult to understand XML schema definitions that were utilized in V3. Now with FHIR (V4) we are utilizing Restful services and JSON resource definitions that makes interoperability much easier to understand and integrate.
Is there a web site you would recommend IT and business professionals review to help them get up to speed on the FHIR standard?
There are a number of good resources to learn more about FHIR. From a developer point of view, visiting the HAPI FHIR server location is a great start. I also recommend reviewing the SMART on FHIR page. This will give people more in-depth information on the various versions and security considerations when implementing the FHIR server. I would also recommend looking at the Argonaut Project on the HL7 site. This is a sample of how to implement FHIR.
So, I understand there is a lot of talk on the importance of a FHIR server. What do you see is the key role of the FHIR server and how does that differ from how companies previously deployed HL7 integration standards?
For one thing, the FHIR server implementation is necessary if you want to implement the FHIR specification. The sites I previously referred to will help people learn more about FHIR and how to implement it. For providers of FHIR services, they get the choice of what resources they would like to implement. They can choose which specific resources their company wants to support. This provides customers with more flexibility to implement the base FHIR server or if starting entirely from scratch, they can implement the JPA FHIR server and take advantage of built-in persistence. Most FHIR servers are built using JAVA and you can download the code to begin your implementation or Proof of Concept.
For iSOA Group clients who have embarked on FHIR, what has been their primary use case driving FHIR deployments?
Well I can’t get into a lot of details about our clients’ implementations, but I can share some high-level reasons that have propelled our clients to go down this route. The primary reason I have seen is they want to integrate patient Information with observation and diagnostic report resources with business partners. Believe it or not, in some cases the motivation to implement FHIR was to remove antiquated methods of delivering data to more up-to-date implementations using FHIR.
In your experience, are there key technology choices a healthcare company should consider before embarking on FHIR?
There are a number of solutions out there and one method of data exchange is using APIs via RESTful services. When I work with customers leaning toward this type of implementation, I always suggest they consider the management of those APIs. Using an API Management system such as IBM’s API Connect or Cloud Pak for Integration (CP4i) will provide often forgotten requirements such as analytics (API metrics and metering), governance and consumer documentation (via a Developer’s Portal), and improved security to support not only web access but backend security requirements.
Another thing I have observed is many customers are developing their resources on cloud platforms. Using a multi-cloud enabled platform such as CP4i has the advantage of providing maximum flexibility of deployment to one or multiple clouds.
Do you see an API Management strategy and solution as a critical element for a healthcare company looking to adopt and deploy the FHIR solution?
Absolutely! Solutions such as IBM’s API Connect will provide additional benefits and help companies manage all of their FHIR API’s. Also using container-based implementations using Docker and Kubernetes will make the implementation more portable. For instance, you could start out implementing an on-premise FHIR server but later move to one of the cloud vendors in the future if you choose.
Now, this question is two-fold: What do you see as the key security and authentication technologies that FHIR has standardized on? Are there any gotchas or advice to companies on what they should review within their own security teams?
For consumers on the web it is generally a best practice to use OAuth2, but there is more to security than just OAuth. So, depending on a company’s particular situation, they could use Basic Auth or other mechanisms such as Kerberos to extend their security model. What I highly recommend for companies is they review their FHIR security model that encompasses not only on-premise but also cloud implementations as well. Each cloud vendor has various mechanisms to help ensure the implementation is secure.
Would you recommend companies include a data transformation element of their FHIR deployment to continue to support legacy HL7 and the newer FHIR standards? I bring this up, because this question was asked on a recent call I was on with an IBM healthcare specialist. The comment was made that there are many companies deploying an ESB FHIR component (e.g. healthcare pack for IBM App Connect Enterprise) that enables them to map older HL7 data records to the FHIR format.
The previous versions of HL7 (V2 and V3) have been implemented by many organizations, so to me, it makes sense to slowly migrate to FHIR. The mapping exercise from older versions to FHIR is time consuming and can be cumbersome. It would be prudent for companies to utilize a tool that makes that effort more streamlined.
IBM recently announced its own FHIR server and also an update to their Healthcare Pak for App Connect Enterprise. Do you think this will help to complete the FHIR solution available from IBM as compared to other offerings in the market?
Brian, what you have to remember that, FHIR is a specification and many of the servers are built on Java. There is an operation called CRUD, which stands for Create, Read, Update, and Delete. CRUD operations for each resource can be implemented in various ways. You can build them inline or proxy the implementation to an ESB or other messaging technologies. There isn’t a one size fits all though. I would say that utilizing something like App Connect Enterprise would provide a benefit because the bottom line is retrieving resource data. Since ACE allows multiple protocols, it won’t matter if your implementation is using MQ, HTTPS, SOAP services or even FTP. You can do all the connections using the same tooling.
Lastly, and maybe most importantly, what are the iSOA Group best practices and recommendations on how to get started developing requirements and solutions for supporting FHIR?
One of the keys to any company’s success implementing FHIR, API Management and Integration solutions is to develop a solution plan. This will ensure the technology selection and implementation plan aligns with the company’s goals and direction. At iSOA Group we recommend an integration workshop that will help companies document their solution plan, including architecture, business alignment, security, and technology capabilities. This also enables the company stakeholders to participate and be involved in this decision-making process and have ownership and buy-in to the chosen direction and solution.
BRIAN SILVERMAN: Thank you Bryon for your time. I am certain this information will be relevant to our healthcare community at large. Have a happy holiday and New Year.
BRYON KATAOKA: You’re welcome and have a happy holiday.
Bryon Kataoka is a trusted IT advisor and a veteran in software consulting with more than 25 years in the industry. After years in the financial industry, Bryon helped mold iSOA Group, Inc., a division of Commerce Solutions, into an IBM Premier Business Partner in 1997. As a trusted advisor, Bryon recognized the need to help organizations move toward SOA.