Welcome back to our series, Creating an FHIR API. This is Part 2 in our 4-part series on standing up an FHIR using GCP. In Part 1, we talked through two of the offerings out there, Google and Azure, and based on the pros and cons, I decided to use GCP FHIR Cloud Healthcare API.
In this part, we’ll start in on our implementation. A forewarning: we won’t be able to finish it during this installment, so stay tuned for parts 3 and 4! Let’s dive in.
Data interoperability is one of the hardest problems in Healthcare IT. The most popular approach is to exchange HL7v2 messages between systems. These pipe-delimited messages are difficult to read by a human and often need additional customizations between implementations.
The next major paradigm shift is towards FHIR (Fast Healthcare Interoperability Resources), a JSON-based standard that is evolving ahead of the needs of the industry. Cloud vendors like Microsoft, Amazon, and Google are trying to lay their claim to be the one-stop shop for healthcare on the cloud.
This blog is part of a 4 part series diving into an actual use case I recently encountered while working with a client. I had to stand up an FHIR repository/API for 2+ million patients that could be used by hundreds of users every day, as well as countless background processes.
Developing custom applications is one of the hardest professional endeavors, and making them secure is even harder. Malicious actors are constantly changing tactics and strategies, which, unfortunately, makes it impossible to completely eliminate any security threat.
There needs to be a balance between delivering features quickly to meet business objectives and mitigating security risks. Thankfully, these two goals are not mutually exclusive. This blog post dives into the top mistakes that can be made while developing custom applications.
These recommendations are different from what would commonly be seen in an OWASP list, and they should be used in addition to whatever security practices and procedures are already in place by an organization’s infosec department. These recommendations are also written from an application architect’s (rather than an enterprise infrastructure) perspective, so most of them aren’t covered by existing security checklists.
The steps described in this blog post allow for the adding of a Logic App on Azure to append rows to an Excel file. It took a lot of trial, and mostly error, to figure out how to describe what I wanted in the way that the Logic App would understand. Hopefully, the steps that I outlined in this blog post will save others the time it took me to come up with them.
Recently, while working for a large healthcare client in New York, I ran into an interesting problem that had slim literature on how to solve it.
Our application is primarily on-prem, but it does leverage Azure for a few functions that are easier to solve in a cloud-native environment. We wanted to be able to monitor those functions using the same Elastic Stack that we use to monitor our on-prem application.
I was tasked with building a bridge between where our functionality logs to in Azure (App Insights), and getting that securely back into our Elasticsearch instance that powers our Elastic Stack.
This blog post will detail the solution I landed on. I hope it will be useful to others that need to solve a similar problem!
